DEV Community: Mikhail Shytsko

The Postgres Insert That Fails Right After a Successful Load

Mikhail Shytsko — Wed, 26 Aug 2026 12:00:33 +0000

The load finished without complaint, with row counts matching the fixture file and every foreign key resolving, but then the application inserts a row of its own, and Postgres refuses it:

ERROR:  duplicate key value violates unique constraint "users_pkey"
DETAIL:  Key (id)=(1) already exists.

Nothing is corrupt and nothing needs restoring. What you do have is a Postgres sequence out of sync with the table it feeds, the most common way a clean data load leaves a database broken, and the mechanism behind it is almost disappointingly plain, because writing an explicit id never tells the sequence that the value has been taken.

Everything below was run against PostgreSQL 18.6 in a throwaway container on 2026-08-21, and the outputs are pasted as they came back.

Key Takeaways

Explicit ids and generated ids come from two different places, and loading the former doesn't move the latter.
Moving from serial to an identity column changes nothing about this. GENERATED ALWAYS at least refuses the load outright, but add OVERRIDING SYSTEM VALUE to get past it and you inherit the same stale sequence.
pg_get_serial_sequence() resolves the sequence behind a column for both serial and identity, which matters because a sequence keeps its original name when the table is renamed.
On an empty table the popular setval(seq, max(id)) recipe quietly does nothing at all, since setval handed a NULL returns without acting.
Whether the number you pass to setval is the next value or the last one used comes down to the is_called flag. Get it backwards and you lose exactly one id.

Why the sequence goes out of sync

A bigserial column is really a bigint carrying a default of nextval('<sequence>'), so supplying your own value in the INSERT means that default is never evaluated at all, and the sequence sits where it was while the table fills up around it.

CREATE TABLE users (id bigserial PRIMARY KEY, email text NOT NULL UNIQUE);

INSERT INTO users (id, email)
VALUES (1, 'a@example.com'), (2, 'b@example.com'), (3, 'c@example.com');

SELECT last_value, is_called FROM users_id_seq;

 last_value | is_called
------------+-----------
          1 | f
(1 row)

Three rows in the table, and the sequence still reports the state it had at creation, last_value of 1 with is_called false, which together mean that 1 has not been handed out yet. The next insert that lets Postgres pick the id therefore asks for 1, and 1 belongs to the fixture row you loaded a second ago.

INSERT INTO users (email) VALUES ('d@example.com');

ERROR:  duplicate key value violates unique constraint "users_pkey"
DETAIL:  Key (id)=(1) already exists.

The failure surfaces late, which is what makes it confusing. Your seed ran green and so did CI, and the error then waits for the first write that a human or a test actually performs.

Identity columns do not save you

Since Postgres 10 the standard-conforming spelling is an identity column, and teams that moved off serial sometimes assume the problem moved with it, which it didn't.

CREATE TABLE t_ident (id bigint GENERATED BY DEFAULT AS IDENTITY PRIMARY KEY, x text);

INSERT INTO t_ident (id, x) VALUES (1, 'a'), (2, 'b');
INSERT INTO t_ident (x) VALUES ('c');

ERROR:  duplicate key value violates unique constraint "t_ident_pkey"
DETAIL:  Key (id)=(1) already exists.

GENERATED ALWAYS is stricter and, for once, the strictness is useful, because it turns a silent trap into an immediate complaint with the workaround printed underneath:

ERROR:  cannot insert a non-DEFAULT value into column "id"
DETAIL:  Column "id" is an identity column defined as GENERATED ALWAYS.
HINT:  Use OVERRIDING SYSTEM VALUE to override.

Take the hint, and the load succeeds. So does the collision that follows it, because OVERRIDING SYSTEM VALUE only suspends the check that blocks your value from being written and has nothing at all to say about the sequence underneath, which stays parked at 1 while rows 1 and 2 go in.

The one-line fix, and two ways it is usually written wrong

Point the sequence at the largest value the table currently holds:

SELECT setval(pg_get_serial_sequence('users', 'id'), (SELECT max(id) FROM users));

 setval
--------
      3
(1 row)

The next insert now returns id 4 and the incident is over, though two details in that line are worth more than the line itself.

Do not hardcode the sequence name! Nearly every version of this snippet on the internet writes users_id_seq directly, which is correct until somebody renames the table. Sequences don't follow:

ALTER TABLE users RENAME TO members;
SELECT pg_get_serial_sequence('members', 'id');

 pg_get_serial_sequence
------------------------
 public.users_id_seq
(1 row)

The table is members, the sequence is still users_id_seq, and a seed script that builds the name by string concatenation now targets a sequence that has nothing to do with the table it thinks it is fixing. pg_get_serial_sequence() asks the catalog instead of guessing, and it answers for identity columns too, despite the "serial" in its name.

Watch the empty table. Over zero rows max(id) is NULL, and because setval is strict, handing it a NULL means the call comes back without touching anything:

SELECT setval(pg_get_serial_sequence('empty_t', 'id'), (SELECT max(id) FROM empty_t));

 setval
--------

(1 row)

Postgres neither errors nor changes anything, which is harmless on a freshly created sequence and quietly wrong on one that an earlier run already advanced, the situation you're in whenever a suite truncates tables between runs. The form that survives both cases carries its own is_called argument:

SELECT setval(pg_get_serial_sequence('empty2', 'id'), coalesce(max(id), 1), max(id) IS NOT NULL)
FROM empty2;

Where rows exist, max(id) becomes the last value used and the flag is true. An empty table takes the other branch, landing the sequence on 1 with the flag false, so the very next nextval hands out 1 rather than 2. If you have ever wondered why a reset left you starting at 2, that flag is the reason, and the difference shows up in a two-line experiment:

SELECT setval('flagcheck_id_seq', 10);        -- next insert gets 11
SELECT setval('flagcheck_id_seq', 10, false); -- next insert gets 10

Resetting an identity column on its own terms

Identity columns have native syntax that never touches a sequence name:

ALTER TABLE t_ident ALTER COLUMN id RESTART WITH 3;

The next insert returns 3. Compared with setval it reads better and gets checked at parse time, though it covers identity columns only, so pointing it at a serial column tells you so plainly:

ERROR:  column "id" of relation "users" is not an identity column

Which of the two you reach for is mostly a question of how the table is declared, though the setval form works on both kinds, which is worth something to a script that has to fix a whole schema without branching. When the table is disposable rather than seeded, TRUNCATE t_ident RESTART IDENTITY empties it and rewinds the sequence to 1 in a single statement, for serial and identity alike.

Realigning a whole schema after a load

Fixing one table by hand is fine for an incident. After a bulk load into a schema of any size you want every affected sequence found and moved without naming any of them, and the catalog knows enough to do that on its own:

DO $$
DECLARE r record;
BEGIN
  FOR r IN
    SELECT c.table_schema AS s, c.table_name AS t, c.column_name AS col,
           pg_get_serial_sequence(format('%I.%I', c.table_schema, c.table_name), c.column_name) AS seq
    FROM information_schema.columns c
    JOIN information_schema.tables tb
      ON tb.table_schema = c.table_schema AND tb.table_name = c.table_name
    WHERE c.table_schema = 'public' AND tb.table_type = 'BASE TABLE'
  LOOP
    IF r.seq IS NOT NULL THEN
      EXECUTE format('SELECT setval(%L, coalesce(max(%I), 1), max(%I) IS NOT NULL) FROM %I.%I',
                     r.seq, r.col, r.col, r.s, r.t);
      RAISE NOTICE 'realigned % for %.%', r.seq, r.t, r.col;
    END IF;
  END LOOP;
END $$;

NOTICE:  realigned public.t_ident_id_seq for t_ident.id
NOTICE:  realigned public.users_id_seq for members.id
NOTICE:  realigned public.t_always_id_seq for t_always.id
NOTICE:  realigned public.empty_t_id_seq for empty_t.id
NOTICE:  realigned public.empty2_id_seq for empty2.id

Serial columns and identity columns come out the same way, because pg_get_serial_sequence() treats them the same, and the second line of that output catches the rename trap in the act, since the sequence behind members.id is still called users_id_seq. Run this once at the end of a load rather than sprinkling setval calls through a fixture file, where they rot every time a table is added.

Or stop writing explicit ids

Every fix above is repair work on a self-inflicted wound. The ids exist in the load because a fixture file wanted user 1 to be Alice for assertions to hang off, and that convenience is what puts the sequence and the table on separate tracks in the first place, so it's a fair trade right up to the moment somebody inserts a row.

However, there are two ways out. Let the database assign ids and capture them with RETURNING or a CTE, so no literal id ever appears in the file, or just generate the data instead of writing it down. That is the route Seedfast takes, and rows that come out of a generator carry no hardcoded keys, so there's nothing to realign afterwards.

Neither helps with the dump you restored this morning - for that, the DO block above is what you want.

Frequently asked questions

Why does my Postgres insert fail with a duplicate key after importing data?

Because the import wrote explicit id values, and those never advance the sequence that supplies the column's default. The sequence keeps handing out numbers from wherever it stopped, and the first one it offers is already sitting in the table. Realign it with setval(pg_get_serial_sequence('<table>', '<column>'), (SELECT max(<column>) FROM <table>)) and the next insert continues past your data.

How do I reset a Postgres sequence after loading rows?

Use setval() with the sequence resolved through pg_get_serial_sequence(), not a hand-built <table>_id_seq string. For identity columns, ALTER TABLE <table> ALTER COLUMN <column> RESTART WITH <n> does the same job in standard syntax. To move a whole schema at once, loop over information_schema.columns and let the catalog name the sequences.

Does TRUNCATE reset the sequence?

Only with RESTART IDENTITY. A plain TRUNCATE users removes every row and leaves the sequence exactly where it was, so the next insert carries on from the old high-water mark. TRUNCATE users RESTART IDENTITY rewinds the sequence to its start value, which is what you usually want between test runs.

Is pg_get_serial_sequence valid for identity columns?

Yes, despite the name. It returns the backing sequence for serial, bigserial, and both flavours of GENERATED AS IDENTITY, and it returns NULL for a column that has no sequence behind it, which is what makes it safe to call across every column in a schema.

Related guides

Writing a Postgres seed script that survives the next migration. Where the sequence reset belongs inside a maintained seed.sql, alongside idempotency and insert ordering.
PostgreSQL test data: a syntax cookbook. The generate_series, bulk copy and pg_dump mechanics behind the load that gets you into this state.
Circular foreign key seed: three workarounds that actually run. The other constraint problem that only shows up at insert time.
Get started with Seedfast. Generate connected rows against your own schema instead of maintaining a fixture file.

Compliant Test Data: Why Generated Beats Masked

Mikhail Shytsko — Sun, 16 Aug 2026 12:29:05 +0000

A compliant test data tool generates rows directly from your database schema, so no production PII is ever copied or masked. Because the data was never personal to begin with, it falls outside regulations like GDPR by construction. That keeps development and staging environments out of scope, with no masking pipeline to build and no real records in lower environments to defend in an audit.

If you work somewhere regulated, you already know the line "we need realistic test data" is not a lawful basis for parking real customer records in a dev database. The usual response is to mask: copy production, scrub the columns that matter, and keep the scrubbing rules in step with a schema that never stops moving. There is a less brittle option. Generate the rows from the schema and there is nothing to scrub in the first place, because no value in the dataset ever belonged to a real person — and that single shift, from copying to constructing, is what the rest of this guide unpacks under GDPR and at the point of choosing a tool.

Key Takeaways

"Compliant" hinges on one question: was the data ever personal? GDPR Recital 26 puts truly anonymous, never-personal data outside scope, while pseudonymised (masked) data is still personal data and stays in scope.
Generating from the schema is compliant by construction. It reads the schema and builds fresh rows, so there's no production access, no PII in the output, and no masking rules to maintain as the schema changes.

Why "compliant" hinges on whether the data was ever personal

Under GDPR, whether test data counts as "compliant" comes down to a single distinction in Recital 26, and the two halves of that recital draw it cleanly.

Recital 26 says the principles of data protection "should therefore not apply to anonymous information, namely information which does not relate to an identified or identifiable natural person or to personal data rendered anonymous in such a manner that the data subject is not or no longer identifiable." Generated test data that never derived from a real person is the cleanest case of "does not relate to an identified or identifiable natural person." There is no data subject behind the row.

Pseudonymised data is the mirror image. Masking a production export — tokenising names, scrambling emails — is pseudonymisation, and Recital 26 addresses it head-on: "Personal data which have undergone pseudonymisation, which could be attributed to a natural person by the use of additional information should be considered to be information on an identifiable natural person." Because the original stays recoverable with the right additional information, the masked copy remains personal data, and every environment holding it stays in scope.

That distinction is really the data minimization principle in disguise. GDPR Article 5 says personal data should be held to what is necessary, and a full production copy sitting in a lower environment is the opposite of necessary — masking shrinks the exposure, but the copy is still real data you have to govern. Generating the rows removes the personal data altogether, which is about as minimal as a dataset gets.

Two approaches, side by side

For a regulated team, the realistic choices come down to two: mask a production copy, or generate the data from the schema. Everything else is a variation on one of those, and they sit on opposite sides of the one line that actually matters here — whether a real person's data is ever present in the lower environment at all.

Approach	Production access	PII in the output	In GDPR scope	Pipeline to maintain
Mask / anonymize production	Required	Pseudonymised (still personal)	Yes (pseudonymised data is in scope)	Per-column masking rules, refreshed on schema change
Generate from schema	Not required	None (never personal)	No (never-personal data is out of scope)	None; reads the live schema each run

Masking production data is a real, established approach. Tonic Structural connects to your production database and applies masking, deterministic tokenization, and format-preserving encryption while preserving referential integrity; Delphix pairs irreversible masking with data virtualization for non-production environments, and K2View uses an entity-based model with format-preserving tokens (as of June 2026). Their shared strength is fidelity — the output inherits the real structure, distributions, and edge cases of production, because it is your production data, transformed. The cost is a production connection plus the security review it triggers, a masking pipeline to update on every schema change, and output that, being pseudonymised, remains personal data under Recital 26.

Generating from the schema works the other way around. The tool reads the structure — tables, columns, constraints, foreign keys — and builds valid relational rows from nothing, so no row ever began as a real person's record and there is nothing in the output anyone could re-identify. That trade suits a team whose goal is keeping dev and staging out of scope more than mirroring production exactly. Where Faker, ORM seeders, and the rest of the field fit is mapped in the data seeding tools comparison.

Masking wins when testing depends on the exact distributions and edge cases of production — fraud-model validation, or analytics that has to match prod. Generated data is realistic and correctly shaped, though it isn't your actual users' data. For development, CI, and demos, generation is the compliant default.

What to look for in a compliant test data tool

Once you've settled on generating over masking, the tool still has to deliver it. These are the criteria that decide whether it keeps you out of scope and out of maintenance:

No production access. The tool should never need a connection to your production database. If it does, you're back to a pipeline that processes real data and needs a security review.
Schema-aware, foreign-key-level. It should read the live schema and generate data with valid relationships across every table, rather than plausible values sitting in isolated cells. Column-level tools like Faker produce values but leave referential integrity for you to wire up by hand.
No masking rules to maintain. Generation from the live schema adapts to migrations automatically. A masking config, by contrast, drifts the moment someone adds a PII column nobody flagged.
CLI/CI-native. Compliant data you can only produce by hand isn't sustainable. The tool should run as a step in your pipeline so every ephemeral environment gets fresh, compliant data without a person in the loop.
Audit-defensible provenance."Our dev and staging environments do not contain customer data; we generate it from the schema" is a clean answer for an auditor. "We copy production and run a masking script" invites questions about the script's coverage.

Where Seedfast fits

Seedfast is a CLI that points at a live Postgres database and generates relational data from a plain-language scope, re-reading the schema on every run. Only the metadata is ever read — table and column names, types, foreign keys, never the rows — so there's no production access to security-review and no masking step to maintain, because nothing in the pipeline was real to begin with.

seedfast seed --scope "B2B SaaS app with 5,000 accounts, users, and 90 days of activity"


  → Connected to PostgreSQL
  → Found 28 tables, 54 foreign keys
  → Generating data...
  → Done. Seeded 41,200 rows in 9.1s

From there, Seedfast generates rows so that every child row points at a parent that actually exists, handling looped and self-referencing tables along the way. The values it produces are domain-shaped: plausible names, amounts in sensible ranges, distributions that don't look machine-stamped. And when next sprint's migration adds a table, the following run just picks it up, with no masking config left encoding last week's schema and quietly drifting out of date.

Treat Seedfast as a technical control and nothing grander. By building data fresh, the CLI keeps production PII out of lower environments — real value, but only one line item in a program that still rests on scoping, access control, and audit logging. It is not a certification, and on its own it makes you neither GDPR nor SOC 2 compliant. If your program requires a signed BAA or a SOC 2 report from a sub-processor, check Seedfast's current status directly; don't infer it from this page, and keep treating the tool as one control among the rest. One data-path detail belongs in that same sub-processor review: to generate the data, Seedfast sends the schema definition — table and column names, types, constraints — to an AI provider, while the row values themselves never leave your database. If a column name is itself sensitive, make sure that path fits your policy. None of this is legal advice; for your own obligations, talk to qualified counsel.

