What is seeding a database? (fake data, real reasons)

What it actually is

Seeding a database means running a script that fills empty tables with a starter set of rows, so your app has something to display before any real person has signed up. Think of it like stocking a new store’s shelves before opening day: nobody’s bought anything yet, but products still need to be sitting there so a customer walking in, or you, testing the checkout flow, has something to click on.

Two different things get called “seed data,” and mixing them up causes real trouble. Development seed data is throwaway: fake users like alice@test.com, sample products with placeholder names, an order or two to test a status change. It exists purely so you and your agent aren’t testing against a blank screen. Production seed data is the opposite: real, permanent rows your app needs from day one, like a list of countries or a default admin account. Deleting that wouldn’t just look empty, it would break something.

Why your AI just did this

Right after your agent builds a table, a users table, a products table, it has no way to confirm that pointing your app at it will show anything. An empty table proves nothing about whether the queries or the relationships between tables work. So it writes a seed script. In Prisma projects that’s usually prisma/seed.ts, run with npx prisma db seed. In Supabase projects it’s supabase/seed.sql, run the first time you run supabase start, and again every time you run supabase db reset. Either way, the point is real rows to look at immediately, instead of you typing ten fake products into a form by hand.

It’s also how your agent tests relationships, not just single tables. A fake user, a fake order tied to that user’s id, is how it checks the foreign keys it just wired up hold together.

When you’ll run into it

• Your agent says something like “I added a seed script with some sample products so you can see the shop working” right after building a table.
• You open your app for the first time and see users named Test User or products called Sample Item 1. That’s seed data, not a bug.
• Running npx prisma db seed and getting Unique constraint failed on the fields: (`email`), meaning the script tried to insert a row that’s already there. Seed scripts need to be safe to run more than once.
• supabase db reset wipes your local database, reruns every migration, then runs seed.sql. That file only affects the local stack, it never touches live production data unless someone separately points it at a remote project.
• You ask your agent to “add some test data” and it either edits the seed file, which survives the next reset, or inserts rows by hand through the dashboard, a one-off that vanishes at the next reset.

What to check

• Ask whether the seed data your agent just added is throwaway or something your app depends on, like a default category or an admin account
• Before deploying to production, confirm the seed script isn’t set up to run there too. Fake test users in your live app is a sign it did
• If re-running a seed script errors instead of updating existing rows, ask your agent to make it idempotent, safe to run twice, usually by switching create to upsert
• Check that no real secret, an actual password or API key, ended up hardcoded inside a seed file that gets committed to git
• If your provider is Supabase, remember local seed.sql runs on supabase start and supabase db reset but doesn’t reach a remote project by itself

Say it like a dev

Instead of: “why is there fake stuff in my database” Say: “is this seed data from the setup script, and is it safe to delete before launch?”

Instead of: “add some test data so I can see it working” Say: “can you add this to the seed script so the data comes back every time we reset the database?”

Instead of: “will this wipe my real users” Say: “does this seed script only run locally, or could it touch production?”