What's the best practice for deploying migrations to an existing database without syncing schema to prisma?

[rjmccluskey]

Question

Background

My team is working on a new backend application for our multi-tenant platform. We have existing DBs (one per tenant) in mysql and we'd like our new application (which uses prisma) to reuse these DBs. There are tradeoffs for this approach which we are willing to accept because we'd like to isolate our customers' data to a single DB and take advantage of our existing infrastructure around that. The new application will only talk to the tables it knowns about and will never query the already existing tables, and vice versa.

We were hoping to only define the new tables in the prisma schema and for the shared DBs to be an implementation detail that the app doesn't need to know too much about. The problem with this is when we run prisma migrate deploy for one of our tenants we get an error Error: P3005: The database schema is not empty. Prisma assumes that the DB will be empty before deploying migrations for the first time.

We don't want to pull down the schema because we don't want this new application to know anything about it and introduce the risk of someone querying tables from the old application. Also, we don't want to maintain the schema in two different places.

Question

We realized one workaround is to create the _prisma_migrations table ahead of time before running prisma migrate deploy. If that table exists, then the error is not thrown and the migrations deploy just fine. But this feels really fragile. Does anyone know of a better way to handle this? Is our setup just fundamentally against prisma's use case? Would the prisma team be open to us contributing a PR to add a flag to prisma migrate deploy that ignores a non-empty DB when deploying migrations for the first time?

How to reproduce (optional)

1. Create a DB and add a table
2. Setup a simple prisma schema with a different table
3. Configure prisma to use the existing DB
4. Run prisma migrate deploy

Expected behavior (optional)

No response

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

• Database: MySQL
• Node.js version: 24.13.0
• Prisma version: 7.3.0

[YitzhakMizrahi]

I would not manually create _prisma_migrations. The supported version of that idea is to baseline the existing database with prisma migrate resolve --applied.

P3005 is Prisma Migrate saying: "this database is not empty, but I have no migration history for it yet." That is expected for an existing production/tenant database.

For your case, since you intentionally do not want Prisma to model the legacy tables, I would use a no-op baseline migration for each existing tenant DB, then let Prisma manage only the new tables from that point forward.

Rough shape:

mkdir -p prisma/migrations/0_existing_database_baseline
printf '%s\n' '-- Baseline existing tenant database. Legacy tables are intentionally unmanaged by Prisma.' \
  > prisma/migrations/0_existing_database_baseline/migration.sql

npx prisma migrate resolve --applied 0_existing_database_baseline
npx prisma migrate deploy

Run the resolve --applied step once per existing tenant database before the first migrate deploy.

After that, future migrations that create/change only your Prisma-owned tables should deploy normally.

A few caveats:

• Keep the baseline migration committed, so all environments share the same migration history.
• Do not manually insert rows into _prisma_migrations; let prisma migrate resolve do it.
• Prisma Client will only expose models in your Prisma schema, so leaving legacy tables out of schema.prisma is a reasonable boundary if the new app must not query them.
• On MySQL, you do not have PostgreSQL-style schemas to isolate Prisma-owned objects inside the same database, so naming conventions and DB permissions are worth using as extra guardrails.

Docs:

• Baselining: https://www.prisma.io/docs/orm/prisma-migrate/workflows/baselining
• migrate resolve: https://www.prisma.io/docs/cli/migrate/resolve