DEV Community: Mikhail Shytsko

Faker Doesn't Know What Your Data Means

Mikhail Shytsko — Sat, 11 Jul 2026 00:00:00 +0000

A single row of Faker output looks flawless. Call faker.name(), faker.email(), and faker.date_time_this_decade(), and back come Gloria Hettinger, gloria.hettinger@example.org, and a timestamp somewhere in 2023, each value drawn from a distribution that fits its column. Stack ten thousand rows like it and every column still survives inspection on its own.

What none of those rows carry is a relationship to the row beside them, or to the row in the next table over. That gap is the whole subject here, because realistic test data usually gets treated as a property of columns (realistic names, well-formed emails) when the realism that actually matters lives in the joins between them. Faker is the convenient example rather than the target; the same blind spot shows up in any generator that fills one column at a time.

What plausible hides

Generate a users table and an orders table in two separate Faker loops and each table looks right in isolation. The orders table has a user_id column full of integers in a believable range, none of them null, all of them the correct type. Whether any of those integers points at a user you actually generated is a question Faker was never asked.

The screenshot above is the ordinary result: five users numbered 1 through 5, five orders pointing at user IDs in the hundreds, a child table that inserts cleanly only because no constraint stood in the way. Add a real REFERENCES users(id) and the same seed script dies on the first orphaned row instead.

Coherent generation produces the opposite artifact. Every user_id in orders gets chosen from the set of users that exist, so a join across the two tables returns every row rather than silently dropping the orphans.

Getting that join to resolve completely is the floor, and clearing it proves almost nothing on its own. It is necessary, and nowhere near sufficient, which is the rest of this article.

Faker generates one column at a time, on purpose

This isn't a defect in Faker, it's the shape of the API. Each provider call returns a value for one domain from a source of randomness that holds no state about the calls before it or the columns around it, which is exactly what makes the library fast, composable, and easy to reason about. As the community puts it, "Faker generates individual field values independently, with no concept of relationships." A first_name and a last_name in the same row have no idea they share a row, and an email two columns over won't contain either of them unless you wire that up by hand.

For a great deal of work, that is the right tool. A unit test that needs one well-formed email, a single flat table with no foreign keys, a throwaway fixture you discard right after the assertion, none of these need cross-row reasoning, and reaching for something heavier only adds ceremony. Once an "AI" label gets stapled onto that same column-by-column approach, the shape underneath hasn't moved, and separating a genuinely schema-aware tool from a chat wrapper is exactly what the best AI test data generator comparison walks through. The trouble starts when the data has to hold together, not merely look right column by column.

Where valid and real diverge

Column values can each be individually plausible and still be collectively wrong, and the clearest case is numeric distribution. Faker will fill an amount column with values spread uniformly across a range, and uniform is precisely what money is not.

Real transaction amounts, account balances, invoice totals, and most quantities that span several orders of magnitude follow Benford's law, their leading digit landing on 1 about 30 percent of the time and on 9 under 5 percent. Balances skew log-normal, a few large accounts sitting over a long tail of small ones. Per-user activity skews Zipfian, a handful of power users producing most of the rows while everyone else trails off. A uniform column reproduces none of these shapes.

The distribution matters because your code and your database both read it. Postgres plans a query from the statistics it has gathered on a column, so a flat spread over ten thousand distinct values can steer the planner toward a sequential scan where production, with its skew, would reach for an index (or the reverse). A SUM over uniform amounts settles near a total that real data would never land on. Anything that ranks or thresholds, a top-accounts panel or a fraud rule that fires above a percentile, behaves against this data in a way it never will against the real thing. This failure is semantic rather than structural, the rows staying perfectly valid while meaning something the domain would never produce.

A foreign key checks existence, not meaning

Coherence has a second axis, one running across rows the schema connects rather than across columns in a single row. A foreign key enforces that the referenced row exists, and enforces nothing about whether the reference makes any sense.

So an orders row can point at a genuine customer and still carry a placed_at earlier than that customer's created_at, an order placed by an account that didn't exist yet. A subscriptions row can reference a billing period that never ran. A shipments row can belong to an order nobody ever paid for. Each of these satisfies referential integrity while being obvious nonsense, the sort a reviewer catches at a glance and a constraint check is built to ignore.

This is how a suite stays green against seeded rows and still sails past the bug a coherent dataset would have exposed. Let your E2E fixtures hold orders older than their own customers, and any test that should exercise an account-age or tenure calculation never meets a row that would break it.

What realistic test data actually requires

Put the two axes together and a working definition falls out. Realistic test data has to hold cross-column coherence inside each row, cross-row coherence across every table it connects to, and distributions shaped like the domain rather than like a random number generator. Meeting all three by hand means encoding the schema's insert order, its temporal rules, and its statistical profile into fixture code, then re-encoding them after every migration that moves any of it.