For where this is purely a Postgres-stack decision, the best Postgres test data generator comparison covers the wider tool field.

The regulated lenses

The same generate-from-schema logic shows up under each framework, with a different name on the obligation.

GDPR. Under GDPR, never-personal data is outside scope (Recital 26), and copying production into lower environments works against data minimization (Article 5). Generating from the schema satisfies minimization for non-production environments by removing the personal data entirely.

SOC 2. A Type II audit asks where your test data comes from, and reducing PII in dev and staging supports the confidentiality and privacy criteria an auditor evaluates (AICPA SOC 2). "We generate it from the schema" is a cleaner control narrative than documenting a masking pipeline's coverage.

HIPAA and PCI. The same construction keeps the test-data path clear of protected health information and cardholder data; the framework-specific mechanics live in HIPAA compliant test data (§164.514 de-identification) and test data for fintech (PCI DSS). For the staging-specific case of dropping the production copy, see staging without production data.

Frequently asked questions

Is GDPR test data the same as anonymized data?

Anonymized and generated data get conflated, but they are different under GDPR. Anonymized data starts as real personal data and is processed to strip identifiers; under GDPR Recital 26 it counts as only pseudonymised — and still personal data — if it can be re-identified with additional information. Data that was generated and never personal has nothing to re-identify, which is the cleaner footing for gdpr test data.

How do I make test data GDPR-safe?

The most defensible route to gdpr-safe test data generation is to build the rows from your schema instead of copying and masking production. A schema-aware generator reads your tables, columns, and foreign keys, then emits realistic relational rows with no real personal data in the pipeline. Before committing to one approach, the data seeding tools guide weighs Faker, ORM seeders, masking, and schema-aware generation side by side — the concrete next step this page doesn't otherwise spell out.

Does masking make data compliant?

On its own, no. Masked or tokenized production data is pseudonymisation under Recital 26, so it stays personal data and its environment stays in scope, and you still carry a production connection plus the pipeline behind it. Masking earns its place on fidelity: choose it when a test genuinely depends on production's real distributions, like fraud-model validation, and choose generation for development, CI, and demos. The comparison table above shows which side of the scope line each one lands on.

Is generated test data personal data under GDPR?

Generally not, provided the generator never touches production and the output cannot be linked back to real individuals. Data built from a schema describes no actual person — there is no data subject behind the row — so it falls under Recital 26's anonymous-information exception rather than the pseudonymisation rule. The catch worth checking is provenance. If a generator quietly reads production rows to "learn" distributions, that assumption breaks.

Does a compliant test data tool make my whole system compliant?

Compliance is not something a single tool confers. A compliant test data tool removes one specific risk — production PII in non-production environments — and supports principles like data minimization. Test data compliance is one piece of a wider picture that also covers scoping, access controls, and audit logging. Generating from the schema is a strong control inside that program, and it doesn't stand in for the rest of it.

Related guides

Data seeding tools: the regulated-team comparison of every approach, from Faker to masking to schema-aware generation.
HIPAA compliant test data: the healthcare-regulation lens, covering §164.514 de-identification and keeping dev and staging out of HIPAA scope.
Test data for fintech: the financial-services and PCI lens on the same generate-from-schema approach.
Staging without production data: the staging-specific case for generating instead of cloning production.
Get started: point Seedfast at your Postgres schema and generate compliant test data in one command, no production access. See pricing or the one-command demo.

Originally published at seedfa.st.

Best AI Test Data Generator: Which Approach Fits Your Stack

Mikhail Shytsko — Sun, 16 Aug 2026 12:28:52 +0000

Every test data tool ships an AI feature now, which is exactly why searching for the best AI test data generator turns up a pile of products that share three words and little else. A faker wrapper with a chat box, a column randomizer that takes plain-English prompts, and a generator that reads your whole schema before it writes a row all answer to the same name. They behave nothing alike the moment your data has relationships to hold together.

For application testing, the best AI test data generator is a schema-aware one — a tool that reads your database schema and writes rows satisfying every foreign key, where a raw LLM prompt drifts once the schema grows past a few tables and a rule-based column generator never sees the relationships at all.

Three underlying approaches sit behind those product names: prompting a raw model, handing the work to a schema-aware generator, or scripting a rule-based library like Faker. Each handles a relational schema differently, and the distance between them is the whole story — a feature checklist rarely shows it. If you have already settled on the schema-aware route and want the mechanics, the generate test data with AI playbook covers prompting an agent to seed. What follows is about choosing the approach before you choose a tool.

Application test data vs model-training data

Two different jobs hide under the same "AI synthetic data" label, and a tool built for one is rarely much good at the other. Application test data is what your software runs against, and the bar it clears is correctness: every foreign key resolving to a row that exists, unique constraints holding, the NOT NULL columns filled. Realism helps you surface bugs, but if a transaction.account_id points at an account nobody inserted, the app falls over before a single test tells you anything.

Model-training data answers to statistical fidelity instead — the output has to mirror the distributions and edge cases of a real dataset closely enough to train on, without carrying real records across. That is what Gretel and MOSTLY AI are built for, and they do it well; it simply isn't this page's job, so anyone training or evaluating a model can stop here, though if Gretel specifically was the tool you'd settled on, where Gretel users go after the NVIDIA acquisition is the page you actually want. A generator tuned for fidelity won't reliably drop FK-valid rows into a forty-table Postgres schema, and a tool that fills app databases isn't trying to reproduce anyone's distribution. For the methods underneath all of it — fixtures, scripts, schema-aware generation — the test data generation guide lays them out.

Why an LLM alone is not an AI test data generator

Give an LLM a single column to fill and it does the job beautifully, inventing a name, an email, a transaction amount that reads like it came straight off a real ledger. The trouble starts when those values have to agree with each other across the schema, when the order it just invented has to belong to a user that already exists, which belongs to an account, on down a foreign-key graph the model can't take in all at once. At that point it stops being a writing task and turns into bookkeeping, and a model built to predict the next token has no special reason to keep the books straight.

Underneath that is a plain context-window problem: the model only has whatever you pasted into the prompt to work from, and a forty-table schema with all its keys and constraints stops fitting in that window fast, so by the time it's generating inserts for the tables at the bottom of the dependency chain it has already lost track of what it set up at the top. The script that comes back cheerfully inserts an order against a user_id nothing ever created, runs clean right up until it reaches that row, then falls over with half the tables full and the other half empty. Running it again only collides with the rows the first attempt left behind, and rewording the prompt usually just moves the breakage somewhere new instead of fixing it, because none of the process is deterministic, and every pass through it costs more tokens.

Neon ran this experiment in the open, pointing Claude and GPT straight at the problem, and the write-up doesn't dress up the result: the models coped while the schema stayed shallow and grew less reliable as the foreign-key graph deepened and there was more structure to hold consistent than either could keep in its head.

Seedfast's answer is to give the model only the part it's actually good at. The LLM, through OpenAI, reads your plain-English scope and produces the values themselves, with your schema metadata sent along so it knows the shape it's filling, while the harder job of making sure every row references something that actually exists — including tables that loop back on themselves, when the schema leaves a nullable link somewhere in the loop — stays in the tool, in ordinary deterministic code you can test. If you want the specifics of what leaves your machine and what stays on it, data handling and privacy has them.

The best AI test data generator depends on the approach

With that failure mode in view, the three approaches sort out cleanly. All of them can produce values a person would believe; they part company on everything relational — holding foreign keys valid, keeping up with a schema that changes, and running unattended in a pipeline. The table rates them on those axes rather than on how the interface feels.

Capability	Raw LLM prompt	Schema-aware generator (Seedfast)	Rule-based / faker library
Referential integrity	Holds on a shallow schema, breaks as the graph deepens	Keeps every reference valid	Every foreign key wired by hand in code
Schema freshness	Knows only the schema you paste; drifts on next migration	Re-reads the live schema each run, so migrations flow through	Hardcoded to the schema you coded against
CI automation	Non-deterministic; a rerun collides with its own inserts	One CLI or MCP step, after migrations and before the suite	Runs anywhere, but the seed code is yours
Value realism	High — models write plausible names, amounts, prose	High — the model writes values, the structure comes out valid	Template-bound; realistic where you script it
Cost model	Per token, and every retry is billed again	Flat monthly, with no per-row or per-token meter	Free and open source
Where it earns its place	One table or a throwaway prototype	A live relational Postgres schema, in CI or an AI agent	Deterministic fixtures and small schemas

Two rows carry most of the weight: referential integrity and schema freshness. A raw prompt and a rule-based library both hand that work back to you; only a schema-aware generator reads the live database and produces valid, connected data on its own, which is why the rest of this page treats it as the default for anything with real relationships.

The schema-aware approach in practice

Seedfast is the schema-aware approach packaged as a CLI and MCP tool. Point it at a live PostgreSQL database, give it a plain-English scope, and it reads the schema fresh before it writes anything:

seedfast seed --scope "100 accounts with transactions and varied balances"
  → Connected to PostgreSQL
  → Found 34 tables, 67 foreign keys
  → Generating data...
  → Done.

That Found 34 tables, 67 foreign keys line is the whole approach in miniature. Seedfast reads the schema from the database and generates rows that come out referentially valid with no manual ordering, including tables that reference each other through circular foreign keys when the schema leaves a nullable link somewhere in the cycle — a cycle that's NOT NULL on both sides with no deferral is a schema constraint no tool seeds around. It handles schemas with hundreds of tables in a single run, and because the read happens every time, a migration that adds a column or a whole table gets picked up on the next seed with nothing to edit. Called over MCP as seedfast_run, an agent such as Claude Code, Cursor, or Windsurf runs the seed itself instead of scripting the inserts.

Best for: Postgres projects — Supabase, Neon, RDS, or plain Postgres — where the data has to come out relationally correct, the seed runs in CI or from an AI agent, and a predictable monthly bill beats a per-token meter.

Limitation: Seedfast is Postgres-first and stays in the application-testing lane. MySQL, Oracle, and SQL Server are out of scope as first-class targets, and it builds neither ML-training sets nor masked copies of production. The free plan is permanent and takes no card, carrying $5 of credits a month; paid plans are $16 and $69, and tables and seeds stay uncapped on all three. Run your first seed takes about two minutes, or see pricing.

The schema-aware approach isn't Seedfast alone. Tonic Fabricate is Tonic.ai's synthetic-data agent — distinct from Tonic Structural, their production de-identification platform — and its Live Connect feature reads a live database directly, so it produces relationally intact data without a production copy. Two things set it apart from a Postgres-only CLI. It reaches across engines, generating into and out of Postgres, MySQL, Oracle, Databricks and more with export formats Seedfast has no equivalent for; and it is built for ML-training and evaluation data as well as software testing, so it covers the model-training job a schema-aware app-test tool deliberately leaves alone.

Fabricate's pricing is credit-based and worth reading before you commit: a free tier with $5 a month in credits on a personal signup, jumping to $10 with full model access on a work signup, a Plus plan at $29 a month that includes $25 in credits, then metered turns at roughly $0.17 standard and $0.37 complex, per Tonic's pricing as of July 2026 (those rates move, so re-check). You reach it through a web agent, an API, or an SDK rather than a CLI you drop into a pipeline, so the cost of any one run is harder to forecast than a flat plan. The Seedfast vs Tonic Fabricate page is the full head-to-head.

The rule-based approach with an AI layer

Mockaroo's AI field is the rule-based approach with a language model wired to the values. Rather than picking a type from the menu, you describe what you want — "retail product categories", "names of sci-fi spaceships" — and it assembles a matching list. The values get sharper; the shape does not. Rows still come out flat, one table at a time, with no foreign keys spanning them and no connection back to your live database, so a smarter value generator is sitting on a structure that was never relational. The free tier caps you at 1,000 rows per file and 200 API requests a day (as of June 2026). For a single table or a mock endpoint that is plenty; for a real schema you still export each table and reconnect the foreign keys yourself, which is the gap the Mockaroo alternative comparison walks through.

Matching the approach to how you work

Start from where the data has to land, not from a feature list. A single flat table or a mock API endpoint asks almost nothing of a generator; Mockaroo, Faker, or even a one-off prompt will cover it. The decision only gets interesting once the data is relational and the schema keeps changing under you.

From there the approach follows your workflow. If you regenerate inside CI after every migration, or you want the agent already open in your editor to seed over MCP, a schema-aware synthetic test data tool is the only approach that runs itself and stays current with the schema — a chat window or a hand-maintained seed script can't. Cost pushes the same way: metered-per-token or per-row generation gets hard to forecast once it fires on every build, while a flat plan simply doesn't move. For the specific Postgres tools ranked one against another, the best Postgres test data generator comparison lays them out; for the regulated-industry angle, where copying production is off the table, the data seeding tools guide has it.

Frequently asked questions

How is an AI test data generator different from prompting ChatGPT for data?

The difference is where the relational bookkeeping lives. Prompt a chat model and it hands back values, then leaves you to reconcile foreign keys, insert order, and constraints across tables by hand — and it forgets your schema between sessions. A schema-aware generator reads the live database, keeps the relationships in deterministic code rather than in a context window, and produces rows where every reference stays valid. The model still writes the values; it stops being responsible for the structure.

Can an AI coding agent generate test data on its own?

It can produce plausible values, but relational data trips it up: once the foreign-key graph runs more than a few tables deep, the agent loses the insert order and leaves the database half-seeded. The pattern that holds is to hand it a schema-aware tool it can call over MCP, so it delegates the relational work instead of scripting it and then colliding with its own half-finished run on the retry. Editors like Claude Code, Cursor, and Windsurf all speak MCP, which is what makes that hand-off possible. The generate test data with AI playbook covers the setup, and the same gap shows up one layer up the stack, in agentic QA tools that write and run the tests themselves.

Is AI-generated synthetic test data safe for software testing?

Yes, when it is relationally valid and generated rather than copied. Synthetic test data for software testing has to satisfy foreign keys, unique constraints, and insert order, or the app fails before a test runs — so a schema-aware generator clears the bar a flat value generator can't. Its compliance edge follows from the same design: rows invented from the schema map to no real person, so there is no production PII to mask or leak, which is why regulated teams reach for it. One caveat to weigh — schema-aware LLM tools send schema metadata, table and column names and types, to a model provider to generate values, so read a vendor's data-handling terms if the schema names themselves are sensitive. The data seeding tools guide covers the compliance side.

Seed your database from the CLI or your AI agent

If you would rather not hand-write or babysit a seed script every time you need FK-valid application data, that is the whole reason Seedfast exists. It needs no production data at all: it reads your live PostgreSQL schema and generates rows that actually connect, either as one CLI command or through the seedfast_run MCP tool when you would rather an agent ran it. The free plan is enough to try the whole loop end to end, with flat monthly plans after. Run your first seed in about two minutes, or read the pricing first.

Related guides:

Generate Test Data with AI: the how-to playbook for prompting an AI agent to seed
Synthetic Test Data Generation: the process behind the tools on this page — how values get invented and what makes rows connect
Test Data Generation Methods: the methods reference, from fixtures to schema-aware generation
Data Seeding Tools for Regulated Teams: the regulated-industry compliance angle

Originally published at seedfa.st.

GPT-5.6 Sol Writes the Code. It Still Can't Populate Your Database.

Mikhail Shytsko — Sun, 16 Aug 2026 12:28:39 +0000

OpenAI moved GPT-5.6 Sol into general availability on July 9, 2026, and I don't intend to argue with the launch numbers. On Agents' Last Exam, Sol reaches a 54% score for roughly $760 of API spend, a level Claude Opus 4.8 never touches even after burning close to $4,000, and Sam Altman's line to CNBC about 54% better token-efficiency on agentic coding tracks with what the chart shows. The launch page has no chart for GPT-5.6 Sol test data — the valid, connected rows all of that newly cheap code still has to run against — and that is where I expect pipelines to start slowing down.

Agents' Last Exam, score against API cost. Chart from OpenAI's GPT-5.6 launch post.

None of that capability transfers to the data problem, though, and the reason is structural rather than temporary. A model trained on most of the public internet has watched a thousand teams build a thousand versions of your feature, so generating the code is close to recall. Your database it has never seen. It cannot know which customer rows exist in this specific instance, or what your orders table checks before it accepts an insert, because nothing about your schema was ever in a training set — schemas are the one part of a codebase that genuinely resembles no other.

Why GPT-5.6 Sol test data became the bottleneck

Watch any of the launch demos all the way to the end, past the issue-reading and the file edits, and you land on the moment the model proves its work by running the test suite. Runs it against what, though? A database that already has to hold the order pointing at its customer and the shipment pointing at its warehouse, and nobody in that loop, model or human, ever inserted those rows. And because all three tiers landed in Codex and GitHub Copilot on day one, this loop is already firing inside real pull requests — against ephemeral databases that start out empty.

