Prisma v7 stops seeding for you, and the pooled URL will not finish the job

A walkthrough published on dev.to reports that in Prisma ORM v7, `prisma db seed` still works but is no longer triggered automatically by `prisma migrate dev`, so it has to be invoked explicitly or called from a CI step ^[1]. That is the kind of change that costs an afternoon rather than an incident, because nothing fails: migrations apply, the schema is right, and the tables are empty ^[1][8].

The guide's own onboarding scenario is the shape of the bug. A teammate clones the repo, runs `npx prisma migrate dev`, and ends up with thirty empty tables; the app boots and every list view is blank ^[9]. The same silence propagates into automation: without an explicit seed step, end to end tests hit empty queries and fail for reasons that have nothing to do with the change under test ^[10]. If your pipeline depended on `migrate dev` to populate fixtures, upgrading to v7 gives you green migrations and empty fixtures, and the test failures will point at your application code ^[17].

The second trap is louder but easier to misread. Prisma Postgres ships two TCP connection strings, a direct one at `db.prisma.io:5432` and a pooled one at `pooled.db.prisma.io:5432` ^[2][13]. According to the guide, the pooled endpoint runs through a transaction mode pooler that breaks long transactions and prepared statements, which is the same class of failure Neon and Supabase users hit on their poolers ^[3][4]. That one does throw, but it throws mid seed, which means a partially populated database that looks seeded until someone queries a relation that never got written. The recommendation is to point `directUrl` in `schema.prisma` at the direct URL and to configure `seed: "tsx prisma/seed.ts"` in `prisma.config.ts` ^[5]. For edge runtimes that cannot open a TCP socket, such as Cloudflare Workers and Vercel Edge, the guide points at `@prisma/adapter-ppg`, which exports `PrismaPostgresAdapter` and accepts the same direct connection string; for Node side seeds it says the plain TCP URL with the standard `pg` driver is simpler ^[6][7].

Two caveats about the source. It asserts the v7 behaviour change without citing Prisma's release notes or changelog, so confirm it against your own upgrade rather than taking a blog post's word for the state of your migration workflow ^[16]. And it is a vendor piece: the same article argues that hand written seed files break whenever the schema changes and recommends Seedfast, which reads the live schema on each run and regenerates connected data, for schemas past roughly fifteen related tables ^[11][12]. Treat the connection string advice and the v7 note as the usable content and the lifecycle argument as a pitch, particularly the framing that Prisma's docs cover the mechanics of `prisma db seed` but not the staleness problem ^[15].

What to watch: whether your CI configuration names the seed step explicitly, and whether whatever the seed connects to is the direct host. The regulated industry framing in the guide is real enough as a constraint, since a fresh Prisma Postgres project has no production data, no PII, and nothing to copy in ^[14], which means the seed script is the only source of realistic data and its silent absence is the failure you will not see logged.