Prisma v7-uses both MongoDB and PostgreSQL with separate Prisma schemas

[siamakkarimi]

Question

Hi! I have a project that uses both MongoDB and PostgreSQL with separate Prisma schemas and generated clients.

For now I'm using @prisma/client v6.4.1 for both databases:

• MongoDB → @prisma/client v6.4.1
• PostgreSQL → @prisma/client v6.4.1

The reason is that Prisma ORM v7 does not yet support MongoDB.

My question is: Is this the recommended approach for a production e-commerce application that uses both MongoDB and PostgreSQL?

Or would it be better to use:

• Prisma Client v6.4.1 for MongoDB, and
• Prisma ORM v7 for PostgreSQL

within the same project until MongoDB support is added to v7?

I'd appreciate any recommendations or best practices from the Prisma team. Thanks!

How to reproduce (optional)

Expected behavior (optional)

No response

Information about Prisma Schema, Client Queries and Environment (optional)

// Add your schema.prisma

// Add any relevant Prisma Client queries here

• OS:

• Database:

• Node.js version:

• Run prisma -v to see your Prisma version and paste it

[logusivam]

Your question is valid and the answer is confirmed by Prisma's official documentation and engineering team. Here is the precise, accurate picture.

---

Current status — verified facts

Prisma ORM v7 does not yet support MongoDB. Prisma's official documentation explicitly states: "If you are using MongoDB, please note that Prisma ORM v7 does not yet support MongoDB. You should continue using Prisma ORM v6 for now. Support for MongoDB is coming soon in v7." The currently recommended version for MongoDB is Prisma ORM v6.19, the latest v6 stable release.

MongoDB didn't make the v7 release because the architectural changes in Prisma 7 required deep rework at the query layer, and SQL databases were prioritized. This isn't a permanent statement about MongoDB — bringing MongoDB support back is described as a priority, but it isn't available today.

---

Direct answer to your question

Your current approach — using @prisma/client v6.4.1 for both MongoDB and PostgreSQL — is not the recommended production path going forward. It works, but you're holding PostgreSQL back to v6 unnecessarily, missing all v7 improvements for your relational layer.

Your second option — mixing v6.4.1 for MongoDB with Prisma ORM v7 for PostgreSQL in the same project — is the correct recommended approach. Here is why and exactly how to do it safely.

---

Recommended production setup — two separate clients, different versions

This is a supported pattern. Prisma's multiple schema / multiple client support means you can have both installed in the same project with isolated generated outputs.

Installation

# Install v7 for PostgreSQL
npm install prisma@7 @prisma/client@7 --save-dev

# Install v6 for MongoDB (as a scoped alias)
npm install prisma6@npm:prisma@6.19 prisma-client6@npm:@prisma/client@6.19 --save-dev

Directory structure

project/
  prisma/
    postgres/
      schema.prisma          ← PostgreSQL schema, Prisma v7
      prisma.config.ts       ← v7 requires prisma.config.ts
    mongo/
      schema.prisma          ← MongoDB schema, Prisma v6

PostgreSQL schema (v7 syntax)

// prisma/postgres/schema.prisma
generator client {
  provider = "prisma-client"          // v7 uses "prisma-client", not "prisma-client-js"
  output   = "../../generated/postgres"
}

datasource db {
  provider = "postgresql"
  url      = env("POSTGRES_DATABASE_URL")
}

model Order {
  id        String   @id @default(uuid())
  userId    String
  total     Float
  createdAt DateTime @default(now())
}

// prisma/postgres/prisma.config.ts — required in v7
import { defineConfig, env } from "prisma/config";

export default defineConfig({
  schema: "prisma/postgres/schema.prisma",
  migrations: {
    path: "prisma/postgres/migrations",
  },
  datasource: {
    url: env("POSTGRES_DATABASE_URL"),
  },
});

MongoDB schema (v6 syntax)

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

datasource db {
  provider = "mongodb"
  url      = env("MONGO_DATABASE_URL")
}

model Product {
  id          String  @id @default(auto()) @map("_id") @db.ObjectId
  name        String
  description String?
  price       Float
  stock       Int
}

Importing in your application

// Import PostgreSQL client (v7)
import { PrismaClient as PostgresClient } from '../generated/postgres';
import { PrismaPg } from '@prisma/adapter-pg';

