Event sourcing and GDPR have a reputation for not getting along. An immutable log that never forgets sounds like the opposite of the "right to be forgotten." Some event stores treat this tension as an afterthought, leaving teams to migrate entire databases or build complex workarounds just to erase the data of a single customer. That is not only inefficient, it can become a real business risk.
GenesisDB takes a different approach. GDPR compliance tools are built directly into the engine.
The problem with bolt-on GDPR
Most event stores were never designed with data erasure in mind. When a deletion request arrives, teams face ugly options:
- Full stream rewrite: Replay every event, filter out the target, and write a new stream. Downtime, risk, and engineering hours add up fast.
- Tombstone hacks: Mark events as deleted without actually removing the data. Auditors may not agree that this counts.
- External encryption or a second database: Encrypt personal data outside the store and throw away the key, or offload it to a separate system entirely. Both approaches add infrastructure costs and operational complexity.
Worse, they break simple queries: if you need to find a user named "Hiram Abiff," you are suddenly reaching across two systems just to answer a basic lookup.
These approaches can work, but they were never designed with production-grade compliance in mind. In most cases, they add more moving parts than they remove.
How GenesisDB handles it natively
GenesisDB separates personal data from the event metadata at write time using the storeDataAsReference option. The event stream stays intact and immutable. The referenced data can be erased surgically, without touching a single other event.
Step 1: Store events with referenced data
When committing events that contain personal data, set storeDataAsReference to true. The engine stores the data payload separately, linked to the event by subject.
curl --location "http://localhost:8080/api/v1/commit" \
--header "Content-Type: application/json" \
--header "Authorization: Bearer secret" \
--data '{
"events": [
{
"source": "io.genesisdb.app",
"subject": "/user/456",
"type": "io.genesisdb.app.user-created",
"data": {
"firstName": "John",
"lastName": "Doe",
"email": "john.doe@example.com"
}
}
],
"options": {
"storeDataAsReference": true
}
}'Step 2: Erase personal data on request
When a customer exercises their right to be forgotten, a single API call removes all referenced data for that subject. The event metadata and stream order remain untouched.
curl --location "http://localhost:8080/api/v1/erase" \
--header "Content-Type: application/json" \
--header "Authorization: Bearer secret" \
--data '{
"subject": "/user/456"
}'That is it. No migration, no stream rewrite, no downtime. The personal data is gone while the audit trail stays intact.
Compliance should be a feature, not a project
GDPR requests should not trigger emergency engineering sprints. When erasure is a native database operation, compliance becomes routine instead of risky.
Why this matters for your architecture
- Zero downtime: Erasure runs while the system stays live. No maintenance windows required.
- Audit trail integrity: Event metadata, ordering, and causality remain intact after erasure.
- Developer simplicity: Two API calls. One to store, one to erase. No custom pipelines or external tooling.
- Regulator confidence: Data is genuinely removed, not just flagged or hidden behind a tombstone.
Compliance as a built-in feature
GDPR compliance should feel like a routine operation, not a migration project. GenesisDB was designed from the start with data erasure as a first-class feature, so your team can handle deletion requests with confidence instead of concern.