Data subsetting for smaller, safer test environments
Tonic reduces full production databases to targeted slices of the data your developers actually need, while keeping primary and foreign key relationships intact.
Describe the subset you need
Tell Tonic's AI agent what you're targeting and it configures the subset, picking the tables to anchor on, setting the filters, and flagging the relationships that matter. What used to mean hunting through a legacy schema is now a sentence.
What the subset takes with it
Once the anchor tables are set, Tonic's patented subsetter follows your foreign keys out from there, pulling in every row those records depend on. Lookup tables copy in full, so referential integrity survives the cut.
Masked in the same pass
Subsetting runs in tandem with de-identification so what reaches your test environment is both smaller and safe to use. One pass through test data management, not a dataset queued behind a privacy review.
What powers a referentially intact subset
Agent-assisted subsetting
Describe the dataset you need in plain language and the agent configures it, target tables, row filters, lookup tables, and upstream filters included. Ask it which tables should be lookups, or how large the subset will be. It reads your schema, so its advice reflects how your tables connect.
Target tables and row filters
Name the table that anchors the subset and say how much you want: five percent of transactions, or every transaction from customers in one region. Tonic converts a percentage into a filter your database understands, then builds the rest of the dataset around it.
Virtual foreign keys
Relationships in a mature schema often live in application code rather than declared constraints. Add them inside Tonic instead of touching the database, and polymorphic keys become traversable too, preventing a subset from arriving full of orphaned rows that fail your suite on the first run.
Circular dependency handling
Employees reference departments, departments reference managers, and a naive traversal circles between them forever. Tonic catches the cycle before the job starts and breaks it by nulling the fewest nullable keys it can, then marks on the schema graph exactly which columns it touched.
Subset and de-identify in one job
Subsetting cuts how many records exist. Generators mask or synthesize what's sensitive in the ones that remain. Both run in a single job, so the developer who asked for a local environment gets a dataset that's small and compliant, not a small dataset waiting on a privacy review.
Where a smaller database changes the work
Local development on a laptop
Production won't fit on a developer's machine, and a random sample breaks the first time a foreign key points at a row that got left behind. A subset that respects relationships clones down, boots, and behaves like the real thing, so you debug your code instead of your fixtures.
Reproducing a production bug
A WHERE clause on the target table pulls the exact account, order, or claim that triggered the defect, plus every related record scattered across the rest of the schema. The engineer chasing it opens a dataset scoped to the problem instead of grepping through a copy of everything.
Offshore and vendor development teams
Data localization rules and vendor agreements both narrow what can leave your environment. A de-identified subset is small enough to move and narrow enough to leave out what you can't share, so contract teams build against data that behaves like your system without holding your customers' records.
Healthcare test data with less PHI
Minimum necessary is a HIPAA standard, not just a storage tactic. Subsetting reduces how much protected health information reaches a non-production environment in the first place, and de-identification handles what does arrive, shrinking both your exposure and the surface an auditor has to walk.
How data subsetting works in Tonic
Connect and enable subsetting
Point Tonic Structural at the production database you want to reduce, then turn on subsetting for the workspace.
Explore Tonic StructuralConfigure your subset
Configure the target tables, filters, and lookups yourself, or tell the agent what you're targeting and let it handle the setup and size estimates.
Check the relationships
Tonic reads the foreign keys your schema declares. Add virtual ones where a relationship isn't declared, and clear any circular dependencies it flags.
Run the generation job
Tonic builds the subset, applies your generators, and writes it to your destination database. Your team gets an environment they can start working in immediately.
Data subsetting questions
Data subsetting reduces a database to a representative sample of its rows while keeping the relationships between them intact. You choose one or more target tables and a filter, and the process follows foreign keys to collect every record those rows depend on.
Not in Tonic. Poorly implemented subsetting can, which is why naive row sampling produces broken test databases. Tonic's traversal takes every row a target row references, upstream and downstream, so no foreign key ends up pointing at nothing. Where your schema doesn't declare a relationship, a virtual foreign key makes it visible.
No. The percentage applies to the target table only. Related tables contribute whatever those rows require and lookup tables copy in full, so a five percent target routinely yields well above five percent of the total. Row count and storage size also move independently — check both.
Subsetting works with the relational, NoSQL, and application database connectors. Data warehouse and Spark-based connectors — Snowflake, BigQuery, and Redshift among them — don't support it, and use table filtering instead, which applies a WHERE clause per table without traversing relationships between them.
