Prisma 7: the connection URL leaves the schema and the client needs a driver adapter

[AKogut]

Dependabot raised #263 (prisma 6.19.3 → 7.9.1). It fails every check, and not for a reason a lockfile bump can settle. Ran it locally to find out what it actually asks for:

error: The datasource property `url` is no longer supported in schema files.
Move connection URLs for Migrate to `prisma.config.ts` and pass either `adapter`
for a direct database connection or `accelerateUrl` for Accelerate to the
PrismaClient constructor.

So it is two changes, not one.

Scope

• prisma.config.ts in packages/db, holding the migrate connection URL that schema.prisma currently carries as url = env("DATABASE_URL")
• A driver adapter (@prisma/adapter-pg) wired into getPrismaClient() in packages/db/src/index.ts
• Every bare new PrismaClient() — roughly a dozen DB-gated test files across packages/queries, apps/api, apps/worker and apps/web construct one directly and would each need the adapter
• prisma/seed.ts, and the prisma block in packages/db/package.json that Prisma 7 no longer reads
• The migrate target in the Dockerfile and the deploy compose stack

The test-file spread is the part that makes this bigger than it looks: the adapter has to be constructed somewhere shared, or a dozen files grow the same four lines.

Why it is not urgent

The security reason to want Prisma 7 was deepmerge-ts — reachable through @prisma/config and fixed in its 8.x line. That is already handled by a scoped override in #266, so this is now a maintenance upgrade rather than a patch.

Suggested resolution

Close #263. Dependabot will raise it again on the next Prisma release, and by then this can be a considered migration rather than a bump that happens to be sitting in the queue.

[AKogut]

Attempted this and backed out. The migration is larger than the issue describes, and one of the reasons is a data-safety problem worth recording before anyone tries again.

?schema= is silently ignored by the driver adapter

Prisma 6 read the schema from the datasource url. Prisma 7's pg adapter hands the connection string to pg, which has no such parameter — so it is dropped without a word:

DATABASE_URL=postgresql://…/flakemetry?schema=flakemetry_test_db
Prisma 7 + pg adapter → {"s":"public","sp":"\"$user\", public"}

Meanwhile prisma migrate deploy still honours the parameter. So an instance running on a non-public schema would, after the upgrade, migrate one schema and read and write another — with no error at any point. That is the worst shape this mistake can take, and it is the reason to be slow here.

Setting options: '-c search_path=…' on the adapter fixes current_schema(), but not the whole problem: Prisma's generated SQL explicitly qualifies table names with a schema, so the qualification and the search path can still disagree. That is where I stopped.

What else it needs, confirmed by doing it

• prisma.config.ts holding the migrate url; url removed from schema.prisma. Both work.
• Every new PrismaClient() — 53 files — through one factory, so the adapter is constructed in a single place. Worth doing on its own merits.
• The client must not throw when DATABASE_URL is absent. Next collects page data at build time in a container with no database; raising there makes the web image unbuildable. PrismaPg tolerates an empty connection string and connects lazily, so this is fine once you know it.
• @auth/prisma-adapter@2.11.3 is the latest release and its peer range stops at >=6. pnpm resolves it a second copy of @prisma/client, and the web build fails on the type mismatch. A pnpm.overrides entry deduplicates it, and the stale store directories have to be cleared for the override to take effect — but this is pinning past a declared incompatibility in the authentication layer, which deserves its own decision.

Detection

The breakage does not show up in a normal test run. Package test suites pass individually, because everything then agrees on the wrong schema. It only appears under turbo run test --force, where suites for different schemas run concurrently and overwrite each other. main passes that same command, which is how I established the regression was mine.

Not urgent: the deepmerge-ts advisory that made Prisma 7 attractive is already handled by a scoped override in #266.