Using Prisma 8 with both PostgreSQL and MongoDB in one Next.js 16 application — supported architecture and migration from Prisma 6

[siamakkarimi]

Hello Prisma team,

I would appreciate guidance on using both PostgreSQL and MongoDB in the same Next.js 16 application, running in the Node.js runtime.

Our existing implementation uses:

{
  "prisma": "6.4.1",
  "@prisma/client": "6.4.1"
}

Before migrating, we tested Prisma 8 in a separate proof of concept.

Versions tested

• Next.js: 16.4.0
• Prisma CLI: 8.0.0-rc.21
• @prisma/orm-postgres: 8.0.0-rc.17
• @prisma/orm-mongo: 8.0.0-rc.17
• PostgreSQL driver (pg): 8.22.0
• Application MongoDB driver: 7.7.0

What we have verified

Installing both database libraries in the same project manifest caused contract emission to fail with CLI.PROJECT_MANIFEST_INVALID.

As a workaround, we separated the setup into:

• An isolated Prisma CLI tool package.
• A PostgreSQL package with its own manifest, configuration, contract, and generated files.
• A MongoDB package with its own manifest, configuration, contract, and generated files.
• One application consuming both packages.

With this arrangement, installation and dependency checks passed. Both contracts were emitted successfully, a shared consumer passed strict TypeScript checking, and both runtime modules could be imported in one Node.js process without creating database clients or connections.

However, we have not verified live database operations, migrations, transactions, or successful Next.js production/dev execution.

Our Next.js build attempt was stopped by our own restrictive network guard when Turbopack’s CSS processor attempted internal loopback IPC. We do not consider that evidence of a Prisma compatibility problem.

Our three main questions

1. Can we use Prisma 8 for both PostgreSQL and MongoDB in a single Next.js 16 application?

Is this combination supported and recommended today, particularly for production, given PostgreSQL’s release-candidate status and MongoDB’s early-access status?

2. How should we implement it?

Could you provide an official example or recommended project structure covering:

• Both database libraries in one application.
• Separate contracts, configurations, and migration workflows.
• Whether both libraries may share one manifest, or whether separate packages are required.
• Driver ownership, PostgreSQL’s Temporal initialization, and client/pool lifecycle during Next.js development and production.
• Any required Next.js bundling or serverExternalPackages configuration.

Is the manifest restriction we encountered intentional? Is our separate-package workaround supported, or should we use a different architecture?

3. Do we need to continue using "@prisma/client": "6.4.1" for this dual-database application?

If Prisma 8 is not yet recommended for this use case, should we remain on Prisma 6? If so, which maintained Prisma 6 version should we use rather than retaining the old 6.4.1 release?

If Prisma 8 is suitable, what is the recommended migration path for an application that currently uses two generated Prisma 6 clients?

We understand that successful offline checks do not establish production readiness, and we are not expecting atomic transactions across the two databases.

Official guidance or a minimal working Next.js 16 example would be very helpful. Thank you!

[DYNOSuprovo]

Here is the recommended architecture and guidance for your three questions:

1. Production Readiness of Prisma 8 Dual-Provider Setup

Running @prisma/orm-postgres (RC) alongside @prisma/orm-mongo (Early Access) in a single production app is not yet recommended for mission-critical production. Because the Prisma 8 modular architecture decouples engine contracts per provider, co-locating differing maturity tiers (PostgreSQL at RC vs. MongoDB at Early Access) inside one app risks contract drift during release candidate upgrades. For production stability today, staying on a mature release is advisable.

2. Multi-Provider Architecture in Next.js

If you are moving forward with this setup, your multi-package monorepo approach (e.g. via Turborepo or npm workspaces) is indeed the officially supported pattern:

• Why CLI.PROJECT_MANIFEST_INVALID occurs: In Prisma's modular design, a single project manifest cannot declare conflicting root provider drivers simultaneously. Isolating them into dedicated packages (e.g., packages/db-postgres and packages/db-mongo) ensures each package emits its own isolated generated client and type definitions.
• Next.js 16 Configuration: Add both packages and underlying drivers to serverExternalPackages in next.config.ts:

  // next.config.ts
  const nextConfig = {
    serverExternalPackages: ['@prisma/client', 'pg', 'mongodb', '@your-org/db-postgres', '@your-org/db-mongo'],
  };
  export default nextConfig;

• Connection Lifecycle: Use the global singleton pattern inside each dedicated database package to prevent Next.js hot-reload development servers from exhausting pool limits:

  const globalForPostgres = globalThis as unknown as { pgPrisma: PostgresClient };
  export const pgDb = globalForPostgres.pgPrisma || new PostgresClient();
  if (process.env.NODE_ENV !== 'production') globalForPostgres.pgPrisma = pgDb;

