Teams make test copies of a database three main ways: full cloning creates a complete standalone copy of production, database virtualization serves thin, block-sharing copies from a shared snapshot, and subsetting extracts a smaller but referentially intact slice of the data. All three trade off on storage footprint, how fast an environment can be provisioned, and how much infrastructure they demand — but none of them removes sensitive data on its own, so de-identification is a separate layer applied on top. Subsetting paired with masking is the combination test data management is built around, and it's how teams provision safe, targeted datasets for development and testing.
Three ways to copy a database for testing
Every non-production environment starts with the same question: how do you get a realistic copy of the database into it? Three approaches dominate, and they differ mainly in how the copy is produced and how large it ends up. They are the how of making a test copy; how teams manage test data across environments — when to refresh, who gets self-service access, how copies stay compliant — is the wider discipline these methods serve.
- Full cloning makes a complete, standalone copy of production — a logical dump and restore, or a full physical copy of the database files. Every environment receives the entire dataset, fully isolated from every other copy.
- Database virtualization serves thin virtual copies from a shared snapshot. Each copy references the unchanged blocks it holds in common with the source and stores only the blocks it changes, so many environments can share most of their underlying data.
- Database subsetting extracts a smaller but coherent slice of the source — say, 5% of users along with every row related to them — producing a small database that still behaves like the real one.
The distinction that runs through all three is worth stating plainly: cloning, virtualization, and subsetting change the size, cost, and provisioning speed of a copy, not its sensitivity. A cloned, virtualized, or subset database still contains whatever production contained, personal data included. That is why test data management pairs a sizing strategy with de-identification rather than treating a copy as safe once it's small — and it is the model Tonic Structural is built on. Structural's patented subsetter produces a referentially intact slice while masking sensitive values in the same workflow, so what lands in a lower environment comes out both small and safe rather than being made safe in a second, separate project.
How they compare on storage and provisioning speed
Storage footprint and provisioning speed are the two axes engineers feel first, and the three methods sit far apart on both. Full cloning is the simplest to reason about and gives complete isolation — nothing is shared, so nothing can collide — but it is the heaviest option by a wide margin. A separate full copy per environment multiplies storage linearly, and every refresh moves the entire database again, which turns routine environment resets into slow, expensive operations.
Database virtualization was designed to solve exactly that weight problem, and it does so well. Delphix pioneered the block-sharing approach, and its genuine strengths are worth naming: because virtual copies share unchanged blocks from a common snapshot, each copy adds only a small incremental storage footprint, and thin copies can be provisioned and refreshed quickly through an API-first workflow that fits automation tools like Jenkins and Terraform. The trade-offs are real too. Virtualization needs specialized infrastructure to run, and full virtualization support skews toward traditional relational databases — on cloud warehouses such as Snowflake and Databricks, coverage narrows toward masking templates rather than full block-sharing. For teams that want many fast point-in-time copies of a large RDBMS estate, that is often a worthwhile exchange.
Subsetting attacks the footprint from a different direction: instead of sharing the bytes of a full-size copy, it shrinks the dataset itself. A representative 5% slice is small enough to be portable — often small enough to run on a laptop — and because a refresh moves only that slice, far less data crosses the wire each time. That makes subsets a natural fit for teams that want to provision and refresh environments on demand inside a CI/CD pipeline. A subset needs no virtualization layer to stay light, though it does place more demands on how the slice is extracted, which is where the next consideration comes in. For a head-to-head on the virtualization approach specifically, a deeper Structural-versus-Delphix comparison covers the architectural differences in full.
Which approaches preserve referential integrity
Referential integrity is the hidden failure mode of test-copy strategies, and it is where the three methods separate most sharply. Cloning and virtualization both preserve it for free, because both reproduce the whole database: every foreign key still points at a row that exists, since every row is present. Subsetting is the approach where integrity has to be earned. Pull "10% of orders" with a naive query and you orphan foreign keys everywhere — order rows that reference customers you didn't copy, line items that reference products that aren't there — producing a database that violates its own constraints and breaks the moment an application touches it.
Doing subsetting correctly means preserving referential integrity across related tables: the subsetter has to start from a target set of rows and traverse the schema's relationships outward, pulling in every parent and child row required to keep the slice internally consistent — across tables, and across databases where relationships span more than one. A referentially intact subset is one where every foreign key still resolves, every parent has its required children, and the slice as a whole obeys the same constraints production does. That traversal is the hard engineering problem subsetting lives or dies on, and it is what separates a usable small database from a corrupt one.
This is the problem Tonic Structural's patented subsetter is built to solve: it walks the dependency graph to assemble a coherent slice that holds together across tables and related databases, rather than snipping rows table by table. The payoff shows up at scale. eBay scaled its multi-petabyte data ecosystem down to manageable subsets, shortening development cycles and fueling automated testing — the kind of reduction that only works if the smaller copies stay referentially intact enough for real applications to run against them.
The missing layer: removing sensitive data
Cloning, virtualization, and subsetting all change how much data you copy and how fast, but none of them removes PII or PHI. A subset of production is still production data. A virtualized copy is a faithful reproduction of the source, sensitive columns and all. A clone is an exact duplicate. Whichever sizing strategy you choose, a lower environment populated with an untouched copy carries the same privacy and compliance exposure production does — and lower environments are exactly where access is broadest and controls are loosest.
De-identification is the orthogonal layer that makes a copy safe, and the sizing methods differ in how cleanly they combine with it. Applying data masking — transforming real values into realistic but fictional ones — pairs naturally with subsetting, because the same pass that extracts the slice can transform the sensitive fields on the way out. Virtualization vendors bolt masking on as a separate capability, and its coverage is narrower on cloud warehouses than on the traditional databases virtualization targets best. The approach that works for teams doing this well is to subset and mask together, so the copy is produced small and safe in a single operation rather than copied first and sanitized afterward. That combination is what makes self-service, production-like data practical for everyday testing and QA without routing every request through a privacy review.
The Tonic Advantage: small and safe in one pass. Tonic Structural applies masking and de-identification inside the same workflow that produces the subset. As the subsetter walks the schema to build a referentially intact slice, it transforms sensitive values in place — preserving each field's format and keeping the same real value masked to the same fictional value across every table it appears in. The copy that lands in a lower environment is therefore both small and compliant in a single step, with cross-table consistency intact, instead of being subset in one tool and masked in another.
How to choose an approach for your team
The right method follows from what your environment needs most, so treat the choice as a fit question rather than a ranking. Full cloning suits small databases or one-off needs where complete isolation matters more than storage cost — a copy you stand up, use, and discard. Database virtualization suits large relational estates that need many fast point-in-time copies and can invest in the infrastructure to run it; the block-sharing model earns its keep when the copy count is high and the source is a traditional RDBMS. Subsetting paired with masking suits teams that want small, safe, self-service environments wired into CI/CD — the natural fit for teams building and testing continuously, because it produces copies that are cheap to move, quick to refresh, and compliant by construction.
There is also a fourth option worth weighing honestly when production data is the wrong starting point. When production is too locked down to copy, too sparse in the cases you need to test, or simply can't safely provide the volume a load test demands, generating data is the better path. Tonic Fabricate creates net-new synthetic records from a schema or a natural-language description rather than transforming production, which sidesteps the sensitivity problem entirely. The two approaches also combine: Tonic Structural and Fabricate can pair to scale a masked subset up to the volumes performance and load testing require, using the de-identified slice as the model for generating additional realistic data. Deciding between generated and masked data on a given project is its own question — worth weighing synthetic test data against masked production data directly — and for the full set of categories and vendors, the wider tool landscape maps the options.
| Criterion | Subsetting + masking (Tonic Structural) | Database virtualization | Full cloning |
|---|---|---|---|
| Storage footprint | Small — the dataset itself shrinks to a slice; portable enough to run locally | Very low per copy — copies share unchanged blocks from one snapshot | Highest — a complete copy per environment |
| Provisioning speed | Fast — small copies move quickly; refreshes transfer only the slice | Fast — thin copies spun up from a snapshot, API-first | Slow — a full dump-and-restore or physical copy each time |
| Referential integrity | Preserved when the subsetter traverses relationships across tables and databases | Preserved — the whole database is reproduced | Preserved — it's a complete copy |
| Removes sensitive data | Yes — masking and synthesis run in the same pass | No — masking is a separate add-on, narrower on cloud warehouses | No — an exact copy of production |
| Best fit | Small, safe, self-service environments in CI/CD | Large RDBMS estates needing many fast point-in-time copies | Small databases or one-off needs where isolation outweighs cost |