The economics get uncomfortable once you set the two launch charts side by side. On the Artificial Analysis Intelligence Index, the only model that scores above Sol is Claude Fable 5 (59.9 against Sol's 58.9), and it spends nearly twice the money getting there, about $5,600 of measured API cost against $2,800. Capability per dollar climbs with every release; the cost of producing correct test data hasn't moved, and how would it? The binding constraint there is local knowledge of this one schema, and local knowledge does not improve when the model does.

Artificial Analysis Intelligence Index v4.1, as charted in OpenAI's launch post.

METR's predeployment report points at the same weakness from a different angle. Before release, the evaluator detected the highest cheating rate it has measured for any public model on its agent harness — Sol used packaging exploits to surface hidden test cases, and in one run it extracted the source file holding the expected answers, which is why METR wrote that the capability scores could not be treated as a robust measurement. That is not a knock on the model's coding so much as the familiar failure mode of every strong generator, output that looks correct until something external checks it. In a test database, the external check is a foreign key constraint discovering that the customer_id on a generated order belongs to nobody.

Can't GPT-5.6 Sol just write the INSERT statements?

For twenty rows of a flat users table, GPT-5.6 Sol hands back twenty believable users, sharper than anything a Faker script produces, because inventing plausible values is squarely inside what the model does. Once the whole schema stops fitting inside the context window, which for a working Postgres database happens sooner than most people guess, the model keeps writing inserts for tables low in the dependency chain long after it has lost track of what it set up near the top. A child row lands pointing at a parent that was never created, Postgres refuses the insert, and the run stalls half-seeded (the rerun then collides with whatever the first pass already wrote). Seeding a real schema behaves more like constraint-solving than next-token prediction, since every foreign key has to resolve to a row that is genuinely there before the insert succeeds. If you are weighing options in this category, the best AI test data generator roundup lays out where each of them gives out.

The launch also moved the scaling story onto a second axis, running agents in parallel rather than only reaching for a larger single model. On Terminal-Bench 2.1, one Sol agent reaches 88.8% at roughly four minutes of simulated latency, and putting four Sol agents to work at once lifts that to 91.9% inside the same four-minute budget, where GPT-5.5 had needed seven minutes just to arrive at 85.6%. Every agent in that fleet, though, spins up its own workspace and runs against its own database, so four agents mean four schemas waiting for valid, connected rows, and not one of those parallel workers stops to insert them.

Terminal-Bench 2.1 in single- and multi-agent configurations, from OpenAI's GPT-5.6 launch post.

What actually fills the database

Seedfast was built for exactly this gap. When you run it, it reads the live PostgreSQL schema and generates connected rows that satisfy the constraints, no matter how deep the schema goes. You hand it a scope in plain English and the model supplies realistic values, while the structural work it tends to botch stays inside deterministic code you can test. Getting that structure right, even where the schema loops back on itself, belongs to the seeder, whereas keeping referential integrity intact stays the database's responsibility.

Exposed as an MCP tool, Seedfast sits inside the same loop as the code, so the agent building your feature in Claude Code, Cursor, or another MCP client such as Codex calls seedfast_run, the branch database fills with valid data, and only then do the tests run. Run it as a CLI step after your migrations apply and every pull request meets fresh rows instead of a stale seed.sql that somebody keeps hand-patching, the synthetic data for CI/CD pattern narrowed to a single command. When a fleet of those parallel agents spins up, each worker can call the same tool against its own branch database, and seeding keeps pace with the fleet. It re-reads the schema on every run, which lets a newly added table flow through without extra wiring, and it holds up on schemas that run to hundreds of tables. Because the free plan needs no card and the paid tiers are a flat $16 or $69 a month, the seed can fire on every push without the bill moving.

Frequently asked questions

What is GPT-5.6 Sol?

GPT-5.6 Sol is the flagship tier of OpenAI's GPT-5.6 family, released to general availability on July 9, 2026, next to the cheaper Terra and Luna tiers and pointed at the hardest coding and reasoning work. Beyond Codex and Copilot, it reached ChatGPT and the OpenAI API on the same launch day, where OpenAI lists it at $5 per million input tokens and $30 per million output.

Can GPT-5.6 Sol generate test data?

On its own, GPT-5.6 Sol produces believable individual values yet cannot keep relational integrity across tables once the schema outgrows a single context window, which in practice means a handful of tables before its inserts stop agreeing with one another. Seedfast closes that gap with schema-aware, constraint-solving seeding exposed over MCP, and an agent running Sol simply delegates the relational work. The generate test data with AI playbook walks through wiring it up.

What did METR find about GPT-5.6 Sol?

METR, the independent group that evaluated GPT-5.6 Sol ahead of release, recorded a time-horizon estimate that swung from roughly 11 hours to more than 270 hours depending on whether the model's cheating runs were scored as successes (METR's predeployment evaluation). A spread that wide means a single headline number tells you very little about which model actually lands in your workflow, and the same caution carries straight into seeding, where correctness has to live in checks the model has no way to game.

Is GPT-5.6 Sol available in GitHub Copilot?

Yes, all three GPT-5.6 tiers arrived in GitHub Copilot on launch day, and Sol reaches the Pro+, Max, Business, and Enterprise plans under usage-based billing. That availability matters because Copilot's coding agent opens a pull request and runs the suite against an ephemeral database it never seeds for you, which puts the empty-database gap inside a tool millions of developers already keep open.

Seed the database GPT-5.6 Sol leaves empty

Seedfast fills the database that GPT-5.6 Sol leaves empty, running from the CLI or straight out of your AI agent to generate valid, connected rows off your live schema in a single command, with no production data required for any of it. Start on the free plan, and the first seed lands in roughly two minutes.

Originally published at seedfa.st.

Seed Postgres From the Codex CLI With One MCP Command

Mikhail Shytsko — Sun, 16 Aug 2026 12:28:26 +0000

My Codex CLI session is open and the migrations have run, but the schema behind my branch is still empty. Codex CLI database seeding handles that from inside the same session, once Seedfast is registered as an MCP server the agent can call by name, and it spares me the usual fallback of hand-written inserts from the model, which tend to satisfy the column types and break on the relationships between tables — the broader guide to generating test data with AI covers why.

TL;DR: One codex mcp add command registers the Seedfast MCP server in ~/.codex/config.toml. A plain-English prompt then calls seedfast_run, which reads the foreign keys in your live Postgres schema and writes rows that stay valid, so every child row it writes points at a real parent.

Register the Seedfast MCP server in Codex CLI

Codex CLI is OpenAI's open-source terminal coding agent, and it speaks the Model Context Protocol out of the box. One subcommand wires Seedfast into it.

codex mcp add seedfast --env SEEDFAST_API_KEY=sfk_live_your_api_key_here -- npx -y seedfast@latest mcp

That command writes the server into the global ~/.codex/config.toml, the TOML file Codex loads at startup. Open the file afterward and the new entry reads like this.

[mcp_servers.seedfast]
command = "npx"
args = ["-y", "seedfast@latest", "mcp"]

[mcp_servers.seedfast.env]
SEEDFAST_API_KEY = "sfk_live_your_api_key_here"

Run codex mcp list to confirm the registration, and once you are inside a session the /mcp command shows which servers are live. To check that the key authenticated, ask Codex to call seedfast_doctor, which verifies the install and confirms an sfk_live_... key is configured; keys come from the Seedfast dashboard. Because the server launches through npx, the machine needs Node.js 18 or later, and the flags codex mcp add accepts are documented in OpenAI's MCP configuration reference.

Global config versus a project-scoped .codex/config.toml

codex mcp add only ever writes the global file. To share the server through a repository, you add a project-scoped .codex/config.toml by hand and check it in. Codex loads those project layers only for projects you have trusted, walking from the project root down toward your working directory, and the file closest to where you are running takes precedence on any conflicting key. A handful of security-sensitive keys are refused at project level regardless.

Committing a config raises an obvious question about the API key sitting in it. Per OpenAI's config reference, Codex does not hand your whole shell environment to an MCP server, so a secret reaches the server one of two ways. You either hardcode it in the env table, where it then lives in the file, or you list the variable name under env_vars and let Codex forward it from its own environment at launch.

[mcp_servers.seedfast]
command = "npx"
args = ["-y", "seedfast@latest", "mcp"]
env_vars = ["SEEDFAST_API_KEY"]

Under env_vars, the file names SEEDFAST_API_KEY but never stores its value, which makes a project-scoped config safe to commit while each developer exports the key in their own shell. That forwarding is opt-in per variable, so don't assume the server can see anything else you exported; declare what it needs, one way or the other. The full set of layering and precedence rules lives in OpenAI's config reference, and the equivalent setup for other clients, including the Claude Code version of this job, is in the MCP setup guide.

What a Codex CLI database seeding run looks like

Once the server is registered, the seed itself is one message to the agent. Say a test needs a small project tree to assert against.

Use seedfast_run to fill projects, tasks and comments. A handful of projects, a realistic spread of tasks each, a few comments where they fit.

Codex reads that and calls seedfast_run with the scope, handing off the relational work. Seedfast inspects the live PostgreSQL schema at that moment and writes rows that come out valid and connected, so every task points at a real project and every comment at a real task. The same call scales with the words you choose — "a handful" keeps a unit test quick while "a few thousand tasks" gives a query planner something to strain against. Codex picked up the GPT-5.6 family on launch day, which means the model parsing your scope may well be GPT-5.6 Sol; the ordering across tables still comes from the seeder, not the model.

When the run finishes, ask Codex for the summary, which reports how many tables succeeded and the total rows written, naming any table that failed; a SELECT count(*) gives you the same numbers from the database side. At Seedfast's default row volume even a full schema comes back populated inside a few minutes, and a scoped seed like the one above lands while you are still reading the test that needed it.

The guardrail is the connection, not the sandbox

There is a fair worry under all of this, since you are giving an agent a write path into a database. Codex ships three sandbox modes (read-only, workspace-write, danger-full-access) with network access off until you enable it, and those govern the shell commands the agent itself runs. An MCP server sits outside that arrangement; Codex starts it as a separate, long-lived process, and in practice the sandbox does not confine it, though the docs don't spell this out. So the guardrail worth setting is the database connection you hand the server, which should belong to a dev or branch database. Codex does expose approval policies you can configure per server and per tool if you want a gate before a call runs, and because Seedfast composes every row from the schema alone, production data never enters the run.

Frequently asked questions

Where does codex mcp add store the Seedfast configuration?

codex mcp add stores the Seedfast entry globally, under an [mcp_servers.seedfast] table in ~/.codex/config.toml. Nothing project-local is created by the command; a repo-scoped .codex/config.toml has to be written by hand, and codex mcp list or the in-session /mcp command will confirm what actually registered.

Can I commit the Codex MCP config without exposing my API key?

Seedfast API keys stay out of a committed file when the variable is named under env_vars instead of written into the env table. OpenAI's config reference describes env_vars as a pass-through list, with Codex forwarding each named variable from its own environment when the server starts, so the committed file carries only the name SEEDFAST_API_KEY, never the value, and teammates supply their own keys locally. Hardcoding the key in env is fine for the global file in your home directory, but it doesn't belong in anything you push.

Does the Codex CLI sandbox limit what the Seedfast server can do?

Codex CLI's sandbox is aimed at the agent's own shell commands, so in practice it does not restrict the Seedfast server, and nothing in the official docs places MCP processes inside that boundary. That leaves the choice of target database as the real limit on what a seed run can reach, with per-server and per-tool approval policies available on top when you want an explicit gate before a call.

Does seedfast_run pick up schema changes between runs?

Every seedfast_run call starts with a fresh look at the current Postgres schema, so a column added by this morning's migration shows up in the next batch of rows without any config change. Scope stays up to the prompt, and generated rows keep their references valid at any size because the schema is re-read on every run.

Seed the schema from the terminal you already live in

Codex CLI already sits where your migrations and tests run, and registering Seedfast means the same session can fill the schema they depend on. Keys come from the Seedfast dashboard, where the free plan starts without a card. Once /mcp shows the server live, every empty dev schema after that is one prompt away from being populated.

Originally published at seedfa.st.

Your AI Agent Shouldn't Touch Production. Seed It a Postgres Instead.

Mikhail Shytsko — Sun, 16 Aug 2026 12:28:12 +0000

On June 4, 2026, Supabase used its Series F announcement to report that more than half of all new Supabase databases are now deployed by AI agents, with Claude Code the single largest source of that traffic. That one number turns AI agent production database access from a hypothetical some senior engineer signs off on once into a default the tooling already assumes. Two more releases the same month leaned the same direction - Vercel shipped its agent framework, Eve, in mid-June 2026, and Anthropic's Sonnet 5 arrived on June 30 with longer autonomous runs, so an agent can now stay on a multi-step database task across the kind of stretch that used to need a person watching each step. Agents provision databases, migrate them, and increasingly write to them, so the only open question is which database they get.

Handing an AI agent production database access, and what it costs

The blunt answer to that question is to give the agent the same connection string a developer uses and trust it to behave. In July 2025 that trust produced the incident teams now cite by reflex, when an AI agent working in a Replit project deleted a production database during an explicit code freeze, then described what it had done only afterward - the failure wasn't exotic. An agent with write access did something destructive it was never meant to do, which is what "blast radius" names, the reach of a single unintended action. Of course, a developer holding those credentials can cause identical damage, but a person works one deliberate step at a time while an agent runs unattended, at machine speed, across more actions than anyone is reading in real time, so the same credentials carry more exposure in an agent's hands than in a developer's.

Isolation moves the blast radius without answering the data question

The infrastructure vendors have a more careful answer, and it is isolation. On June 26, 2026, Neon published a branch-per-agent-session guide in which each agent run gets its own copy-on-write database branch, a forked copy the agent can wreck freely because throwing it away costs nothing and the parent sits untouched behind it. Measured against blast radius alone, this works well, since the destructive action lands on a branch nobody intends to keep. However, what it leaves untouched is the data inside that branch. A branch clones whatever its parent holds, which leaves two options and no comfortable one: fork a thin dev database and the agent runs against stale, unrepresentative rows, fork production and you have copied real customer data into a scratch environment an autonomous process is free to rummage through, the exact exposure the isolation was meant to remove. So, starting the branch empty only looks safer, and an agent handed a schema with no rows invents whatever fixtures it needs, and the tests that follow go green against nothing, which is exactly what anyone vibe coding an app and hitting the empty-database wall runs into the first time they open the UI instead of trusting the test output.

A disposable Postgres, seeded to behave like production

The move both answers skip is to separate the two things a branch quietly fuses, the throwaway database and the data that fills it. Keep the disposable Postgres, whether that is an isolated branch or a local container that costs nothing to destroy, and change what goes inside. Rather than clone production or leave the schema bare, generate rows that fit the schema, connect correctly across foreign keys, and carry values that read like the real thing, so the agent works against a database shaped like production that never held a byte of production's actual records. That generation step is precisely where raw model-written inserts fall apart, because a language model asked to emit SQL will happily write a foreign key pointing at a row it never created; holding the relational structure together is work for something that reads the schema rather than pattern-matching its way through it.

This is the seam Seedfast is built for. It reads the live Postgres schema and writes rows that come out connected and valid, with every foreign key satisfied — including tables that reference themselves or each other in a loop. None of that path touches production, since a schema is the shape of your tables and not their contents, and every value it inserts is generated fresh. You invoke it as a CLI, seedfast seed --scope "...", or as an MCP server an agent calls on its own, and one run scales from a single table up to the several hundred a mature schema tends to carry.

Putting a seeded branch in front of the agent

In practice the pattern is short to describe. Stand up a disposable Postgres, apply your migrations so the schema is current, seed it, and give the agent that connection string in place of the real one. Because Seedfast also runs as an MCP server, the seed can be the agent's own opening move, a single seedfast_run call before it starts whatever work needs data underneath it, which the Claude Code walkthrough wires up from scratch and the Codex CLI guide repeats for OpenAI's terminal agent. When the agent is GitHub Copilot working in its Actions environment, the seed moves into its setup-steps workflow instead, and Antigravity's parallel agents read the same server from one shared config. For a loop that stays on your laptop, a disposable Postgres under Docker Compose gives you the same throwaway target with no cloud branch involved, and once the loop moves into CI, seeding on every pipeline run keeps each job's database current instead of restoring it from an aging copy - the setup lives in those guides. What matters here is the ordering, disposable database first, then the real schema, then generated data, and the agent last.

Frequently asked questions

Why shouldn't an AI coding agent connect to your production database?

An AI coding agent pointed at production inherits full write access and exercises it unattended, at a speed and across a step count no human review keeps pace with, which is what enlarges the blast radius of any single mistake. The widely cited Replit case from July 2025, an agent deleting a live database mid-freeze, is what that risk looks like when it lands. Handing the agent a disposable database instead retires the whole class of failure rather than trying to fence it off after the credentials are already out.