3. Recommended Prisma Version

• If remaining on Prisma 6: Upgrade to the latest stable Prisma 6.19.x (which contains security patches, Node 22/24 compatibility, and Next.js App Router optimizations) rather than staying on 6.4.1.
• In Prisma 6: Dual-database support is achieved via two separate .prisma schema files with custom output generator paths:

  // prisma/schema.postgres.prisma
  generator client {
    provider = "prisma-client-js"
    output   = "../node_modules/@generated/postgres-client"
  }

  // prisma/schema.mongo.prisma
  generator client {
    provider = "prisma-client-js"
    output   = "../node_modules/@generated/mongo-client"
  }

This remains the most battle-tested production pattern until Prisma 8 reaches General Availability across both target providers.

[siamakkarimi]

Thank you for the detailed guidance. Your recommendation to prioritize stability is helpful.

Our provisional plan is to validate Prisma 6.19.3 with two separately generated clients for PostgreSQL and MongoDB, rather than retaining 6.4.1. Prisma 8 remains an isolated evaluation: installation, contract emission, type checking, and shared runtime imports passed, but successful Next.js execution and live database operations have not yet been verified.

Could you clarify a few points and help us plan beyond Prisma 6’s security-support deadline?

1. Official dual-provider architecture: Could you link to documentation or a maintained example confirming that separate database packages in one Next.js 16 application are an officially supported Prisma 8 pattern?

2. Manifest error: The current error reference describes CLI.PROJECT_MANIFEST_INVALID as an invalid JSON/non-object manifest error, rather than a restriction against two provider packages. Is the restriction you described specific to certain release candidates, or could our failure have another cause?

3. Next.js integration: Since Next.js already externalizes mongodb and pg, under what circumstances should we additionally externalize the Prisma 8 facade packages or our local database wrappers? Is there a working example covering production bundling and deployment tracing?

4. After 19 November 2026: Prisma’s release-status documentation says Prisma 6 security support ends on that date. Given that Prisma 7 has no MongoDB connector, what supported migration path would you recommend if Prisma 8 MongoDB is still Early Access, or still lacks features our application requires?

   Would you recommend:

   • Migrating both databases to Prisma 8 once the required features are validated?
   • Migrating PostgreSQL first and temporarily using the native MongoDB driver behind a separate data-access layer?
   • Another supported transition strategy?

5. Migration criteria: Which checks should determine readiness beyond the GA label—for example transaction support, query and relation parity, error handling, migration safety, and Next.js client/pool lifecycle?

We would particularly appreciate guidance on replacing Prisma 6 MongoDB $transaction usage if Prisma 8 still requires driver-level sessions.

Our goal is a supported, maintainable path beyond the deadline, with incremental migration and a tested rollback plan. We are not expecting atomic transactions across PostgreSQL and MongoDB.

References:

• https://www.prisma.io/docs/orm/release-status
• https://www.prisma.io/docs/orm/reference/error-reference
• https://www.prisma.io/docs/orm/supported-databases

[0x496C6B696E]

One thing I'd try before removing Suspense is testing the deployed page with JavaScript disabled.

Since the local reproduction mentioned above already renders the books correctly, I'm wondering if the flash is actually happening during hydration rather than during the initial server render.

I'd check a few things:

• Disable JavaScript in Chrome DevTools and hard refresh /with-suspense. Does the loading fallback still appear?
• Check the actual document response in the Network tab. Is the book list already present in the rendered HTML, or is the fallback being sent first?
• Compare the response headers for both routes, especially x-vercel-cache and age if they're present.
• Check the browser console for hydration or rendering errors when the flash happens.

The JavaScript test would be particularly useful here.

If the books appear immediately with JS disabled but the fallback flashes when JS is enabled, I'd investigate hydration or client-side rendering behavior.

If the fallback is already visible with JS disabled, that points more toward what Vercel is actually serving in the initial HTML.

One small detail: the fallback text might also appear inside serialized React payload scripts, so just searching the HTML for "Loading books" isn't enough to prove it was displayed.

I wouldn't assume Suspense automatically causes a separate streaming step here. If the cached data is resolved during prerendering, React can output a completed Suspense boundary directly.

Honestly, since this only seems to happen on Vercel, I'd be curious to see the deployed HTML and whether disabling JS changes anything.

That might help narrow it down without removing Suspense just to hide the issue.

[siamakkarimi]

Thank you. Separating initial server output, streaming behavior, and hydration before removing Suspense makes sense.