That maintenance burden is why most data seeding tools stop at column values and hand the relational and semantic work back to you. Closing the gap means reading the schema itself, on every run, instead of a snapshot that drifts the moment someone ships an ALTER TABLE.

Seedfast does that read live. It connects to your Postgres, reads the schema, and generates values inferred from each column's role, so a placed_at lands after the customer's created_at and an amount column comes out shaped like money instead of like random(). You describe the scenario in plain language and it fills the database in one command:

seedfast seed --scope "500 customers with orders, payments, and realistic balances"

Inside CI it runs as a pipeline step against a connection string, and inside an AI coding agent it runs through an MCP server, the agent calling the seedfast_run tool rather than writing a throwaway seed script that loses track of the relationships three tables deep. The broader comparison of test data generation methods covers where this sits next to SQL dumps and factory code, and the playbook on how to generate test data with AI covers the agent workflow in depth. The same coherence argument holds past a test suite: convincing demo data has to satisfy it too, just for a person watching the screen instead of an assertion reading a row.

Frequently asked questions

Is Faker output the same thing as synthetic data?

Faker output is one narrow kind of synthetic data, not the whole category. Synthetic data means any data generated rather than sampled from production, which spans everything from a single fabricated email to a fully coherent multi-table dataset with production-shaped distributions; the synthetic test data generation page walks that spectrum end to end. Faker occupies the column-independent end of that range, so "faker vs synthetic data" compares a specific library against a broad category rather than weighing two like-for-like options.

Why does a Faker-seeded database pass tests but break in staging?

A Faker-seeded database passes tests because most assertions check the happy path at tiny volume, where individual column values are all that gets exercised. Staging runs real queries against real row counts, where insert order, cross-row coherence, and distribution shape all begin to matter, and where the query planner picks different plans than it did against a handful of uniform rows. The data was never wrong in a way a small green test could see.

What is cross-column coherence in test data?

Cross-column coherence is the property that the values in a row agree with each other and with the rows they reference, so an order lands after the account that placed it existed and an invoice total matches the sum of its line items. Column-independent generators cannot produce it, because each value is drawn without reference to the others. The line it draws is between data that is individually plausible and data that is jointly true.

When does Faker stop being enough?

Faker stops being enough the moment correctness depends on relationships between rows rather than the format of a single value. As long as what you need is a well-formed value in an isolated column, it stays the right tool. Once the thing under test spans a foreign key, relies on a signup-before-order ordering, or reads a production-shaped distribution, test data quality turns into a schema-level property that a field-at-a-time generator can't reach.

The standard for realistic test data moved

For years, filling a database with per-column fakes was simply what generating test data meant, and for the narrow schemas of that era it was mostly fine. Schemas since then have grown wider and deeper, tests have crept closer to production shapes, and query planners have gotten better at exploiting the very statistics that uniform data fakes, so the bar for what counts as realistic has quietly risen from plausible columns to coherent, correctly-shaped, relationally-valid rows. A generator that can't read your schema can't clear that bar, however convincing its street addresses look. Seedfast reads the schema on every run and generates data that holds together across every table, and its 30-day free trial takes no card.

Originally published at seedfa.st.

Your Test Data Is Type-Correct and Still Invalid: 6 Postgres Schema Features Generators Skip

Mikhail Shytsko — Mon, 01 Jun 2026 19:25:26 +0000

Your Test Data Is Type-Correct and Still Invalid: 6 Postgres Schema Features Generators Skip

TL;DR: Composite primary keys, partial unique indexes, cross-column CHECK constraints, JSONB shape, GENERATED ALWAYS columns, and row-level security all reject type-correct data, because column types are not what your schema actually enforces.

A few months ago I watched a seed run finish with a clean green summary: every column populated, every type correct, a few thousand rows inserted. The first integration test then failed on an INSERT the application itself ran. The generated data was valid the way a sentence with correct grammar can still be a lie. Each value matched its column type. The combination of values broke a constraint the generator never looked at.

That gap has a simple cause. A column type is a per-column promise: this is an integer, this is text, this is jsonb. Most of what a real schema enforces is not per-column. It lives one level up: across columns in a row, across rows in a table, or across the role doing the writing. A generator that thinks in columns produces data that is type-correct and still invalid.

Here are six places that gap shows up in Postgres, what each one actually enforces, and a query you can run to see whether your own generated data respects it.

1. Composite primary keys: the tuple is unique, not the columns

A composite primary key enforces uniqueness over the combination of columns, not over each column on its own. The docs put it plainly: "the combination of values in the indicated columns is unique across the whole table, though any one of the columns need not be (and ordinarily isn't) unique."

CREATE TABLE enrollment (
    student_id integer,
    course_id  integer,
    PRIMARY KEY (student_id, course_id)
);

