Masked production data and synthetic test data are two ways to get safe, realistic data into test environments, and the right choice depends on the test in front of you. Masking de-identifies real production records, preserving the exact structure, distributions, and edge cases your application already hits — the best fit when you have production data you can safely transform. Synthetic data is generated from scratch or modeled on a schema, which makes it the better option when you can't reach production, need more volume than production holds, or must cover scenarios that real data doesn't contain yet.
Two ways to get safe test data: masking vs. synthesis
Every team that can't drop raw production data into a lower environment ends up choosing between two methods for producing safe, realistic data, and the two start from opposite ends. Masking — also called de-identification — takes real production records and transforms the sensitive values inside them, so the output keeps production's structure while shedding its personal data. Synthesis takes a specification and generates new records that never existed, either from scratch or by modeling the patterns of a database you already hold. Almost everything else follows from that one difference in starting point: masked data *is* real data with the sensitive parts changed, while synthetic data is manufactured to match a shape you define.
The distinction maps onto the different types of test data a team works with day to day. A quick way to hold the two apart:
- Masked (de-identified) production data: real records with sensitive fields replaced or obscured. You need access to production and a safe way to transform it, and the output inherits production's exact structure and quirks.
- Synthetic data: records generated to match a schema or a model of real data, with no dependency on any individual production row. You need a specification or a source schema, not access to the live rows themselves.
Tonic Structural is a clear exemplar of the masking approach: it connects to a production database and produces a de-identified copy developers can safely work against. Tonic Fabricate is the exemplar of the synthesis approach: it generates data from a prompt, a schema, or a model of an existing source. They solve different starting problems — one for when you have production data to transform, the other for when you don't — so the useful question is rarely which is better in the abstract, but which fits the test in front of you.
When masked production data is the right choice
Masking is the right choice whenever you have production data you can safely transform, because the de-identified copy carries production's real structure, distributions, and accumulated edge cases — the highest-fidelity option for functional and regression testing. Real production is the record of everything your application has actually encountered: the malformed addresses, the accounts with fifteen years of history, the rare state transitions no one would think to invent. De-identifying that data rather than generating fresh data means the copy still exercises all of it, which is exactly what you want when the test's job is to catch the bugs production would.
Three techniques do the work of test data management: turning a production database into a safe, right-sized copy. Masking (de-identification) replaces sensitive values — names, account numbers, dates of birth — with realistic substitutes so no real person's data reaches a lower environment. Database subsetting shrinks the copy to a coherent slice rather than a full clone, so a test database is a manageable fraction of production's size. And referential integrity — the property that relationships between tables stay valid, so a foreign key still points at a row that exists — has to survive both of those steps, or the copy arrives full of orphaned records that fail your suite on the first run. Getting all three right at once is what separates a usable copy from a broken one, which is why data masking and subsetting are best treated as one workflow rather than two.
The Tonic Advantage: a safe, right-sized copy from your real schema. Tonic Structural connects to a production database, applies masking rules column by column, and provisions a de-identified copy that preserves referential integrity across related tables. Its patented subsetter pulls a coherent slice — a defined percentage of the data, or a targeted set of records plus every row they depend on — so the copy stays a fraction of production's size while still behaving like it. Structural pairs pattern-based detection with LLM-enhanced detection to find sensitive fields that simple pattern matching misses, and its built-in agent configures the masking and subsetting from a plain-language description, turning what used to be hours of manual setup into minutes.
The payoff of getting this right shows up directly in provisioning speed. Patterson reported a 75% reduction in test data provisioning time after standardizing how it de-identifies and provisions production data for its development teams, keeping PHI out of developer workflows. When the data you need already exists and can be transformed safely, nothing else reproduces the real world as faithfully.
When synthetic data is the right choice
Synthetic data is the right choice when the blocker is access, volume, or coverage rather than fidelity to one real record. Masking assumes you have production data you're allowed to transform; synthetic data makes no such assumption, because it manufactures records from a specification instead of deriving them from real rows. That makes it the answer wherever a de-identified copy isn't possible or isn't enough. Reach for synthesis when:
- There's no production data yet. A greenfield feature or a brand-new service has nothing to mask — you have a schema and a set of expectations, not a table full of history.
- Production is locked down. Security or compliance blocks any connection to production, leaving no real rows to model from and no option but generating from scratch.
- You need more volume than production holds. Load and performance tests often call for far more records than production safely contains, and you can't mask data that doesn't exist.
- The scenario hasn't happened yet. Edge cases you need to test against — a spike pattern, a rare sequence of events, a not-yet-shipped state — may not appear in real data at all, so they have to be generated on purpose.
Tonic Fabricate is built for exactly this: it generates a relational dataset from a plain-language prompt, a schema, or a model of an existing source, and maintains referential integrity across the tables it creates, so the output behaves like a real interconnected database rather than a pile of disconnected rows. It can also stand up mock APIs — stand-in endpoints that respond like the real services a system will call — so frontend and backend teams can build in parallel against data that doesn't exist yet anywhere.
The trade-off is that data generated purely from scratch doesn't inherit the exact tangle of real-world messiness a de-identified production copy preserves: you get the coverage, balance, and volume you specify, but only the edge cases you thought to model. That's the line between the two methods — masking reproduces the world you already have, synthesis builds the world you need when the real one is out of reach.
How the two approaches compare on fidelity, privacy, and scale
The choice comes down to three axes practitioners actually weigh — fidelity, privacy, and scale — and the two methods trade places depending on which one dominates the test. Masked production data leads on fidelity to real-world behavior because it *is* real behavior with the sensitive values swapped out. Synthetic data leads on volume and access because it doesn't depend on production existing or being reachable. Both can be privacy-safe when done well: masking's residual risk is re-identification if the transformation is too weak to fully break the link to a real person, while synthesis generated from scratch sidesteps that risk because the records were never tied to a real individual in the first place.
| Criterion | Masked production data | Synthetic data |
|---|---|---|
| Fidelity to real edge cases | Highest — preserves production's actual structure, distributions, and accumulated quirks | Matches the shape you specify; can miss real-world messiness you didn't think to model |
| Privacy posture | Safe when transformation is strong; residual re-identification risk if masking is weak | No real records at all when generated from scratch, so no direct tie to a real individual |
| Referential integrity | Must be preserved through masking and subsetting, or the copy breaks | Generated intact across tables as part of the specification |
| Volume and scale | Bounded by what production actually holds | Generate as much as the test needs, well beyond production |
| Works without production access | No — requires a safe connection to production | Yes — a schema or specification is enough |
| Best-fit test types | Functional and regression testing against real behavior | Load and performance, greenfield, edge-case and negative testing |
These are also the axes that decide compliance posture in a lower environment, which is why testing and QA teams tend to reach for whichever method most cleanly removes sensitive data for the test at hand. The fidelity and privacy columns are where most of the real decisions get made: preserving referential integrity through de-identification is what keeps a masked copy usable, and keeping non-production data compliant is what keeps either method safe to run at all.
Using both together: de-identify, then scale synthetically
The two approaches are complementary far more often than they're competitive, and the strongest test-data setups use them in sequence rather than picking one. The common pattern is to de-identify and subset a realistic baseline from production first, then generate additional records on top of that safe dataset — you get the real-world shape from the de-identification step and the volume from the synthesis step. Because the baseline is already de-identified, scaling it up adds rows without reintroducing any of the original sensitive content.
Laid out as a sequence, the pairing looks like this:
- Mask and subset a baseline. Use Tonic Structural to de-identify a production database and subset it to a coherent slice, producing a safe copy that keeps production's real structure and relationships.
- Generate additional records on top. Point Tonic Fabricate at that de-identified dataset and generate more data modeled on it, expanding the record counts well past what the subset alone contained.
- Provision the combined set. Deliver the scaled dataset into the environments that need it — a workflow that also underpins provisioning and refreshing test data on demand as teams spin environments up and down.
This is the setup that load and performance testing usually needs, and the one that makes many parallel environments practical — cases where production alone can't safely supply the sheer volume of data required. Each product does the job it's built for: Structural produces the safe, production-shaped baseline, and Fabricate multiplies it.
The Tonic Advantage: scale a de-identified baseline without reintroducing sensitive data. Point Tonic Fabricate at the de-identified output Tonic Structural produced, and it generates additional records modeled on that safe dataset. You keep the real-world structure the masking step preserved and add the volume production can't safely provide — the difference between a realistic baseline and a dataset large enough to push a system under load.
How to choose for your test scenario
The decision rule follows directly from the trade-offs: match the method to what the test needs most, and don't treat either one as the default. Functional and regression testing against real behavior points to masked production data, because fidelity to production's actual edge cases is the whole point. Load and performance testing, and provisioning many environments in parallel, point to a masked-and-subsetted baseline scaled up with synthesis. A greenfield build or a hard production lockout points to synthetic data from scratch, since there's nothing to mask. And data so sensitive that even a strong mask leaves residual risk points toward synthesis or expert-determination de-identification workflows, which are designed to support that higher bar.
| Test scenario | Recommended approach |
|---|---|
| Functional and regression testing against real edge cases | Masked production data — highest fidelity to real behavior |
| Load and performance testing; many parallel environments | Mask and subset a baseline, then synthesize to scale |
| Greenfield build, or production lockout with no accessible data | Synthetic data generated from scratch |
| Data so sensitive that masking still leaves re-identification risk | Synthesis, or expert-determination de-identification workflows |
Framing the choice this way turns method selection into a per-task decision rather than a standing policy, which is the posture mature teams settle into: masked production data and synthetic data both stay within reach, and the test in front of you decides which one you pull. Both sit inside the broader practice of test data management — and alongside other ways to make test copies, knowing when to transform real data and when to generate new data is what keeps lower environments both safe and useful.