Five minutes from schema to seeded local DB

The friction

You sit down to bring up a local dev database. You need real-ish data in it. Your options: a seed script that hasn’t survived the last three schema migrations, a fixtures.yaml somebody checked in two years ago that references tables that no longer exist, a seed.sql that only runs on one person’s machine, or nothing. Most teams pick nothing and hardcode IDs.

We built SynthForge to skip all of that. Paste your schema, generate a dataset, run one command. Populated local DB in five minutes.

Hand SynthForge your schema

You already have the DDL. Paste it at /schemas/create/sql. Five explicit dialects (Postgres, MySQL, SQLite, SQL Server, MariaDB) plus auto-detect as the default. The parser is deterministic, no LLM in the loop, and CockroachDB comes in on the auto-detect path as a Postgres-compatible syntax.

You can describe it in plain English. /schemas/create/ai is a single text box. Describe your tables and relationships; the AI agent emits a schema you can edit before you ever generate data.

You want a starting point. /schemas/create/template has pre-built schemas for common shapes (e-commerce, healthcare, SaaS). Pick one and customize.

You want to draw it. /schemas/new opens the visual editor directly.

Generate the dataset

Open “Generate dataset” from your schema. The form renders in this order:

Dataset name (optional). Then row counts. Top-level tables take a plain number. Child tables (any table with a foreign key pointing up to a parent) get a mode toggle: fixed count or per parent row. That toggle is what we wrote about in the cardinality post; you set “8 to 12 orders per customer” and SynthForge derives the child count. For M:N junction tables, the structure autodetects and the form picks a sensible larger-side driver.

Below the row counts, the form shows a live memory estimate. If it climbs too high, the Generate button disables and the banner tells you why.

Output formats come next. Pick CSV. That’s the format that ships the SQL loader scripts. Parquet and JSON are there too, but they won’t seed a SQL database.

Hit Generate. First run after a quiet period adds a couple of seconds while the container wakes. If you’ve been working in the editor for the past few minutes, it’s already warm and the job starts without the pause.

What you download

A zip. For a three-table schema it looks like this:

my-dataset.zip
├── csv/
│   ├── users.csv
│   ├── orders.csv
│   └── order_items.csv
├── import_postgresql.sql
├── import_mysql.sql
├── import_sqlite.sql
├── import_sqlserver.sql
├── import_mariadb.sql
├── import_duckdb.sql
└── import_cockroachdb.sql

One loader script per supported engine, seven total. To seed a local Postgres:

unzip my-dataset.zip && psql mydb -f import_postgresql.sql

The tables land in synthforge_import, not in mydb’s default schema. That is deliberate. The script creates that namespace, works only inside it, and drops only the tables it put there, so you can point it at a database you care about without auditing it first. Want the tables somewhere else? Find and replace synthforge_import in the script before you run it.

Each script runs the same way: drop its own tables in reverse-dependency order so children go before parents, create them in dependency order, load csv/{table}.csv, and make sure every foreign key is in place. Some engines let a foreign key be declared as part of CREATE TABLE. Others need a trailing ALTER TABLE ADD CONSTRAINT. The script does whichever the engine you picked actually supports, so it is worth reading the one you got rather than assuming. Either way the rows are referentially valid before they reach you, because child keys were sampled from parent IDs that already existed at generation time.

Why CSV plus COPY

COPY FROM (or your engine’s equivalent: LOAD DATA, .import, BULK INSERT) is considerably faster than a stream of per-row INSERT statements on any non-trivial load. How much faster depends on the engine, the row width, and your hardware. People who care already know this.

The CSVs are also portable. All seven loader scripts point at the same files. Generate once, hand the zip to a teammate on a different stack, and they run their own loader without touching the data.

The DDL travels with the artifact too. Each loader script creates its tables before it loads anything. No separate schema file, no versioning question, no drift.

If you want a single INSERT-statement dump you could replay against a running instance, pg_dump --data-only is the right tool. That’s not what this is.

The one gotcha: the download cap

Rows are not usually what stops you. A dataset holds up to 1,000,000 of them, and every table counts toward that one number. What you are more likely to meet first is the 200 MB cap on the generated download.

Whether you hit it depends entirely on how wide your rows are. Five integer columns is 40 bytes a row, and a million of those is a small file. A 25-column table carrying free text lands near 365 bytes a row in the zipped artifact, which reaches 200 MB at around 575,000 rows. Same row count, wildly different file.

Speed is not the constraint it used to be. A typical 15-column business table generates 200,000 rows in about 12 seconds. A 25-column table with free-text columns does 500,000 in about 40. A million rows of plain scalar columns is a matter of seconds, not minutes.

The editor tells you before you spend the time: an oversized request turns the estimate into a warning, and past a hard ceiling the Generate button disables. Narrowing a wide column’s max_length usually brings the estimate down faster than cutting row counts. For volumes past a million rows, split across several jobs and concatenate the CSVs.

The free tier

5 GB stored per account, two generation jobs running concurrently. No credit card required.

Try it

Start at app.synthforge.io and open /schemas/create/sql to paste your DDL. The full feature surface is on the data generation page.