A column-by-column generator handles this badly in two opposite ways. It either treats student_id as a unique key and never lets a student enroll in two courses, or it generates both columns independently and produces duplicate (student_id, course_id) pairs that collide on insert. Both are wrong, and the second one only surfaces once enough rows exist to cause a collision, usually in CI rather than on a laptop with ten rows.

There is a second trap here: a primary key forces every participating column to NOT NULL. Adding a primary key "will force the column(s) to be marked NOT NULL," so a generator that emits an occasional NULL for a nullable-looking integer will fail against a column it didn't realize was mandatory.

To count the duplicate tuples your data would reject:

SELECT student_id, course_id, count(*)
FROM enrollment
GROUP BY student_id, course_id
HAVING count(*) > 1;

If that returns any rows, your generator is treating a tuple constraint as a set of column constraints.

2. Partial unique indexes: uniqueness with a WHERE clause

This is the one I see missed most often, because it isn't a constraint at all. It's an index, and generators that introspect constraints never see it. A partial unique index enforces uniqueness "among the rows that satisfy the index predicate, without constraining those that do not."

CREATE UNIQUE INDEX one_active_subscription
    ON subscriptions (user_id)
    WHERE status = 'active';

That index says: a user may have many subscriptions, but only one active one. A generator that produces realistic-looking subscription histories, several rows per user with a mix of statuses, will happily hand two of them status = 'active' and hit a unique violation that exists only for the active subset. Nothing in the column types hints at it. Nothing in the foreign keys hints at it. The rule lives in a WHERE clause on an index.

Diagnostic, to find the predicate subset that would collide:

SELECT user_id, count(*)
FROM subscriptions
WHERE status = 'active'
GROUP BY user_id
HAVING count(*) > 1;

Worth knowing: you cannot express this as a table constraint with ALTER TABLE ... ADD CONSTRAINT. Partial uniqueness only exists through CREATE UNIQUE INDEX ... WHERE, which is exactly why constraint-only introspection misses it.

3. CHECK constraints: the rule that spans two columns

A CHECK constraint can reference more than one column in the same row, and that cross-column form is where generated data falls down. A per-column generator picks each value in isolation, so it has no way to satisfy a rule that relates two of them.

CREATE TABLE bookings (
    starts_at timestamptz NOT NULL,
    ends_at   timestamptz NOT NULL,
    CHECK (ends_at > starts_at)
);

Generate starts_at and ends_at independently from a plausible date range and roughly half your rows will have an end before the start. Every value is a valid timestamp. The row is still rejected.

Two details that bite specifically during seeding:

NULL passes the check. A CHECK is satisfied when its expression is true or null. The columns above are NOT NULL, so it can't bite in this example, but the moment a checked column is nullable, CHECK (ends_at > starts_at) passes on every row where ends_at is null. On a nullable schema, write the diagnostic as WHERE col IS NULL OR NOT (...) so those rows aren't silently skipped.
NOT VALID constraints lie about coverage. A constraint added NOT VALID is enforced for new rows immediately but never checked against existing rows until you run VALIDATE CONSTRAINT. If you seed into a table that has a NOT VALID check, the seed is held to the rule even though the old data isn't.

Run the constraint expression as a query and count the violations:

SELECT count(*) FROM bookings WHERE NOT (ends_at > starts_at);

4. JSONB: the column type that enforces almost nothing

A jsonb column guarantees one thing: the value is valid JSON. It does not enforce keys, required fields, or value types. The structure "is typically unenforced," in the documentation's words. The shape your application depends on lives entirely in application code, not in the column.

This is a problem for generators in both directions. A naive generator drops '{}' or a random string-keyed blob into the column, it's valid JSON, the insert succeeds, and the first code path that reads payload->>'amount' gets null and breaks far away from the cause. A generator that knows the column is jsonb still has no schema to generate against, because Postgres never had one to give it.

You can pull some of the contract back into the database with a CHECK:

ALTER TABLE events
    ADD CONSTRAINT events_payload_shape
    CHECK (
        payload ? 'type'
        AND payload ? 'amount'
        AND jsonb_typeof(payload -> 'amount') = 'number'
    );

The explicit payload ? 'amount' test is doing real work. Drop it and a row with no amount key passes anyway, because jsonb_typeof(payload -> 'amount') returns SQL NULL on a missing key, and a CHECK is satisfied by NULL. It's the same trap as Section 3, hiding in a different operator.

Diagnostic, with absence treated as a violation rather than skipped over:

SELECT count(*) FROM events
WHERE payload IS NULL
   OR NOT (payload ? 'type')
   OR jsonb_typeof(payload -> 'amount') IS DISTINCT FROM 'number';

IS DISTINCT FROM is the key move: unlike = 'number', it returns true (a violation) when the left side is NULL, so a missing amount is counted instead of silently passing. If you have no such CHECK and no such query, your generated JSON is "valid" only in the sense that Postgres accepts it, not in the sense that your application will.