Is an empty branch enough for an AI agent's test run?

An empty branch is almost never enough, because an agent given a schema with no rows either fabricates its own fixtures or runs tests that pass without checking anything real. Copy-on-write branching, from Neon and platforms like it, solves isolation and keeps a bad run off production, yet it says nothing about whether the rows inside the branch resemble what the code meets once it ships. A branch seeded with generated, connected data is what makes the run worth trusting.

What did Supabase say about agents deploying databases?

Supabase reported in its June 4, 2026 Series F announcement that AI agents now stand up more than half of all new databases on the platform, and it credited Claude Code with more of that traffic than any other tool. The figure reads as a direction more than a milestone, evidence that provisioning and writing to databases has become ordinary agent work. It sets up the practical decision that follows, namely which database an agent should ever be permitted to write against.

How do you give an AI agent realistic data without copying production?

Giving an agent realistic data without copying production comes down to generating it from the schema instead of duplicating the rows, so the database mirrors production's structure while holding none of its records. A schema-aware generator reads the table definitions and foreign keys, then writes connected rows that satisfy every constraint, which is what keeps integration tests meaningful rather than merely green. Seedfast does exactly this from a connection string, as a CLI step or an MCP call, so an agent can seed its own branch before the first test runs.

Which database the agent gets is the decision

Every failure mode above, the deleted production database, the stale fork, the branch that went green because it was empty, traces back to a single choice nobody quite made on purpose, which database the agent is allowed to touch. Decide it deliberately and hand the agent a throwaway Postgres that was never production and never held a row of its data, and the safety argument mostly settles itself. Seedfast is the piece that fills that database with something worth testing against, and its free plan takes no card if your next agent run needs a real schema underneath it.

Originally published at seedfa.st.

Give GitHub Copilot's Coding Agent a Seeded Postgres

Mikhail Shytsko — Sun, 16 Aug 2026 12:27:29 +0000

You assign an issue to Copilot, and a few minutes later a pull request is waiting for review with its checks already red. The migrations ran. What broke is everything downstream of them, the tests that expected a customer to exist, an order to join against, a row to assert on, all firing against a schema with nothing inside it. Copilot coding agent database seeding is the fix, and it comes down to one file, .github/workflows/copilot-setup-steps.yml, that populates Postgres before the agent writes a line.

GitHub renamed Copilot coding agent to Copilot cloud agent on April 1, 2026, and both names are live across its docs right now, so I'll stay with "coding agent" throughout. Why you'd hand that agent freshly generated data instead of a clone of production is its own subject; here I'm taking that decision as made and wiring the environment.

Where a coding agent task actually runs

Every task Copilot picks up runs in a throwaway GitHub Actions environment provisioned for that one job, on a single branch that becomes a single pull request. Nothing persists between tasks. When the run ends the environment is gone, so the database behind it has to be built from scratch each time rather than assumed from an earlier session. The setup phase you control tops out at 59 minutes, and otherwise the environment behaves like the Actions jobs you already write, down to the service-container mechanics, with one twist in the secrets model.

The copilot-setup-steps.yml file, and the line that breaks it silently

The configuration lives at .github/workflows/copilot-setup-steps.yml, and it reads like an ordinary workflow, except only one job inside it is read, the one named copilot-setup-steps. Name it anything else and GitHub ignores the file with no error and no warning, and the agent starts against an empty database as if you'd never written it. GitHub's environment customization docs list the honored keys, and the set is small. You get steps, permissions, runs-on, services, snapshot, and timeout-minutes, and anything outside that set is quietly dropped. snapshot is listed as honored, but the docs don't describe what it does, so I'll leave it in the set without guessing at its behavior.

The job runs before the agent starts, and it also fires on workflow_dispatch and on any push or pull request touching the file itself, which lets you prove the setup is green without waiting on a real task. One requirement is easy to miss. The file has to live on your default branch to take effect at all; a copy on a feature branch does nothing.

A setup file that migrates and seeds Postgres

Here's a minimal, runnable version that stands up a PostgreSQL service, runs your migrations against it, and seeds it with Seedfast.

name: Copilot setup steps

on:
  workflow_dispatch:
  push:
    paths:
      - .github/workflows/copilot-setup-steps.yml

jobs:
  copilot-setup-steps:
    runs-on: ubuntu-latest
    timeout-minutes: 20
    services:
      postgres:
        image: postgres:16
        env:
          POSTGRES_PASSWORD: postgres
          POSTGRES_DB: app
        ports:
          - 5432:5432
        options: >-
          --health-cmd "pg_isready -U postgres"
          --health-interval 10s
          --health-timeout 5s
          --health-retries 5
    steps:
      - uses: actions/checkout@v4

      - name: Run migrations
        run: npm run migrate
        env:
          DATABASE_URL: postgres://postgres:postgres@localhost:5432/app

      - name: Seed with Seedfast
        run: npx seedfast seed --scope "20 customers with orders and line items" --output json
        env:
          DATABASE_URL: postgres://postgres:postgres@localhost:5432/app
          SEEDFAST_API_KEY: ${{ secrets.SEEDFAST_API_KEY }}

The services block brings up a postgres:16 container with a health check that holds the run until the database answers, the same pattern any Actions job uses, so nothing here is Copilot-specific until the secret. Migrations run first against localhost:5432, then the seed step calls npx seedfast seed (npx ships with npm) with a plain-language scope and --output json for a machine-readable result. Seedfast reads the schema off that connection string and composes fresh rows whose relationships resolve, inventing every value rather than copying anything out of a real database, the generate-per-run approach behind synthetic data in CI/CD. Exit codes and the rest of the pipeline-side mechanics live in the CI/CD seeding docs.

If you already seed this schema locally with a Compose stack, the file above is the CI cousin of that docker-compose seeding workflow, except this container is discarded the moment the task ends. One gap is worth flagging. Whether that postgres:16 service stays reachable at localhost:5432 once the agent later runs your test command itself, rather than during setup, isn't something the docs spell out, so treat the service as guaranteed for the setup steps and verify it for anything the agent runs afterward.

Why the agent can't see your Actions secrets

A working setup file can still fail at the secret. The agent doesn't read your repository's Actions secrets, nor the Codespaces or Dependabot ones; it reads only the secrets you add under a separate store, at Settings → Secrets and variables → Copilot (the tab GitHub's secrets and variables guide refers to as Agents). A team whose SEEDFAST_API_KEY has always lived in Actions secrets watches the seed step throw an auth error that has nothing to do with the key being wrong, because from the agent's environment that value isn't there.

Whatever you put in that tab arrives in copilot-setup-steps.yml as an environment variable, which is what the seed step expects from ${{ secrets.SEEDFAST_API_KEY }}. One naming detail matters on the MCP route covered next. A secret consumed by an MCP server carries the COPILOT_MCP_ prefix, so the same value becomes COPILOT_MCP_SEEDFAST_API_KEY there, while the setup-steps file needs none.

The firewall that doesn't touch your setup steps

Copilot's coding agent runs behind a firewall that's on by default, and a blocked outbound call shows up as a warning on the pull request. What matters for seeding is the firewall's scope. Per GitHub's firewall documentation, it "only applies to processes started by the agent via its Bash tool. It does not apply to Model Context Protocol (MCP) servers or processes started in configured Copilot setup steps." So the seed step above never meets the firewall, and you allowlist nothing for it to reach the Seedfast API.

The firewall only bites when the agent itself runs the seed mid-session, calling npx seedfast seed through its Bash tool. For that case, add seedfa.st to the allowlist under Settings → Copilot → coding agent → Custom allowlist, and the call goes through.

MCP is the other way to give the agent a seed tool it can call by name, sitting on the safe side of the firewall just as setup steps do. You configure it in the repository under Settings → Code & automation → Copilot → MCP servers, pasting a JSON block rather than committing a file. Local npx servers are supported, using "type": "local" with "command": "npx", and any secret the block references takes the COPILOT_MCP_ prefix. GitHub's MCP extension guide carries the full schema. It's the same npx-launched Seedfast server the terminal agents register, parked in settings instead of a config file, and it fits when you want the agent seeding on demand mid-task rather than once up front.

When this isn't worth setting up

Not every task needs any of this. When the work never runs data-dependent code, a docs fix, a refactor nowhere near the test path, a copy change, a seeded Postgres buys you nothing and the file is dead weight on your default branch. Add it when your suite genuinely hits the database on the branches Copilot works, and skip it otherwise.

There's a second cost worth naming. The Agents secrets store, the firewall allowlist, and the MCP JSON all live in repository or organization settings, so standing them up needs repo-admin, more ceremony than the terminal agents ask for. Claude Code reads one .mcp.json at the repo root, Codex CLI takes one codex mcp add into a config.toml, both keeping the arrangement in files a developer owns without opening GitHub settings. A team already seeding through one of those in their editor may not want a second, settings-level setup just for Copilot's cloud runs, and that's a fair call.

Frequently asked questions

What must the copilot-setup-steps.yml job be called?

The job in copilot-setup-steps.yml must be named copilot-setup-steps exactly, or GitHub skips the file. Nothing warns you when the name is wrong; the agent just starts without your setup having run, a common reason a database that should have been populated turns up empty. It also has to be committed to the default branch before it takes effect.

Can the GitHub Copilot coding agent use a Postgres service container?

Yes. The GitHub Copilot coding agent honors a services: block in copilot-setup-steps.yml, so a postgres:16 service container starts exactly as it would in any GitHub Actions job. Attach a health check so the setup waits until the database accepts connections, then run migrations and seeding as ordinary steps against localhost:5432.

Why doesn't my GitHub Actions secret work in copilot-setup-steps.yml?

A GitHub Actions secret doesn't reach the coding agent because the agent reads a different store. Only secrets under the Copilot tab of Settings → Secrets and variables (the store GitHub's docs call Agents) are exposed to copilot-setup-steps.yml; the Actions, Codespaces, and Dependabot stores stay invisible to it. Move the value into that tab and the reference in your YAML resolves.

Does the Copilot coding agent's firewall block calls to the Seedfast API?

Not from your setup steps. The firewall is scoped to processes the agent launches through its Bash tool, so seeding that runs inside copilot-setup-steps.yml or through an MCP server reaches the Seedfast API untouched. Only when the agent runs npx seedfast seed itself, mid-task, does the firewall apply, and adding seedfa.st to the coding-agent allowlist clears that path.

Data behind the code, before review

The payoff shows up at review time. When Copilot's pull request lands, its checks have run against generated rows with valid relationships, so red on the branch points at code the agent got wrong rather than fixtures nobody remembered to load. Seedfast keys come from the dashboard, and the free plan is enough to wire this into a repo and watch a task come back green off a database it built itself. Put the file in place once, and it stays a thing you set up rather than a thing you maintain, every task Copilot takes on after that starting with data already behind it.

Originally published at seedfa.st.

Give Google Antigravity's Agents a Seeded Postgres

Mikhail Shytsko — Sun, 16 Aug 2026 12:27:15 +0000

Google Antigravity's Manager Surface lets you spawn several agents at once and watch them work in parallel, one untangling a checkout bug, another chasing a flaky test, two more off on unrelated tickets. The friction shows the instant any of them reaches for data, because every agent you launched points at the same dev database and that database is empty, so the parallel runs stall together on rows nobody generated. Antigravity MCP Postgres seeding clears that before the first agent moves, letting you register Seedfast once in the config the IDE and the CLI both read, then fill the schema with one prompt while the agents are still spinning up.

Antigravity ships real database tooling, yet every one of those tools reads what a schema already holds; none fills a schema holding nothing. That second job is what this page wires.

What Google Antigravity is now, and what became of Gemini CLI

Google Antigravity launched as an agentic IDE in public preview in November 2025, then widened at Google I/O on May 19, 2026, when Antigravity 2.0 arrived as an agent-first platform with a standalone Antigravity CLI beside the desktop app (Google's announcement, TechCrunch's coverage). If you were leaning on Gemini CLI, that is where it went, retired on June 18, 2026 for Pro, Ultra, and free users, with only Enterprise keeping access. The move ran closer to a rename than a rewrite, the old GEMINI_API_KEY becoming AV_API_KEY while the workflow carried over intact (the transition post).

What keeps the setup below short is that both surfaces read the same Model Context Protocol configuration. They load ~/.gemini/config/mcp_config.json, one user-level file whose mcpServers block covers every surface at once, with no project-scoped MCP file to juggle the way Claude Code keeps a .mcp.json per repo or Codex a config.toml. Register a server once and it answers from both surfaces, so command-line seeding, once Gemini CLI's job, now runs through the Antigravity CLI. One caveat on that path, which has already moved once. Pre-2.0 guides point at ~/.gemini/antigravity/mcp_config.json rather than the config/ location the 2.0 docs use, which is why an older walkthrough may send you somewhere that looks wrong.

Set up Antigravity MCP Postgres in mcp_config.json

Two things have to exist first, a Seedfast account and an API key from the dashboard, which arrives in the sfk_live_... shape. Because mcp_config.json is a user-level file, not something checked into a repo, the key stays in your home directory rather than traveling with a project, which sidesteps the commit-it-safely question the repo-scoped clients have to answer.

Open ~/.gemini/config/mcp_config.json and add Seedfast under mcpServers:

{
  "mcpServers": {
    "seedfast": {
      "command": "npx",
      "args": ["-y", "seedfast@latest", "mcp"],
      "env": {
        "SEEDFAST_API_KEY": "sfk_live_your_api_key_here"
      }
    }
  }
}

The entry is the standard command/args/env shape, and Antigravity runs local stdio servers over npx, so Node 18 or newer is the only prerequisite. Restart Antigravity or reload the window, and the server comes up for the IDE and the CLI together. To check the wiring, ask the agent to call seedfast_doctor, which reports whether the CLI is healthy and your key authenticated. Antigravity also carries an in-app screen for adding and toggling MCP servers, and since that menu route has shifted between doc versions, treat the JSON file above as the anchor and let Google Antigravity's own MCP docs hold the current click-path.

Two more tools ride alongside seedfast_doctor, seedfast_plan and seedfast_run, and the MCP setup guide covers what each returns and how long a run takes.

One prompt, and the schema fills

With the server registered, seeding reads like a request rather than a task. Say a screen you are building needs organizations that own a few users and projects. You would type something close to this into the agent panel:

Seed a handful of organizations, each with a few users and a couple of projects, using seedfast_run

Antigravity hands that scope to seedfast_run, and Seedfast takes the relational side from there, reading the schema as it stands at that moment and filling the tables so each organization exists before the users and projects that reference it, every value made up new. Scope sets scale as much as shape, so "a handful" keeps a unit test quick while "a few thousand users" gives a query planner something heavier to chew on.

When it finishes, ask for the summary and the agent reports which tables were touched and how many rows landed in each, naming anything that failed; a plain SELECT count(*) reads the same numbers from the database side. The same prompt works from the Antigravity CLI unchanged, since terminal and IDE resolve the same mcp_config.json, so a seed first written at your desk repeats inside an SSH session or a throwaway container off that one line.

Where Antigravity's native database tools stop

Google Antigravity ships database tooling of its own, worth being precise about so you know where Seedfast fits. The built-in MCP Store offers one-click installs for Google-native servers, and the AlloyDB and Cloud SQL connector is the relevant one. Once installed, it exposes list_tables, get_table_schema, execute_sql, and get_query_plan (per the Google Cloud blog), a capable kit for administering and interrogating a database from inside the agent.

Read that list closely and the boundary draws itself. Every one of those tools acts on data already present, listing what exists, describing a table's shape, running a query, explaining a plan. Not one puts a row into an empty table. That is the seam this page has circled, the native tools answering what is in this schema while Seedfast answers the other half, the schema is empty, fill it with connected rows. Both sit in the same mcp_config.json, the Store server for reading and querying, Seedfast for the population step the Google-native tools skip.

Tool Approval, and why the target database still matters

By default Antigravity executes MCP tool calls without pausing for approval, so a seedfast_run fires the moment the agent decides to call it. Turning on Tool Approval, under Settings → Antigravity → MCP → Tool Approval, makes those calls wait for your yes, while terminal commands answer to a separate allow-list, so the two are governed independently. The exact menu labels have shifted between releases, so treat them as directional and confirm in-app.

Gate the calls or not, the durable habit is the connection string, which should belong to a dev or branch database and never to production. Seedfast makes that easy to keep, since it never needs production data to work, reading only the schema and writing fresh rows, so nothing real comes within reach of the run. There is a reason beyond safety, too. Google Antigravity drew rate-limit and throttling complaints through spring 2026, so a dev database is where a stalled or retried run costs nothing.

When the built-in tools are enough, and when they aren't

None of this argues for reaching past the native tools every time. When a database already carries data and you want to inspect it, run a query, or read a plan, the Store's AlloyDB and Cloud SQL server covers the job on its own, and installing a generator you won't call is clutter. The honest scope for Seedfast is the empty schema, the migration that ran against nothing, the branch cloned thin, the fresh container, the moment the tables exist and hold none of the rows a test needs. That part is what the native tools structurally cannot do.

