Scope and boundaries#
A tool is easier to trust when it says plainly what it does not do. This page is the honest boundary of the thing.
Who it is for#
The intended user has a database they did not design, or designed long enough ago that they no longer hold it in their head, and needs plausible data in it to work against. In practice that covers:
A developer joining an existing project who needs a populated local database before anything else makes sense.
A team standing up a staging or demo environment that must look real without containing anything real.
Anyone writing integration tests against an actual schema rather than mocks.
Anyone asked to demonstrate a system to an outside audience without exposing a single genuine customer record.
When it is the wrong tool#
It earns nothing on a schema small enough to fixture by hand in an afternoon. Three tables with obvious columns do not need reflection, classification, and code generation; they need twenty lines of setup and less ceremony.
It is also the wrong choice when the requirement is statistical fidelity: data whose distributions, correlations, and edge-case frequencies match a real production dataset closely enough to support analytics work or model training. This tool produces structurally valid, plausible data. That is a different guarantee, and the distinction matters if the tests being written are about data science rather than software behaviour.
What it is not#
Not statistical or machine-learning synthesis. It does not learn the distributions of an existing dataset and reproduce them. Values are plausible for their column, not fitted to your data.
Not an anonymiser or masking tool. It never takes production data and makes it safe. It generates from structure instead, which is a different answer to the same underlying worry. If you have a legal obligation to work with masked production data specifically, this does not discharge it.
Not an ETL pipeline. It does not move, transform, or migrate data between systems.
Those are separate products with separate risk profiles. Keeping this scope narrow is the reason the claims that remain are dependable.
Known limits worth stating#
Classification is heuristic. It reads names and structure, so a column whose name conveys nothing useful gets a generic generator, and an unconventional naming scheme degrades results. This is why the output is editable source code rather than an opaque service: correcting a wrong guess is meant to be a one-line edit.
Cyclic foreign keys have no valid topological ordering by definition. The tool terminates and produces an order rather than refusing to run, which is the right behaviour for a tool aimed at schemas it has never seen, but for a genuine cycle that order cannot satisfy every constraint at once. SQLAlchemy covers the mechanism and its limits.
Supported engines are SQLite and PostgreSQL today. Installation has the current details.
Read The problem with test data for why this problem is harder than it looks, or The approach taken for how the tool answers it.