5. Generated columns: the value you must not write

A generated column is computed from other columns, and the docs are blunt about it: "A generated column cannot be written to directly." Try to insert one anyway and Postgres returns cannot insert a non-DEFAULT value into column.

CREATE TABLE line_items (
    quantity    integer NOT NULL,
    unit_price  numeric NOT NULL,
    total_price numeric GENERATED ALWAYS AS (quantity * unit_price) STORED
);

A generator that builds its column list by reading every column in the table will try to insert total_price and fail on the first row. A generator that simply skips unknown columns might omit a column that isn't generated. Knowing which columns are write-protected is the difference, and it is not visible from the column type. As far as the type system is concerned, total_price is just a numeric.

There's a version trap here worth flagging, because it changed recently. STORED generated columns arrived in Postgres 12, and through Postgres 17 the keyword was required: omit it and you get a syntax error, so every generated column on those versions is stored. Postgres 18 made the keyword optional and virtual the default, so an unqualified GENERATED ALWAYS AS (...) is now a virtual column computed at read time. That bites on upgrade. Virtual columns can't be indexed yet (planned for a later release), so a column that used to be STORED and indexed becomes un-indexable the moment someone drops the keyword. Always write STORED explicitly when you mean stored. The no-direct-write restriction applies to both kinds.

List the generated columns a writer must never populate:

SELECT column_name, is_generated, generation_expression
FROM information_schema.columns
WHERE table_schema = 'public'
  AND table_name = 'line_items'
  AND is_generated = 'ALWAYS';

6. Row-level security: "valid data" depends on who is writing

Row-level security is the feature that breaks the assumption underneath all the others, namely that whether a row is valid is a property of the row. Under RLS it is a property of the row and the role doing the write.

ALTER TABLE accounts ENABLE ROW LEVEL SECURITY;

CREATE POLICY tenant_isolation ON accounts
    FOR ALL
    USING (tenant_id = current_setting('app.tenant_id')::int)
    WITH CHECK (tenant_id = current_setting('app.tenant_id')::int);

The WITH CHECK clause is applied to every INSERT and UPDATE: a row whose tenant_id doesn't match the current tenant is rejected even though every value in it is type-correct and constraint-clean. Two facts compound this for anyone generating data:

The table owner bypasses RLS by default. Seed as the owner and every policy stays silent, so the data looks fine until the application connects as a normal role and the same rows turn out to be invisible or the same inserts get refused. Unless the table has FORCE ROW LEVEL SECURITY, your seed never exercised the policy.
Superusers and BYPASSRLS roles skip policies entirely. Seeding scripts often connect as exactly these privileged roles, so generate through one and you've tested nothing about the rules that govern real traffic.

Diagnostic, to see which tables have policies your seed role might be quietly bypassing:

SELECT schemaname, tablename, policyname, cmd
FROM pg_policies
ORDER BY tablename;

If those tables matter and your generator connects as the owner, your "valid" rows were never measured against the rules that decide validity in production.

Where the tools actually sit

None of this means generated test data is a bad idea. It means the question to ask a generator is not "does it produce realistic values" but "how much of the schema does it treat as input." Roughly three tiers exist today:

Free and DIY. Faker, ORM seeders, and hand-written scripts generate values per column. Relationships, table-level constraints, and the features above stay your job, in your code, kept in sync by hand.
Schema-aware generators. A newer middle tier reads the schema and treats its structure as a first-class input. Neosync and Seedfast are two of several tools that take this approach in different ways. The honest trade-off is that "schema-aware" is a spectrum. Foreign keys and NOT NULL are widely handled, while partial unique indexes, cross-column CHECKs, and RLS are exactly where coverage varies between tools, so it's worth testing each against your own constraints rather than trusting the label.
Enterprise TDM platforms. Anonymization and masking suites that transform production data. They cover a lot, at the cost of needing production access and a setup measured in weeks.

The useful question isn't which price tier a tool sits in, it's how far past column types it actually looks. Run your real constraints through any candidate before you trust it, whatever tier it claims.

A quick decision table

If your schema relies on...	Before trusting generated rows, check...
Composite primary keys	duplicate tuples, and `NULL` in any PK column
Partial unique indexes	uniqueness only within the predicate subset
Cross-column CHECKs	the expression as a `WHERE NOT (...)` query, adding `col IS NULL OR` for nullable columns
JSONB shape	required keys and value types via a CHECK or a probe query
`GENERATED ALWAYS` columns	the writer skips them;`STORED` is explicit on PG 18+
Row-level security	the seed role isn't the owner or `BYPASSRLS`

When none of this matters

Plenty of test data doesn't need to clear this bar. A unit test that touches one flat table is better served by a three-line fixture than by anything that introspects a schema. Not every column needs realistic values; sometimes 'x' and 1 are the honest choice because the test doesn't care. And there's a class of rules no generator can infer, the domain invariants that live only in your head or your application, like "a refund row must point at a captured payment." Those you encode yourself, or you assert in the test.