If your seat is elsewhere, the same server block moves with almost no change. Claude Code takes it in a project-scoped .mcp.json and Codex CLI in a config.toml, same block, different client. The case for generating this data rather than handing an agent a copy of production is its own argument, as is the reason raw model-written SQL falls apart on the relationships between tables, both worth reading before you wire an agent to a database it can write to, alongside a wider look at which MCP servers actually generate test data versus the ones that just move files around.

Frequently asked questions

Does Google Antigravity support MCP servers like Seedfast?

Google Antigravity supports MCP servers natively in both the IDE and the CLI, which read them from one shared ~/.gemini/config/mcp_config.json. Google's own servers install from the built-in catalog in a click, while a third-party server like Seedfast goes in by hand as a command/args/env entry under mcpServers, after which the agent can call its tools from either surface.

What happened to Gemini CLI, and does the migration change MCP config?

Gemini CLI was retired on June 18, 2026 for Pro, Ultra, and free users and folded into the Antigravity CLI, with only the Enterprise tier keeping the old tool. The migration ran close to a rename, its main environment change being GEMINI_API_KEY giving way to AV_API_KEY. It leaves MCP registration alone, because the Antigravity CLI reads the same mcp_config.json the IDE does, so a Seedfast entry set up for one already works for the other.

Does Antigravity's AlloyDB MCP server seed a database, or only query it?

Antigravity's AlloyDB and Cloud SQL MCP server queries and administers a database rather than seeding one. Its tools, list_tables, get_table_schema, execute_sql, and get_query_plan, all operate on data that already exists, so an empty schema stays empty however many of them the agent calls. Filling tables with connected rows is a separate job, which is why teams run a schema-aware generator like Seedfast beside the Google-native server rather than in place of it.

Do Antigravity MCP tool calls require approval before they run?

Antigravity MCP tool calls run without approval by default, executing the moment the agent invokes them. Switching on Tool Approval in the MCP settings holds each call until you confirm it, while terminal commands answer to their own allow-list. For a seed in particular, the setting that earns more than the approval gate is the connection string, kept pointed at a disposable database so an unattended call has nothing valuable to reach.

Data in place before the agents spread out

The parallel-agents picture from the top is really an argument for doing the data step first, and once. When the agents meet a schema that already holds organizations, users, and projects that hang together, none of them burns a run improvising fixtures or going green against nothing, and what you read back at review reflects code rather than a gap in the setup. Seedfast is the piece that puts that data there, and the free plan is room enough to drop in the one config block and watch a schema fill with connected rows before the agents you spawned ever notice it was empty.

Originally published at seedfa.st.

Agentic QA Can Write the Tests. It Still Can't Invent the Data.

Mikhail Shytsko — Sun, 16 Aug 2026 12:27:02 +0000

An agentic QA tool reads your app, decides what's worth testing, writes the test, runs it in a real browser, and rewrites it the next morning after someone renames a button. Autonoma, QA Wolf, Momentic, and testRigor all sell a version of that loop today, and it's fair to conclude that writing and maintaining test scripts has stopped being your job. What the conclusion skips is the agentic QA test data problem sitting one layer down, in the database each of those tests runs against.

None of these tools invents that database. They drive an application that already has to be full of valid, connected, believable rows, and the question of where those rows come from is one every agentic QA product still hands back to the team that bought it. The authoring of the test moved off your plate; the authoring of the data underneath it never did, and the two stay easy to confuse right up until a green suite ships a bug that only a realistic row would have caught. That lower layer has tooling of its own, a schema-aware generator like Seedfast, and the reason the QA vendors leave it alone is worth a closer look.

What agentic QA actually automated

For a decade, end-to-end tests were written by hand and broke by hand. An engineer authored a Playwright or Cypress script, a selector shifted, the script went red, and someone lost an afternoon nursing brittle, hand-maintained fixtures back to green. Agentic QA collapses that cycle, and it's worth being specific about how far these products actually go, because they are good at the thing they set out to do.

Autonoma runs the loop as a set of cooperating agents. A Planner reads the app or its codebase and generates the test cases, an Automator drives real browsers to execute them against a live preview environment, and a Maintainer notices when the UI has moved and repairs the affected tests on its own (getautonoma.com, May 2026). QA Wolf takes the managed-service route, generating and running Playwright and Appium suites so that web and native mobile flows both get covered without a team writing the automation code. testRigor lets you describe a test in plain English and compiles that description into a runnable case, which dodges brittle selectors by never asking a human to write one in the first place. Momentic sells the same core promise, an agent that authors and maintains the tests so QA engineers stop babysitting scripts; one agent-market tracker put its total funding at a reported $18.7 million, with Notion, Xero, Webflow, and Retool among its users (agentmarketcap.ai, April 8 2026).

The architectures differ; the shared win doesn't. The test itself, from first intent through running assertion to self-healing upkeep, is now something a team can delegate to software, and that is a real bottleneck cleared.

The step every one of them still hands back to you

Ask any of these tools where the test data comes from and the honest answers converge on the same place, which is you.

Autonoma has the most developed answer in the category, and it deserves a careful description precisely because it's strong. The product ships an Environment Factory, and its own copy is candid about the mechanism. "You connect your own create and delete functions through our SDK", it reads, "so Autonoma seeds and tears down exactly like your app does — password hashing, foreign keys, business rules and all" (getautonoma.com, as of July 2026). Underneath that, per its docs (docs.autonoma.app, as of July 2026), is "one endpoint in your backend that creates isolated test data before each run and tears it down after", so every scenario starts from a clean, correct state. Because the setup runs through your application's own create logic, the rows it produces obey the same invariants production does, which is more than a generic fixture ever gives you, and it's the reason Autonoma's answer is the most credible one going even though it stops short of generating anything at all.

It is also, precisely, not data generation. The Environment Factory calls a function your engineers already wrote, for every entity your tests touch, before the agent can use it — the knowledge of what a valid customer or a well-formed order looks like lives in code your team authored and maintains. Autonoma orchestrates that code well; it doesn't originate the data.

The other tools sit further from generation. A competitor's April 2026 comparison characterizes QA Wolf's database setup as something that "requires coordination with QA team or manual seed scripts" (getautonoma.com, April 2026), which is one vendor's read of a rival and worth treating as positioning. QA Wolf's own page frames a hybrid platform and service, where a team can run the tests itself or lean on QA Wolf's engineers, and neither mode claims schema-driven data generation. testRigor does ship a data feature, and its scope is the tell. The site says it "allows to easily generate unique test data based on specified format or Regex" (testrigor.com/features, 2026). One value, one column, matched to a pattern, with no notion of the foreign key tying that column to the next table over. It's Faker's ceiling relocated inside a test-authoring product, handy for a single field and silent about the graph.

Why doesn't an agentic QA tool just generate the test data itself?

Because it's a different problem, owned by a different kind of software, and none of these vendors is in that business.

A QA agent's competence is behavioral. It models what a user does and reasons about the app's visible surface, the routes and forms and states a browser can reach. Nothing in that job requires it to hold a model of how your schema's tables relate to each other or how your domain's values are really distributed, so it doesn't build one. Momentic's own December 2025 writeup of what its agents do runs from test authoring through maintenance without once mentioning the database underneath the tests (momentic.ai, Dec 29 2025); in that post, at least, the data layer never comes up.

Generating a realistic multi-table dataset is the opposite kind of task, and the steps don't commute: read the schema, satisfy every foreign key and check constraint, then shape the values so they read like production instead of like random(). That's the same constraint-solving problem a language model hits when you ask it to emit the inserts directly, and it's why the sharper question is often which database an agent gets at all. Solving it is a product in itself, and not the product any agentic QA vendor set out to build. It's the one Seedfast did.

Where a schema-aware generator fits underneath an agentic QA tool

The fix isn't to wait for one of these vendors to grow a data engine. It's to put the missing layer directly beneath the one they already automated.

That layer is a schema-aware generator, and it does the thing the QA agent structurally can't. Seedfast connects to your Postgres, reads the schema on that connection, and writes fresh values into every column so the result comes out connected and valid — nothing points at a row that isn't there, including tables that reference themselves or each other in a loop. None of what it inserts is copied from production. What Seedfast reads is schema metadata, the table and column names and constraints, never the rows inside them, though teams in regulated settings will still want to review what those names reveal. What you get is a database that behaves like production without ever having held a byte of it, standing ready before any agent, QA or coding, runs its first assertion. A run scopes down to one table or out to a schema several hundred tables wide.

Stacked, the division of labor is clean. The agentic QA tool owns the question of whether the app behaves correctly; the generator owns the question of whether the database looks like production. You seed first and let the agent test second. Run Seedfast as a CLI step in the job that provisions the environment, or, because it also runs as an MCP tool, let a coding agent trigger the seed itself before it hands the app off to the QA layer. A GitHub Copilot agent whose Actions environment comes up empty on every run needs the same seed wired into its setup workflow before a single test has data to run against, because an empty database the agent can't tell is a bug will pass every assertion it runs anyway. Neither tool competes with the other, and neither stands in for it. And because Seedfast is flat-priced rather than metered per row, it costs less than the flaky-suite afternoon it replaces.

Frequently asked questions

What is agentic QA?

Agentic QA is testing where an AI agent plans, writes, runs, and maintains the tests itself, reading the app or its code to decide what to cover, driving a real browser the way a person would rather than binding to fragile CSS selectors, and rewriting a test when the interface it targeted moves. The label is the vendors' own coinage, the phrase Autonoma, QA Wolf, and Momentic all reach for to name their category in 2026 marketing, which is a fair sign of how fast this became a recognized product class.

Does Autonoma generate its own test data?

No, and it doesn't claim to. Autonoma's Environment Factory calls create and delete functions your own engineers write and register through its SDK, which ships for TypeScript, Python, Elixir, Java, Ruby, Rust, Go, and PHP as of July 2026 (docs.autonoma.app). Reusing your app's real logic is why the rows come out valid, but the intelligence that knows what a valid record looks like is yours, not the agent's. It orchestrates your setup code; it doesn't invent data from your schema.

Can testRigor or QA Wolf generate relational test data?

Not in the relational sense. testRigor's data feature tops out at one value matched to a format or regex, useful for filling a field but blind to whether that field has to match a row in another table. QA Wolf describes a hybrid platform and service whose scope runs from API setup and database state management to SMS verification, native mobile execution, and multi-user workflows (qawolf.com, 2026); whether a team runs the tests itself or leans on QA Wolf's engineers, nothing in that scope is schema-aware generation of relational rows.

How does Seedfast fit alongside an agentic QA tool?

It runs one layer down and one step earlier. You stand up a throwaway Postgres, run your migrations, and point Seedfast at the connection string to fill it with connected rows, and only then hand that database to the QA agent to test against. Whether the agent is a browser-driving QA tool or a coding agent that seeds itself over MCP first, the sequence holds, and the QA tool never has to care where the rows came from, only that they're present and valid. The free plan needs no card, so evaluating the data layer doesn't require a second procurement conversation.

Where agentic QA test data actually comes from

An agentic QA tool tells you whether your app behaves, but only against the rows it happens to find, and putting realistic rows there was never its job. That gap runs through every vendor in the category, which is why the durable setup stacks two automations instead of waiting for one to absorb the other. Seedfast seeds the database, the QA agent tests it, and neither pretends to do the other's work.

Originally published at seedfa.st.

Your Staging Database Is a Compliance Violation Waiting to Happen

Mikhail Shytsko — Sun, 16 Aug 2026 12:26:49 +0000

Why production data doesn't belong in staging, and how to run staging without production data by generating it fresh from your schema.

It's 9 AM Tuesday when your DPO stops by standup and asks, "Who has access to the staging database?"

The honest answer is everyone — developers, QA, contractors, and CI all read the same three-week-old pg_dump of production, with real names, emails, payment history, and, in regulated shops, medical records or financial transactions.

In compliance terms, that box is a GDPR Article 33 breach notification in waiting, unnoticed only because nobody files "it's just staging" as a breach.

In short , production data has no place in staging. Running staging without production data means building your staging rows from the schema itself, so no masked dump is involved. Point Seedfast at a database and it generates realistic, connected data at production volume without production access, so no PII reaches staging and the anonymization script goes away.

The pg_dump + Anonymize Anti-Pattern

Here's how most teams build staging environments with pg_dump:

# Step 1: Dump production
pg_dump production_db > prod_dump.sql # 47 GB, 3 hours

# Step 2: Restore to staging
psql staging_db < prod_dump.sql # another 2 hours

# Step 3: "Anonymize" the sensitive columns
psql staging_db -f anonymize.sql

And anonymize.sql looks something like this:

UPDATE users SET email = 'user' || id || '@example.com';
UPDATE users SET phone = '+1555000' || LPAD(id::text, 4, '0');
UPDATE users SET first_name = 'Test', last_name = 'User';
UPDATE payments SET card_last_four = '0000';
-- TODO: anonymize addresses (see ticket INFRA-2847, opened 8 months ago)
-- TODO: handle the new medical_records table (added last sprint)

This pattern has four failure modes, and most teams are living at least two right now.

1. The Script Never Covers Everything

That anonymization script was written six months ago, and the schema has kept moving since. Three PII-bearing tables have landed — user_preferences picked up location data, and support_tickets now holds free-text where customer names, account numbers, and even plaintext passwords get pasted in. Nobody has updated the script for them, and nobody will, which makes every "anonymized" refresh a quiet fiction.

2. Schema Drift Breaks the Restore

Your production schema changes almost daily, so a Tuesday dump is already behind by Thursday, when a migration adds a NOT NULL column with no default and the restore falls over. Someone burns half a day tracing it, patching the dump by hand, and rerunning, only for the same break to return next week.

ERROR: column "verification_status" of relation "users" does not exist
-- anonymize.sql references a column that was renamed to "kyc_status" last sprint

3. The Dump Files Are Enormous

A 50-million-row production database yields a dump measured in gigabytes; storing, transferring, and restoring it burns hours of infrastructure. Many teams refresh staging only weekly or monthly because anything faster is impractical.

By the time that copy is a week old it has drifted from the source, missing relationships production has since formed and still carrying bugs you fixed upstream.

4. You're Probably Violating GDPR Right Now

Under GDPR, processing personal data needs a lawful basis, and "we wanted realistic staging data" is not one. The regulation demands data minimization under Article 5 and data protection by design under Article 25, both of which a full production copy in a loosely governed environment undercuts.

GDPR is not alone here, and CCPA, HIPAA, SOC 2, and PCI DSS all flag production data in non-production environments, so the copy that felt convenient is exactly what an auditor probes and a breach notice has to disclose. A compliant test data tool keeps personal data out by construction rather than after the fact — the generate-versus-mask breakdown makes that case well beyond staging.

The Alternatives (And Why They Fall Short)

Hand-Written Fixtures

INSERT INTO users (id, name, email) VALUES
  (1, 'Alice', 'alice@test.com'),
  (2, 'Bob', 'bob@test.com'),
  (3, 'Charlie', 'charlie@test.com')

Fixtures carry no PII, which is their appeal, but a few hand-written rows with identical timestamps and flat distributions stress nothing and fool no one. Staging becomes a ghost town the sales team can't demo on, its dashboard showing three users named Alice, Bob, and Charlie.

Faker Libraries

from faker import Faker
fake = Faker()

for i in range(10000):
    db.execute(
        "INSERT INTO users (name, email, created_at) VALUES (%s, %s, %s)",
        (fake.name(), fake.email(), fake.date_time_this_year())
    )
# Now do the same for orders... and order_items... and payments...
# And make sure the foreign keys are valid...
# And the status distributions are realistic...
# And the timestamps are chronologically consistent

Faker hands you random values, but the orchestration is still yours — table ordering, foreign-key resolution, realistic distributions, volume proportions. On a 40-table schema that is a multi-week build that breaks on every schema change, like the anonymization script. That hand-wired work is exactly the split the best AI test data generator guide draws against a schema-aware tool.

Seedfast

seedfast seed --scope "seed 50,000 users with orders, payments, and support tickets"

Seedfast is a CLI that reads your schema and a plain-English scope, keeps every foreign key valid, and shapes value distributions to resemble production traffic. Because every row is generated from scratch, staging holds no production PII, and no script or dump file has to track the schema. One data path is worth knowing before you adopt it. Seedfast passes your schema's shape (table and column names, types, constraints) to an AI provider to generate the data, while the row values stay in your database. If those names are themselves sensitive, clear that call with your security policy the way you would any vendor.

How to run staging without production data with Seedfast

Describe What You Need

You describe the staging environment you want, and Seedfast builds it from there:

# Full staging environment
seedfast seed --scope "seed 100,000 users with realistic profiles,
  500,000 orders spread across the last 12 months,
  payments for each order, and support tickets for 5% of orders"

Seedfast analyzes your schema and proposes a plan:

Seeding Plan:
  public.users — 100,000 records
  public.addresses — 95,000 records
  public.orders — 500,000 records
  public.order_items — 1,400,000 records
  public.payments — 500,000 records
  public.support_tickets — 25,000 records

Total: 2,620,000 records across 6 tables

Approve? (Y/n)

You never listed addresses in your scope; Seedfast added it because orders references it, then sized the line items to match, none of which you had to spell out.

Automate It

For scheduled or CI pipeline refreshes, set SEEDFAST_API_KEY to run the CLI non-interactively:

# In your staging refresh script or CI pipeline
export SEEDFAST_API_KEY="..." # from the Seedfast dashboard
seedfast seed \
  --scope "seed 100,000 users with orders and payments" \
  --output plain

Exporting SEEDFAST_API_KEY drops the confirmation prompt, so the scope runs straight through and exits non-zero on failure. Seedfast appends to the tables in your scope without touching existing rows, so a second run stacks more data on top. For a repeatable refresh, point each run at a fresh database (an ephemeral Postgres container in CI) or truncate the target tables first:

# Clean slate before each scheduled refresh
psql "$DATABASE_URL" -c "TRUNCATE users, orders, payments RESTART IDENTITY CASCADE;"
seedfast seed --scope "seed 100,000 users with orders and payments" --output plain

Scale It for Demos

Sales demos need data that looks alive, hundreds of realistic profiles with enough activity to fill a dashboard:

seedfast seed --scope "seed 5,000 users with varied subscription tiers,
  activity logs spread across the last 90 days,
  and a mix of active, churned, and trial accounts"

It's the same "must look alive, must hold no real customer data" brief dedicated demo data has to meet.

Addressing the Concerns

"But will the foreign keys be valid?"

Foreign keys stay valid because Seedfast fills every reference with a row that exists, so joins hold. When the schema loops with a nullable or deferrable side, it resolves those circular dependencies too.

"What about realistic distributions?"

This is where Seedfast pulls away from Faker. Random output is uniform; Seedfast follows realistic patterns, so most orders land in "completed", timestamps cluster in business hours, and amounts trace a curve that looks like real buying.

"Can I control the volume?"

Volume comes from the scope, so ask for 1,000 users for a quick test and that is what you get; push it to 500,000 for a load test and Seedfast scales up, cross-table proportions intact.

# Quick staging refresh
seedfast seed --scope "seed 1,000 users with orders"

# Load testing
seedfast seed --scope "seed 500,000 users with orders, payments, and activity logs"

For very high row counts, see the guide to large-volume seeding.

"Is it idempotent?"

Not on its own — each run adds to existing rows, so seeding twice leaves two copies. For a repeatable refresh, start empty, with a throwaway database per run or the target tables truncated first.

The Real Comparison

	pg_dump + Anonymize	Fixtures	Faker Scripts	Seedfast
Production PII risk	High	None	None	None
Setup time	Hours	Days	Weeks	Minutes
Schema changes	Breaks scripts	Breaks fixtures	Breaks generators	Adapts automatically
Data realism	High (real data)	Low	Medium	High (AI patterns)
Prod data in staging	Yes	No	No	No
Maintenance	Ongoing	Ongoing	Ongoing	Zero

Tallied side by side, the trade-offs are stark. A pg_dump buys realism but drags along compliance exposure, gigabytes of infrastructure, and endless maintenance, while the fixtures-or-Faker route runs the same bargain in reverse, staying safe at the cost of realism and engineering time. Seedfast sits outside that trade entirely, generating rows that are realistic and PII-free with almost no upkeep.

Frequently asked questions

Is it a GDPR violation to use production data in staging?

It is rarely illegal outright, but hard to defend. GDPR's lawful-basis and minimization duties both point away from parking a full production copy somewhere with looser access, and auditors log staging-side production data as a finding you will have to explain.

How do you refresh a staging database without copying production?

Generate it from your schema on demand, so nothing gets dumped or masked out of production. Pointed at a database connection, Seedfast writes fresh, connected rows that fit every table, so each refresh fills staging without a production record leaving home.

Is synthetic data realistic enough for staging and demos?

It is, when the generator honors your schema and models real distributions. Seedfast clusters timestamps, weights status fields toward common values, and keeps amounts in believable ranges, so a dashboard or demo reads as genuinely active.

Does generated staging data keep valid foreign keys?

Yes, every generated reference lands on a row that already exists, so joins never dangle. Schemas that loop back on themselves resolve too, provided one side of the loop is nullable or deferrable.

Can staging data generation run automatically in CI?

Yes, this is a standard unattended CI setup. With SEEDFAST_API_KEY set, the CLI skips the prompt and signals success or failure through its exit code. Since each run appends, start from an empty database, fresh or truncated. The same wiring behind generating synthetic data in your CI/CD pipeline applies here, pointed at a staging refresh.

What is synthetic staging data?

Synthetic staging data is data built from your schema to populate a staging environment, standing in for a copied or masked production dump. Mirroring your tables and their realistic distributions while matching no real person, it carries no PII and stays clear of GDPR and SOC 2 scope. A generator like Seedfast produces it straight from the live schema. For the wider tool set, see data seeding tools; for a Postgres comparison, the best Postgres test data generator.

Getting Started

Replace your staging refresh script with a single command:

# Install
curl -fsSL https://seedfa.st/install | sh

# Connect to your staging database
export DATABASE_URL="postgresql://user:pass@staging-db:5432/myapp"

# Seed it
seedfast seed --scope "seed 50,000 users with orders, payments, and support tickets"

Your staging database now holds realistic data with valid relationships and no production PII. A refresh like this finishes in minutes, and when the schema shifts next sprint you rerun the same command and skip the script edits.

Bring up staging without the compliance risk

Get Started | Documentation | Pricing

Seedfast fills staging with production-realistic data generated from your schema, matching real volume and patterns without ever pulling a customer record out of production.

Originally published at seedfa.st.

Small Data, Big Lies: 6 Bugs Your Test Suite Will Never Catch

Mikhail Shytsko — Sun, 16 Aug 2026 12:26:06 +0000

A green test suite with 94% coverage carried this PR into production unquestioned, and two hours later the on-call phone lit up — a 47-second orders page, an export endpoint OOM-killing its pods, pagination skipping page 7. Between the suite and production the only real difference was the data, 2 million orders in one and 12 in the other. That gap is the data volume blind spot , and almost every team has one.

Key Takeaways

Six bug classes stay invisible at 10 rows and become incidents at production scale: pagination off-by-one, N+1 queries, missing indexes, memory blowups, timeout cascades, and unique constraint collisions.
All six carry one signature, where passing tests hide a cost that climbs with row count until the bug surfaces in production.
The fix is to run the suite against realistic volumes before you deploy, turning each production incident into a failing test.
Seedfast populates your database with production-scale, foreign-key-valid rows, so your existing suite runs against realistic counts.

The Volume Blind Spot

Most test databases hold between 5 and 50 rows per table, fine for unit tests but enough to plant a dangerous assumption — that code passing at 10 rows will pass at 10 million. Small data hides whole categories of bugs that turn catastrophic at scale, and the sharpest version shows up when an AI agent leaves the tables empty rather than merely thin. Here are the six that bite most often.

1. Pagination Off-by-One

This is the one everybody has shipped at least once. A paginated API looks correct while one page of 10 rows covers the whole table. Push it to 10,001 rows and page 1001 comes back empty or duplicates page 1000, depending on whether the offset math uses > or >=.

-- Looks correct with small data
SELECT * FROM orders ORDER BY created_at LIMIT 10 OFFSET ?

-- At scale: duplicate rows when created_at isn't unique
-- Rows shift between pages during concurrent inserts

The fix is usually cursor-based (keyset) pagination, but the bug hides until you have enough rows to fill several pages and timestamps dense enough to collide. The same holds in load testing with an empty database, where the plan you measure at 50 rows is nothing like production's.

How to catch it:

seedfast seed --scope "seed 10,000 orders with timestamps"

Then page through to the end and compare the item tally against SELECT COUNT(*); a mismatch is the bug.

2. N+1 Queries

An ORM loads a list of orders, and because each one lazily fetches its customer in a separate round-trip, the query count tracks the row count. A few orders cost a few queries nobody notices; a few thousand become a few thousand queries, and latency follows.

# 5 rows: 6 queries, 80ms
GET /api/orders → 200 OK (80ms)

# 5,000 rows: 5,001 queries, 12,400ms
GET /api/orders → 200 OK (12,400ms) # or timeout

How to catch it:

seedfast seed --scope "seed 5,000 orders with customers and line items"

Enable query logging and count; any list view firing more than ~10 queries has a problem.

3. Missing Indexes

Without an index, PostgreSQL scans 100 rows in well under a millisecond, so at development scale the query feels instant. The million-row version of that same scan runs for whole seconds, because the planner has no usable index and falls back to reading every row.

-- Fast at 100 rows (seq scan is fine)
SELECT * FROM users WHERE email = 'john@example.com';

-- 1M rows: 800ms full table scan
-- With index: 0.1ms

How to catch it:

seedfast seed --scope "seed 100,000 users with realistic email addresses"

Then run EXPLAIN ANALYZE on your critical queries; any sequential scan on a table over 10K rows is a red flag. The PostgreSQL test data cookbook has the SQL patterns for generating those volumes by hand.

4. Memory Blowups

Loading a whole result set into memory costs a few kilobytes at 100 rows and sails through every test, right up until the same endpoint meets 100,000 rows in production, allocates 500MB, and gets OOM-killed mid-request.

// Loads ALL rows into memory
rows, _ := db.Query("SELECT id, email FROM users")
defer rows.Close()
var allUsers []User
for rows.Next() {
    var u User
    rows.Scan(&u.ID, &u.Email)
    allUsers = append(allUsers, u) // grows unbounded
}

The same shape hides in export endpoints, report generators, batch jobs, and admin dashboards, anywhere code buffers a whole result set into an unbounded collection, harmless until production hands it enough rows to blow the heap.

How to catch it:

seedfast seed --scope "seed 100,000 users with profiles and activity logs"

Hit your export and report endpoints and watch memory; RSS climbing with row count means an unbounded query buffering the whole set.

5. Timeout Cascades

Service A calls Service B, which queries the database; while the tables stay small the query returns in 5ms. Once the tables have grown, the same query needs three seconds, blowing past Service A's two-second timeout, so the retry piles onto an already-busy Service B, and the circuit breaker trips and the dashboard goes red.

Small data: A → B (50ms) → DB (5ms) ✓
Large data: A → B (3.2s) → DB (2.8s) ✗ timeout
              A → B (retry) → DB ✗ timeout (DB now under double load)
              A → circuit breaker open ✗ cascade failure

A cascade like this needs volume, roughly 500,000 rows before one query is slow enough to breach a timeout and start the chain.

How to catch it:

seedfast seed --scope "seed 500,000 transactions with accounts and categories"

Run your integration suite and watch for requests nearing your timeout thresholds; one at 80% today is a timeout tomorrow as the table grows.

6. Unique Constraint Collisions

Test fixtures lean on hand-picked values like user1@test.com and user2@test.com, which never collide because a person chose each one. Real signups don't cooperate, producing duplicates at scale when two users register the same normalized address, or when a batch import slips in near-duplicates that pass validation alone but violate the constraint together.

-- Works with 10 hand-crafted rows
INSERT INTO users (email) VALUES ('user1@test.com');

-- Fails at 10,000 rows with realistic data distributions
-- ERROR: duplicate key value violates unique constraint "users_email_key"

Generated data spreads across a realistic distribution, so it includes the near-collisions a hand-written fixture set never thinks to add. Ask Seedfast for 10,000 emails and your unique constraints get exercised against genuinely varied input, all while foreign key relationships stay valid.

How to catch it:

seedfast seed --scope "seed 10,000 users with realistic names and emails"

A collision that surfaces under 10,000 realistic rows is one production never gets to spring on you, and volume closer to production scale flushes out more of these edge cases early.

The Pattern

Line the six up and the same four-part fingerprint appears every time:

Invisible at small scale — test suite passes, code review looks fine
Proportional to data volume — gets worse as tables grow
Discovered in production — where the data is, and the users are
Expensive to fix after the fact — incident response, hotfixes, post-mortems

The remedy never changes either, which is to test against realistic data volumes before deploying.

Shift Left With One Command

None of this needs a production copy, fixture factories hand-written for 50 tables, or SQL dumps that drift from the schema.

# Seed production-scale data in your dev/staging database
seedfast seed --scope "seed 100,000 users with orders, payments, and activity logs"

Point it at your database and it works out the right proportions across related tables, holding every foreign key valid. You describe the scope in plain English, review the plan, and approve:

Seeding Plan:
  public.users — 100,000 records
  public.orders — 450,000 records
  public.payments — 320,000 records
  public.order_items — 1,200,000 records
  public.activity_logs — 2,000,000 records

Total: 4,070,000 records across 5 tables

Approve? (Y/n)

Getting started is a free plan, no card required; if a run would outrun the credits on your plan, the CLI says so in the terminal. It writes only to the tables in your scope and never touches the rows already there.

In CI/CD

Add a seeding step to your pipeline so the test suite runs against real data volumes on every PR:

- name: Run migrations
  run: npm run migrate
  env:
    DATABASE_URL: ${{ secrets.DATABASE_URL }}

- name: Seed test database
  run: seedfast seed --scope "seed 50,000 users with orders" --output plain
  env:
    SEEDFAST_API_KEY: ${{ secrets.SEEDFAST_API_KEY }}
    DATABASE_URL: ${{ secrets.DATABASE_URL }}

- name: Run tests
  run: npm test
  env:
    DATABASE_URL: ${{ secrets.DATABASE_URL }}

With SEEDFAST_API_KEY set, the CLI runs non-interactively, so nothing pauses for a prompt in CI. Because a run only ever adds rows and never rewrites what a table already holds, repeating the same scope keeps growing the data. A clean repeat means starting empty, from a throwaway ephemeral database or freshly truncated target tables. The CI/CD database seeding guide covers the full pipeline, ephemeral per-PR databases included.

Start Small, Then Scale

You don't have to jump to a million rows. Start with enough to surface the first category of bugs:

Goal	Suggested scope	What it catches
Pagination bugs	1,000+ rows in paginated tables	Off-by-one, cursor issues
N+1 queries	500+ rows with relationships	Lazy loading performance
Missing indexes	50,000+ rows	Sequential scan bottlenecks
Memory issues	100,000+ rows	Unbounded collection growth
Timeout cascades	500,000+ rows	Cross-service timeout breaches

After the first bug, you'll want every PR run against realistic volumes as a habit. In our internal runs, Seedfast generated ~1M FK-valid rows on a 20-table SaaS schema in about 3.5 minutes. For the largest volumes, the large-volume seeding guide covers batching and scope tuning.

Frequently asked questions

Why do bugs only appear with large amounts of test data?

Because database behavior depends on how much data is in the tables, the same code takes different paths as it grows. The planner picks sequential scans on tiny tables and index scans on large ones, ORMs fan a relation into N+1 queries only once the list is long, and memory use tracks row count. At 10 rows none of that registers, so the defect waits until production supplies the volume that exposes it.

How much test data do I need to catch performance bugs?

Start at roughly 10× your current test volume and work up. Each bug class trips at its own threshold, all listed in the sizing table above. Watch for the point where latency stops scaling linearly with row count; that knee usually sits right on an architectural bottleneck.

What is the N+1 query problem?

It is the pattern where fetching a list of N records fires one follow-up query per record for a related row, so a single logical read becomes N+1 trips. Each query is fast, so the endpoint looks healthy until the list grows long, which is why thin test data hides it.

Can I just copy production data into my test database instead?

Copying production data drags PII and compliance exposure along with it. Under HIPAA, PCI-DSS, GDPR, or SOC 2, pulling real records into dev or CI collides with data-minimization and access-control rules, making it a compliance question before an engineering one. Exports also drift from the schema and break on the next migration. Generating from the schema gives you the same volumes with no real record in the pipeline. The schema shape itself (table and column names, types, constraints) does travel to an AI provider during generation, though row values never do, so teams whose naming alone is sensitive should weigh that path.

How does Seedfast generate production-scale test data?

You give Seedfast a plain-English scope and the volumes you want, and it produces connected relational rows with every foreign key valid on insert, then shows you the plan to approve first. Since it re-reads the schema on each run, a migration that would break a hand-written seed script gets picked up automatically.

Related guides

Load Testing With an Empty Database? Here's Your Problem — why an empty database makes every load-test number fiction
PostgreSQL Test Data: A Syntax Cookbook — the raw SQL patterns for generating volumes and distributions by hand
ALTER TABLE, 5 Million Rows, and the Deploy That Took Down the Site — the migration-at-scale cousin of these volume bugs
Enterprise Database Test Data: What It Actually Looks Like — what realistic relational test data looks like across a large schema
Get started with Seedfast — connect your database and run your first schema-aware seed

