Wider access
Developers, contractors, analytics tools: every copy of the database adds people who can see the data.
PostgreSQL and MySQL data masking
Mask your database for testing, production untouched
NymData reads your PostgreSQL or MySQL database and detects the sensitive columns.
It writes a masked copy to a test or analytics database.
The source database is never modified.
The copy can be kept up to date automatically, on your servers.
Before: sensitive columns highlighted in red
| id | name | phone | city | |
|---|---|---|---|---|
| 1042 | Sarah Mitchell | [email protected] | (555) 014-6621 | Chicago |
| 1043 | John Carter | [email protected] | (555) 013-2847 | Boston |
Copied as is into a test database, the table exposes real people
After: method set column by column
| id | name | phone | city | |
|---|---|---|---|---|
| 1042 | Emily Parker | [EMAIL] | [PHONE] | Chicago |
| 1043 | Daniel Brooks | [EMAIL] | [PHONE] | Boston |
Realistic test data, IDs and structure preserved
- Source database never modified
- Sensitive columns detected
- Joins preserved
- Scheduled updates
How do you mask a database for testing?
Instead of copying production as is, you populate the test database with a masked copy.
With NymData, you choose the source database and the tables.
Sensitive columns are detected.
Each column gets a method (realistic fake name, constant identifier or label), then the data is written to the target database.
Production is never modified, and an audit report documents the run.
The trap
Why copying production into a test database is a risk
Test, development and analytics databases are more open than production: more people access them, with fewer controls.
Copying real data there multiplies the copies of PII you have to protect.
Overlooked columns
Free-text comments, "notes" fields, addresses in a secondary table: sensitive data is not always where you expect it.
Fragile homegrown scripts
A masking script written once goes out of date as soon as a column is added, and it often breaks the links between tables.
What NymData does
A masked database you can still use
Sensitive columns detected
Select the tables: NymData finds the columns that contain personal data.
Simple or column by column
In simple mode, one method applies to every detected column.
In advanced mode, you set it per column, with a preview of the result.
Joins preserved
With a constant identifier, the same value gets the same code across the whole project: tables stay linked to each other.
Source database untouched
Masked data is written to a target database: replace the table, truncate then insert, or append, with an upsert of existing rows when needed.
SQL filters
Limit processing to certain rows with a WHERE clause, tested before the run, or a maximum number of rows.
Scheduled updates
Every day, week or month, NymData only picks up the rows changed since the last run, and produces an audit report.
Learn more: how NymData works, security and on-premises installation, anonymization vs. pseudonymization. In your industry: finance and insurance, manufacturing, healthcare.
Use cases
When should you mask a database?
- Testing and development: realistic test data, with no real people.
- Analytics and AI: feed a data warehouse or a data project with anonymized or pseudonymized data.
- Vendors: give a usable dataset to a systems integrator or a software vendor.
- Historical data: keep the statistical value of older data after its retention period.
Scope
Supported databases
- SupportedPostgreSQL
- As source and target, with schema selection.
- Upsert of existing rows by primary key (ON CONFLICT).
- SupportedMySQL
- As source and target.
- Upsert of existing rows by primary key (ON DUPLICATE KEY UPDATE).
- Good to knowScheduled updates
- A filter on the last-modified date, such as updated_at > '${LAST_JOB_DATE}', or an upsert by primary key, picks up only new or changed rows.
- SupportedSQL filters
- A WHERE clause tested before the run and a maximum number of rows, to process only the data you need.
FAQ
Frequently asked questions about database masking
Is the production database modified?
No. NymData reads the source database and writes the masked data to a separate target database, for example a test or analytics database.
The source stays intact.
Do I have to specify which columns are sensitive?
No. NymData detects the sensitive columns in the selected tables.
In simple mode, the chosen method applies to all of them.
In advanced mode, you set it column by column.
Do joins between tables still work?
Yes, with a constant identifier.
The same value gets the same code across the whole project.
A column replaced with a constant identifier still links the tables it appears in.
Can the masked database be updated automatically?
Yes. A project can be scheduled daily, weekly or monthly.
A filter on the last-modified date picks up only the rows changed since the last run.
Which databases are supported?
PostgreSQL and MySQL, as source and as target.
Learn more
Related reading
ProductFormatProduct
Scheduled processing
Mask your historical data, then every new record automatically.
Excel and CSV anonymization
For files exported from your databases: sheets, columns and delimiter preserved.
Security
Installed on your own servers, without sending your data outside.
See NymData populate a masked test database, live
A demo on a sample database, remotely or at your offices.
Your data stays with you.