Generators aren't the problem here. The trouble is that "the insert succeeded" and "the data is valid" are two different claims, and the gap between them lives in exactly the schema features that never show up in a column type. Run the six queries above against your own generated data before you trust the green summary.

Database Seeding: What It Is, Methods, and Best Practices

Mikhail Shytsko — Sat, 04 Apr 2026 00:00:00 +0000

Database seeding is the process of populating a database with an initial set of rows before an application runs against it, so the schema isn't just structurally valid but contains the reference data, demo accounts, and test fixtures the application expects to find.

If you've ever written an INSERT statement into a file called seed.sql or seed.ts, you've done it. This guide starts there and works forward through ORM seeders, generated data, and what to do when none keep up — including the database part of vibe coding, where an AI tool scaffolds the whole app but leaves the seed file to you. The schema-aware approach at the end is what Seedfast was built around, best read after you've watched the conventional methods break.

If you're already past the "what is it" stage and comparing concrete tools (Laravel vs Prisma vs Drizzle vs standalone seeders), jump to the database seeder tool comparison.

Key Takeaways

Database seeding starts simple (a SQL file) and gets complicated fast as schemas grow; the problem isn't generating values, it's keeping seed data valid across migrations
Every major ORM has a built-in seeder (Prisma, Laravel, EF Core), but the data and relationships are defined manually, which means they break on schema changes just like raw SQL
Keeping foreign keys valid is what makes seeding hard at scale. Once tables form cycles or deep chains, hand-ordered inserts stop working, and the fix is a tool that keeps referential integrity intact for you instead of leaving it to a hand-maintained file
If your seed file is the bottleneck, the next step is generation, meaning tools that read the schema directly and produce data that satisfies constraints, so the seed doesn't need to be maintained alongside the migrations

What Is Database Seeding?

Database seeding is the process of populating a database with an initial set of data. The term comes from agriculture, where nothing grows until something is planted, and in databases it means inserting a starting dataset so the application has something to work with, whether that's three admin users for local development, a thousand products for a staging demo, or a connected dataset across 40 tables for integration tests.

There are two kinds of seed data, and teams routinely conflate them. Reference data lives in production and covers roles, categories, feature flags, country codes, and default settings; it's part of the application's contract and changes rarely. Development and test data is the opposite, fake users and sample orders that exist only outside production. Getting that fabricated data to cohere across columns is its own problem, and what Faker-style generation misses is where hand-written fixtures look plausible without holding up.

The confusion starts when teams use one mechanism for both. A seed.sql that inserts admin roles AND a thousand fake users couples two things that change at completely different rates, the roles almost never and the fake users constantly, so every later migration has to drag both through the same increasingly brittle file.

Why Seed a Database?

A freshly migrated database has tables but no rows. Every dashboard renders an empty state, every list view returns nothing, and every test that depends on a user or a product fails before it starts. Seeding solves three concrete problems at once:

Local development gets a populated UI, so new devs can click through real flows on day one instead of staring at empty tables.
Integration and end-to-end tests get data to assert against, since a test that checks "user sees their last 10 orders" needs 10 orders in the database before it runs.
Production gets the reference rows the app needs to boot cleanly; without them the application won't start on day one.

Skip it and every developer writes the same INSERT statements by hand, every CI run starts from a different database state, and onboarding degrades into "ask Marcus for a dump".

Database Seeding vs Database Migration

Migrations and seeds are often confused because they both run against the database before the application does. They are not the same thing.

	Migration	Seed
What it does	Changes structure (tables, columns, indexes)	Inserts data
Versioned?	Yes — strict order	No — should be idempotent
Runs in production?	Always, on every deploy	Reference data only; never test data
Repeatable?	Each migration runs once	Should produce the same end state on every run

The rule of thumb is that if you'd lose work without it, it's a migration, and if you'd lose realism without it, it's a seed. Mixing the two, whether that's test data inside a migration or schema changes inside a seed, tangles deploys in ways that surface at the worst possible moment.

Starting Simple: the seed.sql File

Every database seeding journey starts here:

INSERT INTO roles (id, name) VALUES
  (1, 'admin'), (2, 'editor'), (3, 'viewer');

INSERT INTO teams (id, name) VALUES
  (1, 'Engineering'), (2, 'Design');

INSERT INTO users (id, email, team_id, role_id) VALUES
  (1, 'alice@example.com', 1, 1),
  (2, 'bob@example.com', 2, 2);

Run it with psql -f seed.sql and your database has data, deterministically and under version control. For a 5-table schema that changes quarterly, this is fine. For writing a Postgres seed file from scratch, see Seed Database: PostgreSQL Step-by-Step Guide; for the failure modes that quietly break one, from FK ordering and idempotency to the migration that invalidates it, see Postgres Seed Script: Build One That Lasts.

