Every sprint ends with the same request to the DBA: "can we get production data to test this?" QA wants to validate a backlog item (PBI) against real shapes of data. A developer wants to know whether the new batch process still finishes when it meets production volume, not the 200 rows of the test seed.
The usual answers are both bad. Say no, and bugs reach production because test data was too clean. Say yes, and a full copy of customer data now lives in an environment with wider access, weaker controls and more people. Most leaks from test environments are not attacks. They are human error: a column nobody remembered, a manual script run against the wrong copy, a dump left in a shared folder.
The idea: mask in flight, by default
dbSlice reads the production table and masks the values before it writes each row to the test database. There is no unmasked intermediate copy to clean up afterwards, and source and target can be different engines, for example SQL Server to PostgreSQL.
What makes it safe against human error is the default:
- Every non-key column is masked unless you say otherwise. With masking on, a column keeps its real value only if someone explicitly marks it original. Forgetting a column means it gets masked, not leaked.
- New columns are covered too. If production gains a column next month, the saved job masks it by type on the next run, without anyone editing the job.
- Keys and foreign keys stay intact. Primary keys, foreign keys and the key column of the operation are never changed, so joins still return the same rows and the application under test behaves as in production.
- Same rules every run. The masking map is saved in the job. The nightly refresh applies exactly what was reviewed, not what someone remembered to tick that day.
- The log says what happened. Each run reports how many columns were masked and how many were kept as original on purpose, which is the evidence your security team will ask for.
Who does what
| Role | What they get |
|---|---|
| DBA / SRE | One job that refreshes the test database on a schedule, from the command line or Windows Task Scheduler; the Linux edition runs it in Docker. |
| QA | A database with production's volume, distributions and relationships to validate the PBI, with masked values. |
| DEV | A realistic load to test processing time and query plans before release. |
| Security | A reviewed masking map, a log per run, and no copy in clear outside production. |
Choosing the treatment per field
The default mask works by data type (text keeps only its first two characters, so Maria Silva becomes Ma****; numbers become 0; dates become 1900-01-01). When a field needs to stay useful, pick a treatment:
- Keep the first characters of a phone or document number.
- Hide only the digits of a formatted tax ID, keeping the punctuation.
- Keep the domain of an e-mail:
john.smith@acme.combecomesjo****@acme.com. - Template with the row key, such as
Customer {key}. - Fixed value or empty.
- Consistent hash: the same input gives the same code in every table. With a secret, dbSlice uses HMAC-SHA256, so values cannot be rebuilt by trying every possible input; the secret is stored encrypted for the Windows user who runs the job.
In a job file the whole policy fits in a few lines (field names are from the job format):
"ofuscar": true,
"ofuscarCampos": {
"email": "email:",
"phone": "keep:4,*",
"full_name": "template:Customer {key}",
"document": "hash:"
}Every column not listed is masked by type; "original" is the only way to keep a value in clear.
Production volume, without production risk
A masked copy keeps the row counts and the relationships of production. That is what a developer needs to see whether a nightly process, an index or a report still fits its window. Measure in a rehearsal on your own hardware: copy time depends on rows, row width, network and the target server.
What it does not do
- dbSlice applies the rules you set; it does not decide on its own which columns hold personal data.
- Keys are never masked. If a primary key or foreign key holds personal data (a tax ID used as a key, for example), review that design before copying.
- Using a tool does not make a process compliant by itself; the policy stays with your security and privacy team. Masking needs a dbSlice Desktop or Server license.
Key takeaways
- Test data should look like production in shape and volume, not in content.
- Mask in flight, so no clear copy exists outside production.
- Make masking the default, so a forgotten column is masked, not leaked.
- Save the rules in a scheduled job, so every refresh is the same reviewed policy.
The full walkthrough is on masked staging copy, and the 80-second video is in test data without real customers. The free version of dbSlice is on the Microsoft Store; writing to a target database needs a Desktop or Server license.
Planning a system replacement and need help designing the coexistence? Thinwork can run the project with you.
