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.

Removed in 1.3This process involves the following steps:

1. Create a backup using the API – see Backup and Restore.
2. Filter or transform the backup to remove or pseudonymize sensitive information.
3. Rebuild the chain of the backup from the first event you changed or removed on, since a restore checks every event against its hash and the one before it, and refuses a backup at the first event that does not fit: number the events again from 0 without gaps, compute the hash of every event again, and set the predecessor hash of every event to the hash of the one before it. Work on a full backup, and keep the time of every event as it is.
4. Restore the transformed backup into a clean instance of EventSourcingDB – see Migrating Between Instances.

Added in 1.1Changed in 1.3How to compute the hash of an event is described in Verifying Event Signatures.

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.