The trouble starts the day someone runs ALTER TABLE users ADD COLUMN department_id INTEGER NOT NULL REFERENCES departments(id). The seed file doesn't insert departments, so the INSERT into users fails, and someone has to fix it, test it, and commit it. Multiply that across 30 tables and monthly migrations, and the maintenance cost becomes its own workstream.

How ORMs Handle Database Seeding

Every major ORM ships a seeding mechanism. The syntax varies from one framework to the next, but the pattern underneath is identical, since you're writing code that creates records through the ORM's API.

Prisma puts seeds in a TypeScript file:

import { PrismaClient } from "@prisma/client";
const prisma = new PrismaClient();

async function main() {
  const team = await prisma.team.create({
    data: { name: "Engineering" },
  });

  await prisma.user.create({
    data: {
      email: "alice@example.com",
      team: { connect: { id: team.id } },
    },
  });
}

main()
  .then(async () => {
    await prisma.$disconnect();
  })
  .catch(async (e) => {
    console.error(e);
    await prisma.$disconnect();
    process.exit(1);
  });
// Register the script under `prisma.seed` in package.json or prisma.config.ts,
// then run: npx prisma db seed

Laravel uses seeder classes:

// database/seeders/DatabaseSeeder.php
public function run(): void
{
    $team = Team::create(['name' => 'Engineering']);

    User::create([
        'email' => 'alice@example.com',
        'team_id' => $team->id,
    ]);
}
// Run: php artisan db:seed

EF Core (version 9 and later) uses UseSeeding and UseAsyncSeeding on the DbContext:

protected override void OnConfiguring(DbContextOptionsBuilder optionsBuilder)
{
    optionsBuilder
        .UseSqlServer(connectionString)
        .UseSeeding((context, _) =>
        {
            if (!context.Set<Team>().Any())
            {
                context.Set<Team>().Add(new Team { Name = "Engineering" });
                context.SaveChanges();
            }
        })
        .UseAsyncSeeding(async (context, _, ct) =>
        {
            if (!await context.Set<Team>().AnyAsync(ct))
            {
                context.Set<Team>().Add(new Team { Name = "Engineering" });
                await context.SaveChangesAsync(ct);
            }
        });
}
// Triggered automatically by EnsureCreated / Migrate, or manually via context.Database.EnsureCreated()

EF Core's older HasData API is now classified as "model managed data"; Microsoft recommends UseSeeding for general-purpose seeding because HasData runs as part of migrations and couples schema changes with row inserts.

ORM seeders improve on raw SQL. Typed languages like TypeScript and C# catch errors at compile time, the seed code lives alongside your app, and the ORM wires direct relationships through its own API.

The core problem survives, though. Data and relationships are still defined by hand, so a migration that adds a required column or changes a relation breaks the seeder the same way a seed.sql breaks, only in TypeScript or PHP or C#. You're also locked to one ORM, since a Prisma seed can't be reused if half your team runs Drizzle, which is why teams weighing a move look at how Seedfast's flat-rate pricing compares to metered or quote-gated tools. For a side-by-side of 7 database seeder tools on FK resolution and schema drift, see the database seeder tool comparison.

When Seeding Stops Being Simple

Most teams hit a wall around 15-20 tables, sometimes at the dependency chain, sometimes at circular references, and usually at all of them in the same week.

The dependency chain gets deep. To insert an order_item you need an order, a product, and a price; the order needs a user and a shipping_address, and the product needs a category and a vendor. That's three or four levels of dependency for a single line item, and the seed code becomes more about wiring IDs together than about the data itself.

Circular references show up next, and they're worse. A user carries a manager_id that points at another user, a category has a parent_category_id, and an employee belongs to a department whose own head_employee_id points back at an employee. Neither side can be inserted first, so a straight top-to-bottom insert fails outright, and getting it right by hand turns into fiddly, error-prone work.

Then migrations keep breaking the seeds. Every NOT NULL column, every new FK constraint, every renamed table sends someone back to the file, and on a codebase with weekly migrations seed maintenance becomes a recurring tax nobody budgets for, until the file stops working and a known-good dump gets passed around instead.

By now most teams either live with broken seeds, copy production (which can carry compliance considerations), or start comparing the best Postgres test data generators and best AI test data generators — or, when the data is specifically for a sales demo, a trial sandbox, or an investor walkthrough rather than a test run, a demo data generator. Some arrive after a previously adopted generator was orphaned, whether Snaplet Seed (shut down 2024, now stalled) or Neosync (archived 2025), weighing the same options.

Real Schemas, by the Numbers

The 15-20 table wall isn't folklore. Seed-run metadata from Seedfast, aggregated in July 2026, puts numbers on where real projects actually sit.