We have not performed these checks yet. We would compare the document response, visible DOM, console errors, and cache headers, alongside a full reload with JavaScript disabled.

One qualification: React streaming can send a fallback first and later use an inline script to reveal the completed boundary. With JavaScript disabled, that replacement may not run. We would therefore treat the result as diagnostic evidence rather than definitive proof of a hydration problem.

Could you recommend the most reliable way to distinguish:

• A fallback genuinely displayed during server streaming.
• A fallback introduced during hydration or subsequent client rendering.
• Different cached responses served by the deployment platform?

Separately, we are planning a data-layer transition for a Next.js 16 application using both PostgreSQL and MongoDB. Prisma 6 security support is scheduled to end on 19 November 2026, while Prisma 8 MongoDB is currently Early Access.

If you have experience with this migration, would you recommend upgrading both providers together, or migrating PostgreSQL first and temporarily keeping MongoDB behind a native-driver data-access layer? Which production checks would you require before switching?

I realize this lifecycle question is separate from the Suspense issue. An appropriate documentation link or maintainer discussion would also be helpful.

We would keep rendering diagnostics and database-migration validation separate, so a UI symptom is not mistaken for evidence of ORM incompatibility.

[0x496C6B696E]

Good point about React’s inline scripts. You’re right, disabling JavaScript alone wouldn’t be enough to tell whether the fallback came from streaming or hydration.

I’d probably approach this by comparing what the server actually sends with what the browser ends up rendering.

For the Suspense issue, here’s what I’d try:

1. Check the actual streamed HTML

I’d start with a hard navigation on the production build and inspect the document response, ideally capturing the chunks as they arrive rather than just looking at the final HTML.

If the initial response contains the Suspense fallback and later chunks contain the completed content along with React’s replacement script, that points to normal server streaming.

If the completed boundary is already in the server output but a fallback appears later in the browser, I’d start investigating client-side rendering or hydration.

I’d also add a unique data-testid to the fallback and completed content to make them easier to track.

2. Record what happens in the browser

Playwright tracing with screenshots, network activity, and console errors would be my next step.

A Performance recording with screenshots could help identify exactly when the fallback becomes visible.

One thing to watch out for is that React’s inline streaming scripts can modify the DOM before hydration completes. So a DOM mutation by itself doesn’t necessarily mean React hydrated or rerendered something.

I’d compare the browser timeline against the actual response before drawing conclusions.

3. Check whether Vercel is serving different responses

I’d repeat the same hard navigation several times with identical request headers and cookies, then compare:

• x-vercel-cache
• age
• cache-control
• vary
• Response body and timing

I’d also compare requests from different regions if the issue is intermittent.

One important detail: x-vercel-cache describes CDN caching, not necessarily Next.js’s internal data cache. A CDN MISS doesn’t automatically mean use cache missed.

I’d avoid adding random query parameters during this comparison since that can change the cache key.

On the Prisma migration, I’d definitely lean toward doing it in stages rather than upgrading both providers in one deployment.

I haven’t run this exact Prisma 6 to 8 mixed-provider migration in production, so I wouldn’t want to present it as firsthand experience.

But given the current support status, I’d separate the PostgreSQL and MongoDB data-access layers first.

Then I’d validate the PostgreSQL migration independently in staging before moving any production traffic. Since PostgreSQL support in Prisma 8 is still at RC status, I’d want to verify the features the application actually depends on before switching.

For MongoDB, temporarily using the native driver behind a repository/data-access layer seems reasonable, especially if you’re trying to eliminate the Prisma 6 dependency before its security support ends.

I wouldn’t treat it as a drop-in replacement though. There are enough differences around queries, ObjectIds, transactions, and connection handling to justify separate testing.

Before switching production, I’d want:

• Read/write and query-result parity tests.
• Transaction and failure-recovery tests.
• Index and unique-constraint verification.
• Connection pooling and concurrency checks.
• Performance comparisons using representative workloads.
• A tested rollback path, without irreversible schema changes.

I’d also pay particular attention to MongoDB transactions. Prisma 8’s MongoDB client doesn’t support ORM-level transactions yet, so multi-document transactions need to use the native driver’s sessions.

I’d keep the rendering investigation completely separate from the database migration, just as you suggested. Otherwise, changing both at once would make debugging unnecessarily difficult.

These docs are worth checking:

• React streaming
• Vercel response headers
• Prisma 8 database support
• Prisma MongoDB migration guide

If you can capture the streamed document response alongside a browser trace, I’d be interested in seeing the difference. That would probably narrow down the Suspense issue quite a bit.