const adapter = new PrismaPg({ connectionString: process.env.POSTGRES_DATABASE_URL });
const postgresClient = new PostgresClient({ adapter }); // v7 requires adapter

// Import MongoDB client (v6)
import { PrismaClient as MongoClient } from '../generated/mongo';
const mongoClient = new MongoClient();

package.json scripts

{
  "scripts": {
    "db:generate:postgres": "prisma generate --config prisma/postgres/prisma.config.ts",
    "db:generate:mongo": "prisma6 generate --schema prisma/mongo/schema.prisma",
    "db:migrate:postgres": "prisma migrate deploy --config prisma/postgres/prisma.config.ts",
    "db:push:mongo": "prisma6 db push --schema prisma/mongo/schema.prisma"
  }
}

---

Key differences between v6 and v7 you must account for

Area	Prisma v6 (MongoDB)	Prisma v7 (PostgreSQL)
Generator provider	"prisma-client-js"	"prisma-client"
Config file	--schema flag	prisma.config.ts required
PrismaClient instantiation	new PrismaClient()	Requires driver adapter: new PrismaClient({ adapter })
Auto-seeding on migrate	Yes	Removed — must run seed explicitly
prisma generate	Runs automatically after migrate	Must be run explicitly
$use() middleware	Deprecated	Completely removed — use $extends
Module format	CommonJS or ESM	ESM only
MongoDB support	Full	Not supported

---

Important caveats for your e-commerce production app

1. v7 requires a driver adapter for PostgreSQL — you cannot instantiate PrismaClient without one:

import { PrismaPg } from '@prisma/adapter-pg';
const adapter = new PrismaPg({ connectionString: process.env.POSTGRES_DATABASE_URL });
const prisma = new PrismaClient({ adapter });

2. Remove any $use() middleware — it is completely removed in v7. Replace with $extends:

// v6 (MongoDB) — $use still works
mongoClient.$use(async (params, next) => { ... });

// v7 (PostgreSQL) — must use $extends
const postgresClient = new PostgresClient({ adapter }).$extends({
  query: {
    $allModels: {
      async $allOperations({ operation, model, args, query }) {
        // your middleware logic
        return query(args);
      }
    }
  }
});

3. Auto-seeding is removed in v7 — if you relied on prisma migrate dev triggering your seed script for PostgreSQL, add an explicit seed step to your CI/CD pipeline.

4. When Prisma v7 adds MongoDB support, a second migration from v6 to v7 will be needed for the MongoDB client (ESM-only, driver adapters mandatory, new generator syntax). Design your MongoDB service layer to make this future migration straightforward — avoid tight coupling between your MongoDB and PostgreSQL service layers.**

---

Tracking MongoDB v7 support

There is a roadmap for MongoDB support laid out in Prisma discussion #29296. The recommended path is to stick to v6 as the stable production path until an official Release Candidate (RC) explicitly mentions MongoDB parity for v7. You can track the specific v7 milestone or connector/mongodb labels in the Prisma repo to see active PRs.

Hope this helps — if it answers your question, would you mind clicking "Mark as answer" so others searching for the same thing can find it quickly?

[aymenhmaidiwastaken]

The two-versions-in-one-project approach needs a bit more than installing both, and it's worth testing before you commit to it for production.

Installing them one after the other doesn't give you two clients — npm has a single name per package at the top level, so the second install replaces the first:

$ npm install @prisma/client@6.19.3
$ npm install @prisma/client@7.9.1
$ cat node_modules/@prisma/client/package.json | jq .version
"7.9.1"

The MongoDB client is simply gone at that point.

npm aliasing is the usual next idea, and it does put both on disk:

$ npm install prisma-client-v6@npm:@prisma/client@6.19.3
$ npm install @prisma/client@7.9.1

node_modules/@prisma/client        → 7.9.1
node_modules/prisma-client-v6      → @prisma/client 6.19.3

But it doesn't actually solve it, because the generated client doesn't import through the alias. Every generated file uses the bare specifier:

// generated/prisma/client.ts
import * as runtime from "@prisma/client/runtime/client"

Same in class.ts, prismaNamespace.ts, commonInputTypes.ts and each model file. A bare specifier resolves through normal node resolution, so both generated clients find whichever single @prisma/client sits in node_modules — one of them silently gets the wrong major's runtime.

