Skip to content

GDPR Compliance

This guide explains how to assess and achieve GDPR compliance when using EventSourcingDB. It addresses the challenges of storing personal data in immutable event streams, outlines the implications for the right to erasure and other GDPR provisions, and offers practical recommendations for designing compliant systems.

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. Understanding these implications is essential when handling personal or sensitive data in a production context.

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. This immutability guarantees consistency, auditability, and replayability — but it also has implications for privacy regulations like the General Data Protection Regulation (GDPR), which includes rights such as:

  • The right to access stored data
  • The right to rectification of inaccurate data
  • The right to restriction of processing
  • The right to erasure (“right to be forgotten”)

Since EventSourcingDB does not allow updates or deletions, these rights cannot be fulfilled at the level of the database itself. Instead, they must be addressed through application design, data modeling, and operational processes.

Think Before You Write

The most effective way to build GDPR-compliant systems with EventSourcingDB is to avoid storing personal data in events unless strictly necessary. In many cases, you can store references (such as user IDs) instead of actual names or contact information. The referenced data can then reside in a traditional database, where it can be updated or removed independently.

Another option is to use pseudonymization: replace direct identifiers with pseudonyms or tokens that can only be resolved externally. For example, instead of storing "email": "alice@example.com", store "userId": "a3f2b1" and keep the mapping in a separate system.

If personal data must be included in events, make sure to document which fields contain such data, why it is necessary, and how long it should be retained. Align this with your organization's data protection policies and risk assessments.

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.

This process involves the following steps:

  1. Create a backup using the API.
  2. Filter or transform the backup to remove or pseudonymize sensitive information.
  3. Restore the transformed backup into a clean instance of EventSourcingDB.

This strategy is known as rehydration or migration-based redaction. While it is technically feasible, it requires careful planning, validation, and operational discipline. It is not a substitute for data minimization or privacy-aware modeling.

Anonymization and Crypto-Thrashing

One possible strategy for eventual erasure is crypto-thrashing: 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. Crypto-thrashing is not part of EventSourcingDB itself, but it can be implemented at the application level.

This approach allows the system to maintain its immutable event history while rendering personal data inaccessible — a compromise that may be acceptable under certain interpretations of GDPR, especially when combined with documentation and appropriate legal review.

Operational Isolation

When working with personal data, it is also important to isolate environments (e.g. development, staging, production) and to avoid replicating personal data into systems that don't require it. Always treat event logs as production-grade data — even when they are used for debugging or analytics.

If you must share events across systems, ensure that only the necessary fields are included and that downstream consumers are subject to the same privacy constraints.

Designing for Compliance

EventSourcingDB gives you complete control over what gets written — and with that comes the responsibility to handle personal data carefully. Compliance with GDPR must be designed into the system from the start.

Key recommendations:

  • Minimize personal data in events whenever possible
  • Use references or pseudonyms instead of direct identifiers
  • Document which fields contain personal data
  • Plan for rehydration if deletion becomes legally required
  • Consider crypto-thrashing for post-hoc inaccessibility
  • Avoid treating the event store as a general-purpose datastore

Event sourcing and GDPR are not incompatible — but they require conscious trade-offs and disciplined design. By understanding the constraints and responsibilities, you can build systems that are both event-driven and privacy-aware.