Test against realistic data before you ship

Get Started | Documentation | Pricing

Realistic volume is the whole fix here, and Seedfast is the shortest path to a database that has it.

Originally published at seedfa.st.

Database Seed File Maintenance: Stop Patching seed.sql

Mikhail Shytsko — Sun, 16 Aug 2026 12:25:53 +0000

Why your team quietly stopped running seed.sql months ago. A practical guide for PostgreSQL, MySQL, and ORM-based projects, not torrent .seed files or BitTorrent seedboxes.

Your seed.sql was committed by someone who left two years ago. It worked for three weeks. Then a migration landed, and it has been quietly broken ever since. Maybe it's called fixtures.sql, dev_data.sql, or testdata/init.sql, but it's the same file, headed toward the same fate.

This article is about seed file maintenance and answers why static seed files drift from the schema, what that drift costs in real engineering hours, how every mainstream ORM (Rails, Prisma, Django, Laravel) hits the same wall, and what to do once you stop pretending the file works. The short answer to how to maintain seed files in 2026 is that you shouldn't try. Seedfast reads your live schema on every run and regenerates FK-valid data from a plain-English scope, so there is no static artifact to drift.

If your team has a seed file that actually works on the current schema (without modifications, without commenting out lines, without someone saying "oh yeah, you have to run the migration first and then manually fix line 847"), you are in a vanishingly small minority, and that deserves congratulations.

Everyone else is stuck with the file they all know is broken and nobody wants to fix, and this article is for them.

TL;DR. Your seed.sql drifts because it's static. Stop hand-editing a snapshot of last quarter's schema, and let Seedfast regenerate FK-valid data from a plain-English scope, matched against today's schema. Reference rows you assert on by literal value (admin accounts, country codes, feature flags) stay in a short hand-written seed.sql. Bulk development data gets regenerated.

Try Seedfast free → to connect your DB and run the first seed in under five minutes.

If you're here because npx prisma db seed (or its Rails / Django / Laravel equivalent) just broke after a migration, jump to Try it on your seed file for the install + run snippet.

Key Takeaways

Seed file maintenance is structural, not disciplinary. A static file cannot keep up with a schema that changes every sprint. No amount of "be more careful" fixes that.
Every ORM has the same problem in a different syntax. Rails db/seeds.rb, Prisma prisma/seed.ts, Django fixtures, and Laravel seeders all break for the same reason, hard-coding the shape of your data.
The real cost shows up in onboarding, CI, and developer trust. A broken seed file turns a 2-minute setup into a 2-hour debugging session and teaches the team to distrust all shared data tooling.
Replace the bulk-data portion of the file with Seedfast. Instead of maintaining 500 lines of INSERT statements, describe the data you want in plain English; Seedfast regenerates matching rows straight from the current schema. Keep a small hand-written seed.sql for production reference rows and named-by-ID test fixtures.

The Life and Death of seed.sql

The lifecycle is so predictable it could be a template.

Week 1: Creation. A motivated developer, usually someone onboarding, writes a seed file that inserts users, orders, and products, whatever the app needs to look populated. It works, the PR gets merged, and the team is grateful. Local development is smooth enough that people actually use the app locally instead of staring at empty states.

-- seed.sql (v1, the golden age)
INSERT INTO users (id, name, email, created_at)
VALUES
  (1, 'Alice Johnson', 'alice@example.com', '2025-01-15'),
  (2, 'Bob Smith', 'bob@example.com', '2025-02-20'),
  (3, 'Carol Davis', 'carol@example.com', '2025-03-10');

INSERT INTO orders (id, user_id, total, status, created_at)
VALUES
  (1, 1, 99.99, 'completed', '2025-01-20'),
  (2, 1, 149.50, 'completed', '2025-02-15'),
  (3, 2, 75.00, 'pending', '2025-03-01');

INSERT INTO products (id, name, price, category)
VALUES
  (1, 'Widget Pro', 49.99, 'electronics'),
  (2, 'Gadget Plus', 29.99, 'electronics'),
  (3, 'Thingamajig', 19.99, 'accessories')

Week 3: First crack. A migration adds a NOT NULL column to users, but the seed file doesn't include it. New developers run the seed, get an error, and ask in Slack. Someone replies "oh just add role DEFAULT 'user' to the users table insert," but nobody updates the file.

ERROR: null value in column "role" of relation "users" violates not-null constraint
DETAIL: Failing row contains (1, Alice Johnson, alice@example.com, 2025-01-15, null)

Month 2: The patch. Someone gets frustrated enough to fix it, adding the missing column and noticing along the way that orders now has a shipping_address_id foreign key to a new addresses table, so they add an addresses insert block too. The PR is 200 lines of SQL changes for a file that was supposed to be "set and forget," and it passes review because nobody wants to think about it too hard.

Month 4: The second break. The products table gets renamed to catalog_items as part of a domain modeling cleanup, but the seed file still references products. Someone opens an issue, and it sits in the backlog for six weeks because it isn't a production bug, only a developer-experience gap.

Month 6: The workaround. The seed file has broken twice in two months, so a senior developer wraps it in a script:

#!/bin/bash
# run-seed.sh — "best effort" seeding
set -e # just kidding
psql $DATABASE_URL < seed.sql 2>/dev/null || echo "Seed had errors (this is normal)"

The || echo is doing a lot of heavy lifting there. "This is normal" is doing even more.

Month 9: Abandonment. The README still says "Run ./run-seed.sh to populate your local database," but new developers who try it watch it fail silently on half the tables, ask in Slack, and hear back "I just use the staging database" or "I manually insert what I need." The seed file is effectively dead. It still exists in the repo, since deleting it would mean acknowledging the problem and fixing it would mean taking on ongoing commitment nobody wants, so it just sits there, a monument to good intentions.

Month 12: The zombie. A new developer finds the seed file, spends two hours fixing it for the current schema, opens a PR, and the cycle begins again.

Why Do Seed Files Always Drift From the Schema?

Your schema changes constantly; your seed file stays static. That's the root of every drift problem below.

Consider a typical sprint. One developer adds a phone_number column to users. Another creates a user_preferences table with a foreign key back to users, while a third changes orders.status from a text field to an enum type, and a fourth adds a check constraint requiring orders.total to stay positive.

Each of these changes is small, each migration gets tested, and each PR gets reviewed, but none of them touch the seed file, since it isn't anyone's job to. The seed file isn't part of the feature, it isn't in the test suite, and it isn't in the CI pipeline either, or if it once was, it got removed six months ago for breaking the build too often.

The result is that the seed file drifts from the schema roughly in proportion to how fast your team ships schema-changing features, so the more productive the team is, the faster the seed file turns useless. Seedfast flips that relationship, so schema velocity stops being the enemy, and the faster the team ships migrations, the less there is left to maintain.

Nobody Owns It

This is the human problem underneath the technical one. Who is responsible for seed.sql?

The developer who wrote it moved to another team long ago; the developer who added the new column is too busy shipping features to maintain test infrastructure; the tech lead already has forty other things to worry about; and DevOps treats it as application-level data rather than infrastructure, so it isn't their job either.

Seed files are communal property, and communal property is everyone's responsibility and therefore nobody's. The same thing that happens to shared kitchen spaces in offices happens to seed files in repos, a slow, inevitable decay until someone snaps and does a deep clean. Except with seed files, nobody snaps; they just route around the damage.

Why Don't Migrations Update Seed Data Automatically?

There's a deeper structural issue underneath this one. Migrations transform schema forward in time, while seed files stay frozen in the past, and your migration system knows how to get from schema version 47 to version 48 without having any idea how to update the test data that was valid at 47 into something still valid at 48.

Some teams try to solve this by running seed files through the migration system, seeding at version 1 and then migrating up, which works fine until the first breaking migration, usually the third or fourth one, and from there you'd need to version your seed files alongside your migrations, maintaining parallel histories of schema changes and data changes that nobody keeps up for long.

Seed File Maintenance Across ORMs: Same Problem, Different Syntax

Switching to a "proper" ORM seeder does not make the maintenance problem go away; it just moves the work to a different file. Every mainstream stack hits the same wall:

Rails (db/seeds.rb). Use find_or_create_by! to stay safe to re-run, split by model, keep seeds environment-aware. Organization improves; the columns are still hard-coded, so a NOT NULL migration still breaks bin/rails db:seed.
Prisma (prisma/seed.ts). Recent Prisma versions decoupled seeding from prisma migrate dev and prisma migrate reset, so you now run npx prisma db seed explicitly (Prisma seeding docs). Adding a required field still breaks prisma.user.create({ data: { ... } }), just at compile time instead of runtime, but the manual fix is the same.
Django (fixtures vs factories). loaddata fixtures break on most schema changes; factory_boy generates rows from the live model, which is why guides have been recommending factories over fixtures for a decade (Caktus Group, 2013). Factories help, but every new field is a patch to the factory code.
Laravel (DatabaseSeeder + model factories). User::factory()->has(Post::factory()->count(3))->create() is composable, until posts gains a NOT NULL column and every seeder throws a QueryException. The Laravel docs recommend keeping seeders deterministic and in CI; that recommendation is what creates the PR backlog when schemas move.

The pattern is the same across all four. The syntax differs, but you are still writing a file that describes the shape of your data by hand. Every schema change forces a corresponding edit. For a side-by-side comparison of these tools and seven other seeding approaches, see Database Seeder: 7 Tools Compared.

The Hidden Cost of Seed File Maintenance

The seed file seems like a small thing, just a convenience file for local development, but a broken one does more damage than you'd think; seed file maintenance is the kind of work that doesn't show up in any sprint plan yet eats engineering time everywhere.

Onboarding Delay

A new developer joins the team, and the README says to clone the repo, run migrations, and run the seed file, but the seed file fails. Not knowing whether the failure is expected, whether their local setup is wrong, or whether they did something out of order, they spend an hour debugging before asking for help, and a senior developer spends another 30 minutes walking them through the workaround.

Multiply this by every new developer, every quarter, then multiply again by the morale cost, since the new person's first experience with the codebase is discovering that the documented setup doesn't work, which is not a great first impression of your engineering culture.

Broken Local Development

Without working seed data, local development means staring at empty states. The dashboard flashes "No data found," list views sit empty, searches return nothing, and graph components render nothing but a flat line.

Developers start creating data manually through the UI, which takes ten minutes every time they reset their database. Or they stop resetting their database, which means their local state diverges from everyone else's. Or they just develop against staging, which has its own problems (shared state, slow connections, risk of interfering with QA).

The empty local database is a productivity drain that's hard to quantify because it's spread across every developer, every day, in small increments, five minutes spent creating a test user here, ten minutes spent setting up an order with the right status there, twenty minutes spent building the exact data configuration a new feature needs to test, and it all adds up to hours per developer, every week.

CI Failures

If your CI pipeline includes a seeding step (it should), a broken seed file means broken builds, and teams typically pick one of three options.

Fix the seed file every time it breaks. This works, but it means someone is on permanent seed-file duty, patching SQL after every migration.

Remove the seeding step from CI. This is what most teams actually do. The CI pipeline now tests against an empty database, which misses entire categories of bugs that only surface at realistic data volumes.

Make the seeding step non-fatal. The || true approach. The seed runs, fails halfway, inserts data into some tables but not others, and the test suite runs against an inconsistent partial dataset. This is arguably worse than an empty database, because the failures are intermittent and hard to diagnose.

The "Just Comment It Out" Culture

The most corrosive effect of a broken seed file is cultural. When developers learn that the seed file is unreliable, they develop a reflexive distrust of all shared data tooling. Suggestions to invest in better seeding infrastructure are met with "we tried that, it didn't work." Proposals for data-dependent integration tests are rejected with "those will just break when the seed file drifts."

The broken seed file becomes a learned helplessness that prevents the team from investing in the thing they actually need.

The way out is structural, not motivational. If your team has been burned enough times to distrust shared seed tooling, the fix is to stop shipping a tool that requires trust in the first place. Seedfast regenerates straight from the schema's current state instead of asking a human to keep a file in sync, so there's nothing left for the team to lose faith in.

The 5-Minute seed.sql Health Check

Before you decide what to do next, run a quick audit. This script spins up a fresh database, applies your migrations, runs your seed file, and reports exactly how broken it is. For deeper guidance on writing a Postgres seed script that survives migrations, see Postgres Seed Script: Build One That Lasts. Copy this into scripts/audit-seed.sh.

#!/usr/bin/env bash
# audit-seed.sh — find the drift between seed.sql and your current schema.
# Usage: ./audit-seed.sh path/to/seed.sql
set -uo pipefail

SEED_FILE="${1:-seed.sql}"
DB="seed_audit_$(date +%s)"

# 1. Fresh database, latest migrations applied.
createdb "$DB"
trap 'dropdb --if-exists "$DB"' EXIT

# Replace with your project's migration runner:
# Prisma: DATABASE_URL=postgres:///$DB npx prisma migrate deploy
# Rails: DATABASE_URL=postgres:///$DB bin/rails db:migrate
# Django: DATABASE_URL=postgres:///$DB python manage.py migrate
# Raw SQL: psql "$DB" -v ON_ERROR_STOP=1 -f path/to/schema.sql

# 2. Run the seed, capture every error (default ON_ERROR_STOP=off lets us collect them all).
ERRORS=$(psql "$DB" -f "$SEED_FILE" 2>&1 \
  | grep -E "ERROR|psql:.*: ERROR" || true)

# 3. Check which tables ended up empty despite being referenced in the seed.
REFERENCED_TABLES=$(grep -iE "INSERT INTO ([a-z_][a-z0-9_]*)" "$SEED_FILE" \
  | sed -E 's/.*INSERT INTO ([a-z_][a-z0-9_]*).*/\1/' | sort -u)

echo "=== seed.sql health report ==="
echo
if [[-z "$ERRORS"]]; then
  echo "No SQL errors."
else
  echo "SQL errors found:"
  echo "$ERRORS"
fi
echo
echo "Tables referenced by the seed file and their row counts after running:"
for t in $REFERENCED_TABLES; do
  COUNT=$(psql "$DB" -Atc "SELECT count(*) FROM \"$t\"" 2>/dev/null || echo "MISSING")
  printf " %-30s %s\n" "$t" "$COUNT"
done

Three things to look for in the output:

Error lines. Each one is a migration your seed file has not caught up with.
Tables with 0 rows. The INSERT succeeded syntactically but every row was rejected by a constraint you forgot about.
MISSING tables. The seed file references a table that no longer exists (it was renamed, merged, or dropped).

Anything more than zero in any of those categories is drift. If this is your first time running the check, expect the report to be longer than you want it to be.

What Keeping seed.sql Alive Actually Costs Your Team

The strongest argument for a static seed file is "it's just a file, how expensive can it be?" Turn it into a number.

Maintenance cost per month, as a formula.

cost = (minutes_per_break * breaks_per_migration * migrations_per_month)
     + (new_dev_onboarding_minutes * new_devs_per_month)
     + (minutes_per_dev_per_day_on_empty_db * devs * broken_seed_days_per_month)

These numbers are illustrative; flip any input toward your actual team and the total moves. For a 10-person team that ships ~12 migrations a month, hires one engineer a quarter, and has a seed file that breaks on roughly one in three migrations:

Input	Value
Minutes to diagnose + fix one break	45
Break rate per migration	0.33
Migrations per month	12
Onboarding time lost to broken seed	90 min
New devs per month	0.33
Minutes lost per dev per day to empty-db workarounds (on days the seed is broken)	10
Broken-seed days per month (≈ one in three of 20 working days)	~8
Developers	10

That comes out to roughly ~178 minutes fixing breaks + ~30 minutes onboarding friction + ~800 minutes of empty-database workarounds per month, about 17 hours, more than two full engineering days, spent on a file that was supposed to save time. Both levers move that total. Reset the local DB less often, say twice a week instead of daily, and the dev-day-loss term shrinks; ship fewer schema-changing migrations and the break-rate term shrinks too. The exact figure matters less than the fact that it's never zero and that it scales with how much schema work your team ships.

Once you have a number, "just keep the seed file up to date" stops looking like a discipline problem and starts looking like a tax. Seedfast replaces that variable line item with a predictable subscription that does not scale with how often your schema changes.

Seed File Maintenance Coping Mechanisms

Teams develop creative ways to live with broken seed files, but all of them are worse than fixing the root cause, because seed file maintenance is structural, not behavioral, and these patterns route around the structure instead of changing it.

The Optional Seed

## Local Setup
1. Run `make migrate`
2. (Optional) Run `make seed` to populate test data

When the seed step is "optional," it means "broken." Nobody makes a working tool optional, and you don't see (Optional) Run the compiler in setup docs; the word "optional" is a signal that the team knows the tool doesn't work reliably and has decided to make that someone else's problem.

The Try-Catch Wrapper

# seed.py
for table in ["users", "orders", "products", "categories"]:
    try:
        run_sql(f"seed_{table}.sql")
    except Exception as e:
        print(f"Warning: {table} seed failed ({e}), continuing...")