The median schema seeded through Seedfast has about 14 tables, and one schema in ten brings 25 or more. That is squarely the territory where hand-wired dependency chains stop being worth maintaining.
A typical seed run finishes in a few minutes , measured over the whole run from start to completion.
Most runs ask for fixture-sized data rather than bulk loads, with typical volumes in the hundreds of rows per run and the occasional load-test-scale exception reaching into the thousands.

The medians above cover completed seed runs from November 2025 through July 2026, are computed from run metadata alone rather than anything inside customer databases, and shift by only a table or two whether our own internal test runs are included or excluded.

Reading the Schema Instead of Writing the Data

Every failure mode above shares one shape. A human wrote the data, the schema moved, and the data went stale. The fix is to invert who reads whom, so the generator reads the schema and produces rows that satisfy the constraints it finds.

This is how Seedfast works. You connect it to your schema, with no production data or PII leaving your database, and it generates a full dataset from the schema itself — the rows come out connected and valid, with no relationships to wire up by hand.

# Point Seedfast at your database (connection string or DATABASE_URL)
seedfast connect

# Generate data from the current schema
seedfast seed --scope "e-commerce store with electronics products"

The two commands above are the whole setup once you install the CLI, and the same call happens automatically when Claude Code drives the seeding through Seedfast's MCP server instead of a terminal prompt. Seedfast reads your PostgreSQL schema and generates a dataset that respects your declared constraints and foreign keys. Tell it --scope "e-commerce store with electronics" and you get reviews that reference real products and users whose orders make sense together, because the flag describes the domain in words and the schema supplies the structure.

Because Seedfast reads the database rather than your ORM schema, it works with Prisma, Drizzle, TypeORM, Laravel Eloquent, EF Core, and others, whichever one defined your PostgreSQL schema. When a migration changes the schema, the next seedfast seed picks up the new structure, usually with no seed file to update.

# Quick local dev setup
seedfast seed --scope "small team with a few projects"

# Integration test data
seedfast seed --scope "3 users with 2 orders each"

# Staging demo
seedfast seed --scope "realistic e-commerce with 500 products and reviews"

For production reference data like roles and feature flags, a version-controlled SQL file is still the right tool, and the two pair well, since you run your reference seeds first and let Seedfast fill in around them.

Database Seeding in CI/CD

In a pipeline, database seeding needs to be automated, fast, and isolated. No shared databases between parallel test runs, no manual "run this script first" steps, no fixtures drifting from the schema. Python suites get the same guarantee from pytest database fixtures, scope and transactional rollback standing in for a reseed between tests. For a full pipeline setup guide, see the CI/CD database seeding docs, and for the service-container and health-check mechanics underneath it, see Seed a Postgres Test Database in GitHub Actions.

The ideal is a single command after migrations:

# GitHub Actions
steps:
  - name: Run migrations
    run: npx prisma migrate deploy
  - name: Seed test database
    env:
      SEEDFAST_API_KEY: ${{ secrets.SEEDFAST_API_KEY }}
    run: seedfast seed --scope "minimal checkout flow"
  - name: Run tests
    run: npm test

ORM seeders work here too, whether npx prisma db seed, php artisan db:seed, or EF Core seeding via dotnet ef database update, as long as the seeder script is maintained and the CI environment matches dev. A schema-aware generator needs no maintained script, so the same command works whether the last migration added one column or ten tables.

Many teams share one PostgreSQL database where each service owns its tables. There, Seedfast fills every service's tables in a single command, with none of the "seed users first, then orders, then payments" choreography. If your services use separate databases, that's a harder problem with its own strategies.

Database Seeding Best Practices

The first rule follows straight from the two-kinds distinction above. Production reference data belongs in migrations or a dedicated reference seed that runs in every environment, while test data belongs in a separate step confined to dev, test, and staging.

Make seeds idempotent. A seed that fails on its second run is a seed that breaks CI after a retry, so reach for INSERT ... ON CONFLICT DO NOTHING, upsert patterns, or a clear-and-reseed strategy.

Volume should match the use case, too. Tiny datasets hide bugs like broken pagination, missing indexes, and queries that only crawl at scale, so while local dev can stay small, integration tests should carry enough data to hit edge cases and load tests need production-scale volumes. The SQL patterns for producing that volume by hand, generate_series() and bulk \copy among them, live in the PostgreSQL test data cookbook.

Copying production is the shortcut to avoid. A pg_dump gives realistic data but drops PII into every environment that receives it, and quality masking is harder than it sounds, since you must catalog every PII-bearing column (JSON fields, free-text notes, audit logs) and keep that catalog current as the schema evolves. Miss one and PII leaks through. Generating synthetic data from the schema cuts this risk substantially, since production rows never leave production. (The generator still reads schema metadata like table and column names, so regulated teams should review what those names reveal.)