What does work is giving each database its own resolution root, e.g. workspaces:

package.json          { "workspaces": ["packages/*"] }
packages/mongo        depends on @prisma/client 6.19.3
packages/pg           depends on @prisma/client 7.9.1

node_modules/@prisma/client                    → 6.19.3
packages/pg/node_modules/@prisma/client        → 7.9.1

Each package's generated client then resolves the bare specifier by walking up from its own directory and lands on the right major. Worth noting npm decides which one gets hoisted to the root, so don't rely on a particular layout — if you want that deterministic, pnpm isolates by default (I only tested npm here, so treat that as a suggestion rather than a verified result).

One other thing that may change your plan: both CLIs now scaffold the same generator. prisma init on 6.19.3 and on 7.9.1 both produce

generator client {
  provider = "prisma-client"
  output   = "../generated/prisma"
}

so neither version generates into node_modules/.prisma by default any more, and each schema emits to a path you choose. v7 also introduces prisma.config.ts. If your 6.4.1 setup still uses prisma-client-js, that migration is probably a bigger piece of work than the version split itself, and it might be worth doing that first on the MongoDB side while it's still on v6 — smaller change, and it makes the eventual v7 move mostly a version bump.

For what it's worth, splitting the two databases into separate packages is likely worth doing regardless of Prisma versions. You get one client per package, no ambiguity about which schema a query belongs to, and when MongoDB support does land in v7 you upgrade one package instead of untangling a shared node_modules.

[DucMinhNe]

Recommended Approach: Stay on Unified @prisma/client v6.x across the project

The short answer is YES, staying on @prisma/client v6.4.1 (or upgrading to the latest v6.x patch) for both MongoDB and PostgreSQL in the same project/package is the strongly recommended approach for a production e-commerce application.

Here is why attempting to split versions within the same project is problematic, along with the clean architectural patterns to follow.

---

Why mixing Prisma v6 and Prisma v7 in a single package is problematic

If you try to run @prisma/client v6 for MongoDB and @prisma/client v7 for PostgreSQL within the same Node.js project (package.json), you will run into several operational and build issues:

1. CLI Tooling Conflict (prisma CLI):
   The npx prisma generate command depends on the single prisma CLI version installed in your package.json. Version 7 of the CLI introduces new WASM/engine generator behavior. Running the v7 CLI against a v6 schema (or vice versa) causes generator mismatches and schema validation errors.

2. Engine / WASM Runtime Mismatches:
   Prisma v7 introduced significant changes to how the query compiler and WASM engine binaries are loaded. Having both runtime dependencies in one node_modules tree frequently leads to module resolution errors for @prisma/client and @prisma/engines.

3. Duplicated / Conflicting Global State:
   Even if aliased via package.json (e.g. @prisma/client-v6 vs @prisma/client-v7), shared internal types, tracing context, and telemetry handlers can collide at runtime.

---

Recommended Architectural Patterns

Option 1 (Recommended for Single App / Monorepo Package): Unified v6.x

• Keep both PostgreSQL and MongoDB schemas on @prisma/client v6.4.1 (or latest 6.x).
• Why: Stability is priority Rename postgres provider to postgresql #1 for a production e-commerce platform. Using unified v6 guarantees zero CLI conflicts, predictable builds, and identical client generation.
• Upgrade path: When Prisma ORM v7 officially releases MongoDB support, you can perform a single, clean upgrade for both databases simultaneously.

Option 2 (If you strictly need Prisma v7 features for Postgres today): Monorepo Package Isolation

If you require specific v7 features for PostgreSQL right now, you must isolate the dependencies at the package boundary using a monorepo structure (e.g., Turborepo, pnpm workspaces, or Nx):

my-ecommerce/
├── packages/
│   ├── db-mongo/         <-- package.json pinned to prisma & @prisma/client v6.x
│   │   ├── schema.prisma (provider = "mongodb")
│   │   └── index.ts
│   └── db-postgres/      <-- package.json pinned to prisma & @prisma/client v7.x
│       ├── schema.prisma (provider = "postgresql")
│       └── index.ts

This isolates the node_modules, prisma CLI versions, and generated WASM artifacts so they never collide during development or deployment.

---

Summary

For a single-package setup, sticking with @prisma/client v6.4.1 for both databases is the safest, most maintainable choice for production until MongoDB support lands in v7.