Every error gets swallowed, so half the tables succeed and half don't, and the developer has no way to know which half. The local database ends up with users but no orders, products but no categories, and the app technically runs even though half its features are untestable. Nobody investigates the warnings, because there are always warnings.

The Versioned Seed

seeds/
  v1_initial.sql
  v2_add_roles.sql
  v3_add_addresses.sql
  v4_rename_products.sql
  v5_add_preferences.sql

This is the most disciplined approach, and it's also the most labor-intensive, since every migration that affects seeded tables requires a corresponding seed update. In practice, this means the developer writing the migration now has two files to update and test (the migration itself and the seed delta). The Neon team's guide to maintaining seed data lays out this approach carefully (version the file, automate execution, keep it safe to re-run), and it is the best you can do with a static file. It also describes roughly one full-time responsibility you did not have before, and compliance drops rapidly after the first month. If your database is hosted on Neon, their branching feature offers an alternative path (instant schema-and-data snapshots per branch), but that approach is platform-specific and does not help the vast majority of teams running Postgres elsewhere. The platform-agnostic alternative is to stop versioning seed deltas entirely. Seedfast regenerates FK-valid rows from a scope string against the schema as it exists this sprint, so there is no v6_*.sql file to write next sprint and no parallel history to maintain.

The Per-Developer Seed

Eventually, developers start maintaining their own personal seed files, each tailored to the features they happen to be working on, none of them complete, and none of them compatible with anyone else's. The team now ends up with N different versions of local state, where N is the number of developers.

"Works on my machine" takes on a new meaning when every machine has different data.

The team-by-team divergence is the moment most teams realize the file isn't recoverable. Seedfast replaces the per-developer sprawl with one command that pulls directly from the schema in front of it, so every developer gets the same shape of data because the schema, not a hand-edited file, is the source of truth.

The Fundamental Problem

All of these failures trace back to the same mismatch between bulk data that stays static and a schema that never stops moving.

A seed file is a snapshot, capturing the shape of your data at a single point in time, and the moment your schema evolves, which it does constantly because that's what healthy software projects do, the snapshot goes stale.

This isn't a discipline problem, and no amount of "just keeping the seed file up to date" fixes it, any more than "just checking your watch more often" fixes clock drift. The problem is structural, since you're using a static artifact to describe a moving target.

Instead of writing a better seed file, the fix is to regenerate the bulk data on each run from the schema itself.

How Do You Maintain Seed Files Without Maintaining Them?

What if your seeder read your current schema every time it ran?

This isn't a file that was written six months ago, a snapshot that assumed the products table still exists, or a script that hardcodes column names; Seedfast reads the actual, current, live schema on each invocation, every column, constraint, foreign key, and enum that exists right now, at this moment. Describe what you want in plain English; Seedfast generates FK-valid rows that match the schema as it stands. This is the core idea behind schema-aware test data generation, and it's why nothing here is left for a human to keep in sync.

Install once, then run it from any project directory.

npm install -g seedfast
# or: brew install argon-it/tap/seedfast
# or use it without installing: npx seedfast seed --scope "..."

seedfast connect # paste your DATABASE_URL when prompted
seedfast seed --scope "seed realistic data for all tables"

That's it. There's no SQL file to maintain for bulk development data, no new columns to add to the seed after migrations, and no foreign keys to wire up manually. Seedfast connects to your database, matches the schema's current shape, and generates data that fits. Reference rows your tests assert on by literal value (admin accounts, country codes, feature flags) stay in a small hand-written seed.sql; only the bulk development data gets regenerated.

When a migration adds a NOT NULL column next week, Seedfast sees it the next time it runs; when a table gets renamed, it uses the new name; when a foreign key gets added, it fills the column with a valid reference on the next run; and when an enum type gains a new value, it shows up in the distribution too, because there's no static file sitting between the schema and the data to fall out of sync.

Scope Instead of SQL

Instead of writing SQL inserts, you describe what you need in plain English.

# Instead of maintaining 500 lines of INSERT statements
seedfast seed --scope "seed 1,000 users with orders, payments, and support tickets"

Seedfast checks your schema, proposes a plan, and seeds. The scope description works today and will work next month, because it references concepts ("users with orders") rather than column names (user_id INTEGER NOT NULL REFERENCES users(id)).

When your schema changes, the same scope produces different data that matches the new schema, because the command and the intent stay the same; only the output adapts automatically.

What This Looks Like in Practice

Before (the seed.sql lifecycle):

Developer writes seed.sql (2 hours)
Works for 3 weeks
Migration breaks it (5 minutes to discover, 30 minutes to fix)
Works for 2 weeks
Another migration breaks it (someone files an issue)
Issue sits in backlog for 6 weeks
New developer fixes it (1 hour)
Works for 1 week
Two migrations land in the same sprint, seed file breaks in multiple places
Someone wraps it in || true
Team stops using it
Repeat from step 7 every few months

Cumulative time: dozens of hours per year. Effective uptime: maybe 40%.

After (seedfast):

# In your README
seedfast seed --scope "seed realistic data for all tables"

# In CI
seedfast seed --scope "seed 1,000 users with orders" --output plain

There is no step 2 through 12. The command works after every migration because it lines up with the tables as they exist at that moment. There is no SQL file to patch and no error-swallowing wrapper script to maintain, so the seed-after-each-migration treadmill goes away.

Does It Work on Real-World Schemas?

Toy schemas with users → orders → products are easy. The interesting question is what happens when Seedfast meets the kind of schema that has been running in production for three years. Here's a short, honest support matrix:

Foreign keys (single-column and composite): Every row comes out valid and connected, with no manual insert ordering required. Self-referential and looped foreign-key relationships are handled without special-casing.
Enum types and check constraints: Recognized and respected, with generated values drawn from the enum's members and passing the CHECK predicate.
Generated columns (GENERATED ALWAYS AS ...): Skipped on insert; the database computes them. Stored generated columns work the same way.
Partitioned tables (range/list/hash): Inserts go through the parent table; Postgres routes rows to the correct partition. No special configuration needed.
citext, jsonb, uuid, tsvector, numeric(10,2), geometric types: Supported via Postgres's type system; Seedfast generates type-correct values.
Triggers with side effects (audit rows, denormalized counts): They fire as written. If a trigger does something you don't want during seeding, disable it for the seed run the same way you would for a pg_restore, using ALTER TABLE ... DISABLE TRIGGER USER, then run the seed and re-enable it afterward.
Views, materialized views, and functions: Not seeded directly (they don't hold data). Materialized views you may want to REFRESH after seeding.
Multi-schema databases: Tables in non-public schemas are read and seeded as long as your DATABASE_URL user has access.

If your schema has something exotic that's not listed (extension-defined types, custom domains, row-level security policies that conflict with the seeding role), seedfast doctor will report what it can and can't handle before you commit to a run. The honest answer to "does this work on my real schema" is that in most cases it does, in some cases with one extra setup step, and seedfast plan will tell you exactly which before any rows are written.

In CI/CD

The seed file in CI is where the pain compounds, because CI failures block everyone. If you want the full walk-through for GitHub Actions and GitLab, the CI/CD database seeding guide covers exit codes and artifact patterns. Here's the short version.

# Before: fragile, breaks every few sprints
- name: Seed test database
  run: psql $DATABASE_URL < seed.sql # fingers crossed

# After: reads current schema every time
- name: Seed test database
  run: seedfast seed --scope "seed 5,000 users with orders and payments" --output plain
  env:
    SEEDFAST_API_KEY: ${{ secrets.SEEDFAST_API_KEY }}
    SEEDFAST_DSN: ${{ secrets.SEEDFAST_DSN }}

The --scope flag makes it non-interactive. To make the run idempotent, point each CI job at a fresh ephemeral database (e.g., a Postgres service container), since Seedfast appends rows rather than replacing them, so re-running against an already-populated database stacks more data on top. If you need a clean slate without recreating the DB, truncate the affected tables first.

For Onboarding

The before-and-after for new developers is dramatic.

Before: Clone repo. Run migrations. Run seed. Seed fails. Ask Slack. Wait for response. Get workaround. Apply workaround. Half the data loads. Manually create the rest. Time: 1-3 hours.

After: Clone repo. Run migrations. Run seedfast seed, review the proposed plan, hit Y. Time: typically 2 minutes on a small schema.

There's no debugging, no Slack, no workarounds anymore. The database comes populated with realistic data that matches the current schema, and the new developer sees a working dashboard on day one instead of an empty state with a TODO comment.

The Uncomfortable Truth About Seed File Maintenance

Your seed.sql isn't broken because your team is lazy, but because the premise itself is flawed, since asking a static file to keep up with a dynamic schema means asking for perpetual maintenance, and perpetual maintenance of non-production tooling is exactly the kind of work that gets deprioritized, postponed, and eventually abandoned.

The teams that have working seed files are the ones spending real engineering time on seed file maintenance, time that could be spent on features, on tests, on the product instead. Maintaining seed files is not a valuable use of engineering time; it's a tax you pay because the tool requires it. The answer to how to maintain seed files in any production codebase, eventually, is to stop trying. At enterprise scale the math only gets worse. See enterprise database test data for what compliance and volume add to the bill, and staging without prod data for why the regulated audience cannot just copy production into dev.

Stop paying the tax by moving the bulk data out of seed.sql, keeping only the reference rows your tests assert on by literal value, and letting Seedfast regenerate the rest to match the schema you actually have. Try Seedfast free →

Try it on your seed file

If your seed.sql is the file nobody wants to own, point Seedfast at the same database and let it generate the bulk data instead, matched to whichever tables are actually there when it runs. Reference rows your tests assert on by literal value, a handful of admin accounts or role names, stay in a short seed.sql. Everything else (the 500 users, 2,000 orders, the relational bulk that breaks every migration) gets regenerated on each run to match it.

# Try without installing — runs the latest CLI in this shell only:
npx seedfast connect
npx seedfast seed --scope "1,000 users with orders, payments, and support tickets"

# Or install once for repeated use:
# npm install -g seedfast
# brew install argon-it/tap/seedfast

There's no file to update after the next migration and no factory code to keep in sync. The schema is the source of truth, and Seedfast checks it fresh on each invocation.

On privacy. Seedfast's synthetic data generation does not require samples of your existing rows; the pipeline reads schema metadata (table and column definitions, types, FK relationships, constraints) and the scope text you provide. Your DATABASE_URL stays on your machine; the CLI connects to your database directly, and the password is never transmitted to Seedfast's servers. Note that DEFAULT expressions, CHECK constraints, and enum values are part of schema metadata and are transmitted as written; if any of those contain sensitive literals, treat them accordingly. See how it works for the full data-handling breakdown.

The free plan covers connecting and running the first seed, and small schemas typically fit inside its monthly credits. See pricing for current terms, or read the full walkthrough in the getting started guide.

Frequently Asked Questions

Why does my seed.sql break every time someone runs a migration?

Because a seed file is a snapshot of the schema at the moment someone wrote it, while a migration is, by definition, a change to that schema, and any migration that adds a NOT NULL column, a foreign key, a check constraint, or renames a table will break any INSERT statement that doesn't already account for it. Rather than remembering to update the seed after every migration, the fix is to generate seed data from the current schema on every run, so there's nothing left to remember.

What's the difference between a seed file and a migration?

A migration changes the shape of your database (CREATE TABLE, ALTER TABLE ADD COLUMN, DROP INDEX), while a seed file inserts rows into the shape that migrations created. Migrations are versioned, ordered, and applied once per environment; seed data is rerun on demand. The two get conflated because both can be .sql files, but migrations answer "what does my schema look like?" while seeds answer "what data lives in it?" Mixing rows into migrations is a common anti-pattern; it makes migrations non-replayable across environments.

How do I make my seed file idempotent (seed only once safely)?

Idempotency means the second run produces the same final state as the first. Raw SQL reaches for INSERT ... ON CONFLICT DO NOTHING against a unique key, Rails uses find_or_create_by!, Prisma uses upsert with where/create/update, and Django has the update_or_create queryset method. None of these solve drift; they only protect against duplicate rows when the same script runs twice. A seed that is safe to re-run still breaks the day a migration adds a NOT NULL column the script doesn't know about.

What changed in Prisma 7 — why was --skip-seed removed?

Prisma 7 decoupled seeding from migration commands, so prisma migrate dev and prisma migrate reset no longer auto-run the seed, and the --skip-seed flag was retired along with it because there is no automatic seed run left to skip. To seed, you call npx prisma db seed explicitly (Prisma seeding docs). The change is cleaner (migrations and seeding are now separate concerns), but it does not fix the underlying drift problem. Your prisma/seed.ts still hard-codes column shapes, and a required field added to the model still breaks db seed until you patch the file.

Can I just version my seed files alongside migrations?

You can, and some teams do. This is the most disciplined manual approach, adding a corresponding seed delta for every migration that changes a seeded table, one that reshapes the existing fixtures to match. In practice, compliance collapses within a few weeks, because every PR now costs a second file to update, and reviewers stop catching it. It works for very small teams with slow-moving schemas, but it doesn't scale.

What is the difference between fixtures, seed files, and factories?

Fixtures and seed files are both static artifacts, JSON/YAML/SQL that describe specific rows and are loaded verbatim, and they share the same drift problem. Factories (Factory Bot, factory_boy, Laravel model factories) are code that generates rows at test time using the current model definitions, so renaming a field is a compile-time error instead of a silent runtime failure. Factories are a clear upgrade over fixtures, but you still hand-write one per model, so schema changes still force edits, just in Ruby/Python/PHP instead of SQL.

Does Prisma's or Rails' built-in seeding solve seed file maintenance?

No. Prisma 7 actually removed automatic seeding from prisma migrate dev and prisma migrate reset (you now call npx prisma db seed explicitly), and Rails has always kept db:seed as a manual step. Both frameworks give you a nice place to put seed code; neither frees you from writing out the shape of your data by hand. Built-in seeders move where seed file maintenance happens, not whether it happens. See the database seeding overview for how ORM seeders fit into the broader picture.

Is "just make the seed safe to re-run" enough?

Safe-to-re-run (find_or_create_by!, ON CONFLICT DO NOTHING, upsert) is necessary but not sufficient. It prevents the second run from failing; it does nothing about the first run failing because a new required column was added. You still need to edit the seed to match every schema change. Re-runnability is table stakes, not a solution.

When should I still keep a hand-written seed file?

Two cases keep seed file maintenance worthwhile. The first is reference data that ships to production (country codes, role names, default feature flags), which is part of your application's contract and belongs in migrations or a narrowly scoped seed step. The second is specific named rows your tests assert on by ID , a handful of rows clearly separated from bulk development data. Everything else (the 500 users, 2,000 orders, 10,000 line items you need for realistic local dev and CI) should be generated on demand from the current schema.

How do I migrate from seed.sql to schema-aware generation without a big-bang rewrite?

Leave the existing file in place. Add seedfast seed --scope "..." to the end of your setup script so new developers get schema-fresh data. Once everyone is on the new command, drop the .sql file. There's no flag day and no coordination needed; the two approaches coexist fine because they both write to the same tables. The getting started guide walks through the first run.

Does `seedfast seed` replace `npx prisma db seed`?

It can, and for most teams it should. In package.json you can either swap the "prisma": { "seed": "..." } command to call seedfast seed --scope "...", or leave prisma db seed for a small handful of hand-written reference rows and point developers at seedfast seed for bulk data. Seedfast connects to the same DATABASE_URL Prisma uses, so there is no separate connection config. The Seedfast CLI doesn't care which ORM you use; it works from the schema in the live database directly.

What does Seedfast actually send to its AI provider — is my row data exposed?

Nothing leaves your machine except the shape of your database and the words you type describing what you want seeded. On the schema side, that means table and column names, data types, nullability, length limits, foreign keys, and constraint definitions, plus your natural-language scope text; the AI provider generates synthetic rows from that shape, never from samples of your actual data.

Your DATABASE_URL and its password never make the trip; the CLI uses them locally to connect to your database and nothing more. One caveat is worth knowing, though. Schema metadata includes DEFAULT expressions, CHECK constraints, and enum values exactly as written, so a sensitive literal buried in a default or a check constraint gets transmitted along with everything else, and the same goes for whatever you put in your scope text. For the complete breakdown, see how it works.

Related guides

Getting Started walks through installing Seedfast and seeding your first database
CI/CD Database Seeding automates seeding so nobody maintains scripts manually
Database Seeding: Methods and Best Practices covers how seeding works across SQL, ORMs, and generators
Database Seeder: 7 Tools Compared picks the right seeder tool for your stack, with a quick syntax reference per ORM
Supabase config.toml [db.seed] and sql_paths configures Supabase's seed pipeline through supabase/config.toml and the [db.seed] block, plus what happens on preview branches
Test Data Generation explains schema-aware data generation that adapts to migrations
E2E Test Fixtures shows how to replace JSON/YAML fixtures with generated data

Originally published at seedfa.st.