Synthetic Data Studio — Realistic Test Data in Your Own Schema

Everyone building software needs realistic data and nobody is supposed to use the real thing. So it gets improvised: a loop around a fake-name library, a spreadsheet somebody made in 2019, or — far too often — a slice of production on a laptop.

This is the tool that was meant to exist instead. It generates coherent businesses: six of them, each structurally different, each configurable down to the column names, and each checked against its own rules on every run.

Three things make it different from a loop around a fake-name library.

The same seed gives the same data. Every number comes from a seeded generator; nothing reads the clock, nothing calls Math.random. Run it twice, on two machines, a year apart, and the files are byte for byte identical. That is what turns generated data into test fixtures: your fixtures become a one-line command instead of a large file in the repository, and a failing test can be reproduced exactly by anyone who knows the seed. Streams are independent too, so generating ten more products does not change a single customer — a configuration change produces a diff the size of the change rather than a total one.

The data agrees with itself. Every foreign key resolves. Order totals equal the sum of their lines, and tax is charged on the discounted subtotal. A refund never exceeds what was paid for the line it refunds. A bank ledger's running balance reconciles to the cent, every transfer sums to zero, and no account passes its overdraft limit. A subscription stops being invoiced the month it is cancelled. A compensation history has no gaps and no overlaps and exactly one current row. Those are not claims in a README — they are checked on every run, and the suite that checks them ships with the product so you can point it at your own settings and run it in CI.

It can be dirty on purpose. Clean data tests nothing, and the bugs you are hunting all live in the handling of data that is not clean. Turn on the messiness dial and you get the specific problems real data arrives with: names that went through a spreadsheet and came out shouting, a postcode that lost its leading zero to something that read the column as a number, the same customer entered twice with a typo in the surname, three date formats in one column, mojibake from a file read as the wrong encoding. And every single change is recorded in a manifest — table, row, column, what was done, what the value was before — so you can score your cleaning pipeline against an exact answer key instead of eyeballing it.

The fields are the shape you say they are. Renaming a column does not help if the value inside it is the wrong shape, and loading the data into your columns is usually the whole point. So set the pattern — `ACC-######`, `SKU-@@@-####`, a UUID, ten unambiguous characters with no I, O, 0 or 1 — along with the length, the range, the null rate. Reshaping a primary key rewrites every foreign key pointing at it, so the references still resolve and the integrity check proves it. Ids generated this way cannot collide, because each row index is mapped through a permutation of the pattern's value space rather than filled with random characters; and if your pattern is too small for the rows, you are told the two numbers instead of being handed a duplicate key.

Or declare your own tables entirely. Nobody's schema is retail with the columns renamed. An insurer has policies and claims, a school has enrolments, a utility has meters and readings. Write your tables and fields in JSON — types, formats, ranges, vocabularies, relationships — and get data for them with the same guarantees: deterministic from a seed, every foreign key resolving to a real parent row, no child dated before the parent it belongs to, and the same messiness pass and integrity suite running over your columns.

The six models are different shapes, not different column names. Retail is discrete transactions in a star schema. SaaS is state over time — subscriptions, plan changes, monthly invoices that stop the month someone leaves. Healthcare is episodes hanging off a person, with age-appropriate conditions and clinically plausible vitals. Banking is an append-only ledger that has to balance. Logistics is an event trail where the order is the meaning. Workforce is slowly-changing records with contiguous compensation intervals. Code that copes with all six has met most of the shapes it will meet in production.

Making it your business takes a few lines. Replace the vocabularies and the data starts to read like your company — your product categories, your plan names, your departments. Rename columns to match your schema, drop the ones you do not have, add computed ones you do. Set exact row counts per table, the date window, the growth curve, the country. And when the business logic itself is what you are testing — an invoice that must equal the sum of its lines — write a model: one file, about two hundred lines, and the engine has no list of models built into it.

On privacy, the distinction that matters. Anonymised data starts as real data about real people and has identifying details removed — a process that can fail, and does, because the identifying power of a record is not in the name. Synthetic data never had a person behind it. There is no source record, no mapping, and nothing to re-identify. Names are common ones combined at random, every email is on a reserved example domain that cannot reach a mailbox, card numbers fail every scheme's check digit deliberately, and the clinical model emits its own codes rather than pretending to be ICD-10 or SNOMED.

Zero dependencies, no build step, no network access at any point. A million rows takes about fifteen seconds. The demo on this page is the product: the generator running in your browser is the code in the download, unmodified.