How Anonyx preserves referential integrity
Anonymizing a database is easy. Anonymizing one that still works is the hard part. Most tools transform values column by column and break the links between your tables along the way: an order points to a customer who no longer exists, an invoice line references a deleted order. Anonyx keeps those links intact on every run, so your test environments behave exactly like production.
- Primary and foreign keys detected automatically and never anonymized
- The same source value gets the same anonymized value across every table
- Irreversible hashing: HMAC-SHA256 with an ephemeral key, destroyed after the run
- Tables processed in dependency order: parents before children
- Automatic check on every run: no orphaned foreign keys
- No changes to your schema or your application code
Why naive tools break your database
A customer ID carries no personal meaning on its own. But it links a dozen tables: orders, invoices, addresses, support tickets. The moment a tool replaces it with a random value in the customers table without propagating that change everywhere else, the link is broken.
The damage is silent and expensive. Foreign-key constraints fail on import. Joins return empty rows. Integration tests pass against inconsistent data, or crash for no apparent reason. Your team burns hours chasing a bug that isn't in the code, it's in the data.
This is the core problem with homegrown scripts and free libraries: they anonymize a column, not a database.
What it changes for your tests
With Anonyx, an anonymized database behaves like a production copy, minus the personal data. Foreign keys still point to a row that exists. Joins return the same number of rows. The edge cases in your real data (the customer with 400 orders, the invoice with no shipping address) survive anonymization.
In practice, you refresh your dev, test, and staging environments with realistic data, and your test suites pass just like in production. No synthetic dataset to maintain, no fixtures drifting from the real schema, no constraint workarounds to force the data in.
Under the hood
Three mechanisms guarantee integrity, and they apply on every run.
Keys are never anonymized. When you connect your database, Anonyx reads the schema and detects primary and foreign keys. Those columns are automatically locked to the "preserve" strategy: their values are copied as-is. Anonymizing a key would sever the link it carries, so Anonyx won't do it, and stops you from doing it by mistake.
Masking is consistent across tables. When a value needs transforming (an email, a name, a business identifier present in several tables), Anonyx records the mapping between the original value and its anonymized version. The same source value always produces the same anonymized value, everywhere it appears. Your joins on those columns keep working.
Tables are processed in the right order. Anonyx builds the dependency graph of your foreign keys and processes parent tables before their children (topological sort). A referenced value is always anonymized before the rows that reference it.
For hashed columns, Anonyx uses HMAC-SHA256 with a key generated at random at the start of each run and destroyed at the end. The same value yields the same hash during the run, so links hold, but the mapping can't be reconstructed once the key is gone.
Verified on every run
Anonyx doesn't promise integrity, it measures it. At the end of each run, the engine re-validates every foreign-key relationship: every foreign-key value must match an existing primary key in the referenced table.
The run report shows the result: the number of relationships checked and the number of violations introduced. The target is zero, and you see it confirmed on every run. If a misconfigured rule were to break a link, you'd know immediately, before shipping the data.
To see where referential integrity fits in the GDPR debate between anonymization and pseudonymization, see the anonymization vs pseudonymization page.