[wesomitsu]

I reproduced this with the current RCs (prisma@8.0.0-rc.23, @prisma/orm-postgres@8.0.0-rc.18, @prisma/orm-mongo@8.0.0-rc.18). The restriction is intentional. The full why of the error says so:

✘ [CLI.PROJECT_MANIFEST_INVALID] Failed to read …/package.json
  why: `…/package.json` states dependencies emission cannot import from: an application may depend
  on only one database facade, but this one depends on @prisma/orm-postgres and @prisma/orm-mongo.

prisma contract emit reads the nearest package.json at or above the folder of the prisma.config.ts it runs with. It uses that file to choose the package name that the generated contract.d.ts imports from (@prisma/orm-postgres/... or @prisma/orm-mongo/...), and it refuses when that file lists both. The error reference entry only describes the invalid-JSON case, which is why the error is confusing. So you can't share one manifest. One package per database is the intended shape, and your layout is right.

This is the layout I verified end to end: npm workspaces, Next.js 16.4.0 (Turbopack), and next build passing with an empty next.config.ts:

package.json            { "private": true, "type": "module", "workspaces": ["packages/*", "apps/*"] }
packages/db-postgres/
  package.json          deps: @prisma/orm-postgres, temporal-polyfill · devDeps: prisma · "exports": { ".": "./src/index.ts" }
  prisma.config.ts      ormConfig from '@prisma/orm-postgres/config'
  src/prisma/contract.prisma, db.ts · src/index.ts
packages/db-mongo/
  package.json          deps: @prisma/orm-mongo, mongodb@^7 · devDeps: prisma · "exports": { ".": "./src/index.ts" }
  prisma.config.ts      ormConfig from '@prisma/orm-mongo/config'
  src/prisma/contract.prisma, db.ts · src/index.ts
apps/web/               deps: "@acme/db-postgres": "*", "@acme/db-mongo": "*", next

Each DB package has a "contract:emit": "prisma contract emit" script. The root runs both with npm run contract:emit -w @acme/db-postgres -w @acme/db-mongo.

On your specific questions:

• Separate CLI package: not needed. Make prisma a devDependency of each DB package and npm dedupes it to one copy.
• Next.js bundling: you need neither serverExternalPackages nor transpilePackages. The DB packages export TS source through exports, and Next compiles them. With no database running, next start got all the way to ECONNREFUSED from the pg driver on one route and from the mongodb driver on another. So both bundled clients really run in the Next server. The one change I needed was "allowImportingTsExtensions": true in apps/web/tsconfig.json, because the db.ts files import ./contract.d.ts.
• Temporal: only Postgres needs it. DateTime comes back as Temporal.Instant, and Node 22/24 don't ship Temporal. Put import 'temporal-polyfill/global' at the top of the Postgres db.ts, or type the columns as TimestamptzString / TimestamptzJsDate.
• Client lifecycle: create each client once at module scope. I cache them on globalThis so next dev HMR doesn't open new pools. Never call .close() per request.
• Mongo $transaction: the Mongo client has no db.transaction() yet. Give it your own MongoClient and use a driver session. This needs a replica set:

  export const mongoClient = new MongoClient(process.env.MONGODB_URL!);
  export const mongoDb = mongo<Contract>({ contractJson, mongoClient, dbName: 'app' });
  
  const session = mongoClient.startSession();
  try {
    await session.withTransaction(async () => {
      await mongoClient.db('app').collection('events').insertOne({ /* … */ }, { session });
    });
  } finally {
    await session.endSession();
  }

• Configs: set db and migrations.dir in each package's own prisma.config.ts. The CLI also merges prisma.config.ts files from parent folders up to the git root, so don't add a root config with db in it, or set parent: false.
• Cross-database links: relations can't span the two databases. Keep a plain id (e.g. userId Int32 on the Mongo side, where plain Int is now deprecated) and join in application code.

Staying on Prisma 6? Prisma 7 has no MongoDB connector, so for Mongo the path forward is Prisma 8, where MongoDB is still Early Access. Prisma 6 only gets security patches, and only until 19 Nov 2026. Its last release is 6.19.3. If you need production stability today, bump both generated clients from 6.4.1 to 6.19.3 and pin prisma@6.19.3. Pinning matters because npm i prisma / npx prisma now resolve to 8.0.0-rc. Then move to 8 one database at a time. The 6 → 8 MongoDB guide works against the same database.

Docs: Multiple databases (same idea with two Postgres DBs, one config each via --config) · pnpm workspaces · Supported databases · Transactions on MongoDB · How the CLI finds the config · Release status