Your fixtures rot because they encode yesterday's schema. So I regenerate mine — deterministically.

#postgressql #prisma #cli #opensource

Two moments broke me on hand-written seed data.

The first: fresh clone, migrations pass, app boots — and every screen is blank, because a database with perfect structure and zero rows can't show you anything. So you hand-write INSERTs in dependency order, or a Faker script, and the script promptly references a user that doesn't exist.

The second, worse one: CI. Integration tests need a seeded DB, and they need the same DB every run or the suite goes flaky. Hand-written fixtures deliver the opposite — they're frozen at whatever the schema looked like the day you wrote them, and every migration after that is a fixture-maintenance tax.

Both problems have the same root cause: the data is hand-maintained while the schema keeps moving. So I built a CLI that regenerates the data from the schema, deterministically. It's called Veriseed, and I want to be precise about what's shipped versus what's a bet.

What's actually live today (free, open source)

One command: npx veriseed seed --schema ./prisma/schema.prisma → a single transactional SQL file (BEGIN; … COMMIT;) for Postgres
FK-correct by construction: tables are topologically ordered (parents before children) and every child FK is picked from parent keys that were actually generated — no orphans
Deterministic: --seed 42 (the default) → byte-identical SQL on every run, regenerated from your current schema. Commit the command, not the fixtures — they can't rot, and CI stops flaking
Volume: --rows 50000 if you want to see your pagination and N+1s at something like real scale — I've verified 200k INSERTs across a 4-table schema in ~2.6s, locally
Parses Prisma (@id, @relation, @map/@@map, enums, optionals, @default), light lookup-based locale coherence (name, city, country agree within a row)
Zero dependencies, no account, no API key; once installed it runs offline

npx veriseed demo
npx veriseed seed --schema ./prisma/schema.prisma --rows 500 --seed 42 --out seed.sql

To be equally clear about what Core is not: the values aren't AI-realistic. The coherence is lookup-based, not generative. What you get is structurally correct, reproducible data — which turned out to be what my actual problems needed.

"Can't I just ask an AI chat for this?"

For a one-off sample to eyeball — yes, honestly, and you don't need my tool for that. A chat LLM will even produce more lifelike values than my Core does. Where chat falls over is exactly where this tool starts: it truncates past a few dozen rows, it invents parent IDs that don't exist, it gives you different data every ask (hello flaky CI), and it can't run unattended in a pipeline. If your seeding is one-off and small, use chat. If it's repeated, structural, or at scale, that's what Veriseed is for.

"Isn't this just Faker plus a toposort?"

Mostly, yes — and that glue is exactly what you keep rewriting. Faker has no schema awareness: you write the toposort, the FK-value-picking from generated parent PKs, the per-row coherence, and a fresh script per schema — then patch it all after every migration. Veriseed does that from the schema, deterministically, as one transactional file. The value is the glue, not AI magic.

The bet I'm validating: Pro

Core doesn't mask PII, doesn't subset a big graph into a referentially-intact slice, and doesn't do deep realism. That's the Pro layer — designed to run on a local model, keeping everything on your machine. Can a local model clear a usable realism bar? Unproven — that's literally what the $19 founding pre-order funds me to find out. It locks the founding price (planned $38 at launch) and is fully refundable if it doesn't ship. I'd rather tell you that than fake a demo.