GDPR Compliance

EventSourcingDB does not include any built-in features for anonymization, redaction, or deletion of data. Instead, it relies on architectural discipline and design-time decisions to ensure that systems built on top of it can meet legal and regulatory requirements.

Events Are Immutable#

By design, EventSourcingDB stores events in an append-only log. Once an event has been written, it cannot be changed or deleted. Since EventSourcingDB does not allow updates or deletions, rights such as the right to rectification or the right to erasure cannot be fulfilled at the level of the database itself. Instead, they must be addressed through application design, data modeling, and operational processes.

No Built-In Deletion#

EventSourcingDB does not support deletion of individual events or fields. There is no API for removing data from the event log. If you need to eliminate certain events or anonymize their content, the only option is to perform a controlled migration to a new instance.

Changed in 1.3This process involves the following steps, none of which needs a hash, since the database computes the hashes itself as it imports the events:

1. Export every event with export-events, which returns each of them as a plain CloudEvent on a line of its own, and check that the export is complete, as its page describes.
2. Filter or transform the lines to remove or pseudonymize sensitive information: remove a line to remove its event, or change the data of an event.
3. Number the events again from the first event you removed on: the IDs begin at 0 and follow each other without gaps, so where you removed an event, every later event takes the ID one lower than before. Keep the time of every event as it is.
4. Start a clean instance of EventSourcingDB and register the schemas of your event types there, as read-event-types lists them on the old instance, with register-event-schema. The import checks every event against the schema of its type, so a change in step 2 has to keep each event matching its schema.
5. Import the lines into the new instance with import-events, all of them in one request.

If the import fails, it removes what it has imported so far and keeps the schemas, so you can correct the lines and import them again.

The import gives every event a hash of the current version, so an event written before version 1.3, whose hash is of version 1, gets a new hash even where nothing before it changed.

This strategy is known as rehydration or migration-based redaction. It is technically feasible, but a last resort: rebuilding the chain changes the IDs and hashes of the events from the first change on, so read models, the positions of observers, and anything else that stored them have to be rebuilt as well. It is not a substitute for data minimization or privacy-aware modeling, such as crypto-shredding, described next.

Crypto-Shredding#

Crypto-shredding is not part of EventSourcingDB itself, but it can be implemented at the application level: encrypt sensitive fields using a per-user encryption key, and destroy the key when the user requests deletion. This renders the encrypted data unreadable without physically deleting it.