Automate, don't document. If your onboarding doc lists four commands to run in a specific order for a working database, that's a seed script waiting to be written, and the target is one command with no decisions left to whoever runs it.

Frequently asked questions

What is database seeding?

Database seeding populates a database with an initial dataset, either reference data for production or test data for non-production. Which method fits, from a SQL file to an ORM seeder to a schema-aware generator, depends mostly on how often your schema changes.

What is db seeding?

Db seeding is just shorthand for the same act. The abbreviation comes from tooling, since seed commands ship as db:seed in Laravel and Rails and prisma db seed in Prisma; the terms are otherwise identical.

What does it mean to seed a database?

You run a script against a freshly migrated schema and let its INSERTs execute, be it a seed.sql, an ORM seeder, or a generator reading the live schema. The point is turning an empty-but-valid database into one the app can run against.

What is seeding in database?

Seeding is the lifecycle step between migration and application start. Migrations build the structure and seeding supplies the contents, which is the difference between a database that's correct on paper and one a developer can click through or demo.

What is a seed script?

A seed script is the artifact that does the seeding, version-controlled and re-run when you need data, be it a .sql file, an ORM seeder class, or a one-command generator. A durable one is idempotent, so a second run changes nothing instead of erroring on duplicate keys.

What does seed data mean?

Seed data splits by where each kind may travel. Reference data (roles, country codes) ships everywhere including production, while development and test data (fake users, fixtures) must never reach it, which is exactly why the two belong in separate steps.

What is the difference between migration and seeding?

Both run before the app, hence the confusion, but they do opposite jobs. A migration changes structure and is versioned to run once; a seed adds rows and stays idempotent. Keep them apart, since a migration carrying test rows eventually breaks a deploy.

Why do we seed a database?

Because a valid but empty database is useless, all blank dashboards and tests that fail before they start. Seeding makes the schema usable, and a shared seed gives every developer and CI run the same starting point instead of whatever the last job left.

Should you seed a production database?

Only with reference data, the roles and default settings the app's contract depends on. Development and test data must never land there, so keep two separate steps, a small reference seed that runs everywhere including production and a larger dev/test seed confined to non-production.

What is idempotent seeding?

Idempotent seeding produces the same end state however many times it runs. The second run becomes a no-op instead of a duplicate-key crash, via INSERT ... ON CONFLICT DO NOTHING in PostgreSQL, find_or_create_by! in Rails, or upsert in Prisma, the minimum bar for CI where retries are routine.

What is a seed.sql file?

A seed.sql is the lowest-common-denominator seed, a plain SQL file of INSERTs you run with psql -f seed.sql after migrations build the tables. It has no dependencies and stays deterministic, but it's a snapshot of one schema version, so the next breaking migration invalidates it until someone edits it by hand.

How do I seed a database in CI/CD?

Add a seed step right after migrations, one command with no manual steps and no shared state across parallel runs. ORM seeders work if someone maintains the script, while seedfast seed skips that upkeep by reading the current schema on every run. Host mechanics vary, so on Neon seed the parent once and every branch inherits the data, while on Supabase, preview branches re-apply seed.sql on creation.

Does Seedfast work with my ORM?

The ORM barely matters, because Seedfast talks to the database rather than to your ORM. Prisma, Drizzle, TypeORM, Sequelize, Laravel Eloquent, EF Core, Django ORM, Rails ActiveRecord, SQLAlchemy, or raw SQL all work the same way, provided you're running PostgreSQL. Run your migrations first, then seedfast seed.

When should I use a seed file vs a generator?

Use a version-controlled seed file for small, stable, deterministic data like production reference rows; use a generator for data that has to span many tables, respect foreign keys, and survive schema changes without hand edits. For a category-level breakdown of DIY scripts, web generators, enterprise anonymization, and schema-aware generators, see the data seeding tools comparison; for a methods-level comparison, see Test Data Generation: 7 Methods Compared. On Postgres, the best Postgres test data generator comparison ranks options on schema-awareness, FK validity, and CI fit, and you can see how the tools stack up side by side on the comparison hub.

How does database seeding fit into test data management?

Database seeding is one mechanism inside test data management, the act of getting initial data into a database. Test data management is the wider discipline around it, deciding where data comes from, how it stays valid as the schema moves, and who can see it. The test data management guide covers the four-tier breakdown and the in-house framework that wraps this seeding work.

Seed your database in one command

The methods on this page fail in a predictable order. Seed files break first, ORM seeders break the same way a little later, and factory code holds out longest while costing the most to keep alive. What they all share is a human encoding the schema by hand, so a generator that reads the schema itself on every run is the one version of seeding a migration cannot invalidate. Building Seedfast around that idea is why, for PostgreSQL and whichever ORM sits on top, a migration that would break a seed file just produces the next dataset instead. The 30-day free trial runs on your own schema without a card, if you'd rather watch that happen than read about it.

Originally published at seedfa.st.