Migrate from Supabase

Move your PostgreSQL application data from Supabase to Prisma Postgres with pg_dump and pg_restore, then reconnect and verify your application.

This guide works with Prisma ORM 8, Prisma ORM 7, earlier Prisma ORM versions, and standard PostgreSQL clients. Moving your database does not require changing your ORM version.

You need:

• your Supabase database password
• access to the Supabase project's Connect panel
• a new, empty Prisma Postgres database
• the direct and pooled Prisma Postgres connection strings
• enough local disk space for the compressed database dump
• PostgreSQL 17 command-line tools: pg_dump, pg_restore, and psql

Confirm that all three tools use PostgreSQL 17:

pg_dump --version

pg_restore --version

psql --version

Each command should report version 17.x. PostgreSQL 17 pg_dump cannot dump a source server newer than version 17.

In your Supabase project, click Connect and copy the Direct connection URI. Set it as an environment variable:

export SOURCE_DATABASE_URL='postgresql://postgres:PASSWORD@db.PROJECT_REF.supabase.co:5432/postgres'

Supabase direct connections use IPv6 unless the project has the IPv4 add-on. If your network cannot reach the direct endpoint, copy the Session pooler URI instead:

export SOURCE_DATABASE_URL='postgresql://postgres.PROJECT_REF:PASSWORD@aws-0-REGION.pooler.supabase.com:5432/postgres'

Use only one of these URLs. Do not use the transaction pooler on port 6543. pg_dump needs session-level settings that transaction pooling does not preserve.

Check the connection, source version, and database size:

psql "$SOURCE_DATABASE_URL" \

  -X \

  --set ON_ERROR_STOP=1 \

  --command="SELECT current_setting('server_version') AS server_version, pg_size_pretty(pg_database_size(current_database())) AS database_size;"

The command should print the server version and database size. Stop if the source is newer than PostgreSQL 17 or if you do not have enough local disk space for the dump.

This guide exports the public schema by default. List your non-system schemas to identify any additional application schemas you created:

psql "$SOURCE_DATABASE_URL" \

  -X \

  --set ON_ERROR_STOP=1 \

  --command="SELECT schema_name FROM information_schema.schemata WHERE schema_name NOT IN ('information_schema') AND schema_name NOT LIKE 'pg_%' ORDER BY schema_name;" \

  --command="SELECT extname FROM pg_extension ORDER BY extname;"

Do not add Supabase-managed schemas such as auth, storage, realtime, supabase_functions, or supabase_migrations to the dump. Compare the extension list with the extensions supported by Prisma Postgres. Stop and decide how to replace or remove an unsupported extension before continuing.

Inspect row-level security policies in the schemas you plan to migrate:

psql "$SOURCE_DATABASE_URL" \

  -X \

  --set ON_ERROR_STOP=1 \

  --command="SELECT schemaname, tablename, policyname, roles FROM pg_policies WHERE schemaname = 'public' ORDER BY tablename, policyname;"

Add any other application schema names from the list above to the query filter. pg_dump does not copy PostgreSQL roles. Record the name of every policy that depends on Supabase roles such as anon, authenticated, or service_role. You will omit those policies during restore and recreate them for your new authorization design before switching the application.

Create a new Prisma Postgres database in Prisma Console:

1. Open your project and select the database.
2. Click Connect to your database.
3. Click Generate new connection string.
4. Copy both the direct and pooled connection strings.

Set the direct connection string for the import:

export PRISMA_POSTGRES_DIRECT_URL='postgres://USER:PASSWORD@db.prisma.io:5432/postgres?sslmode=require'

Confirm that the target is reachable and empty:

psql "$PRISMA_POSTGRES_DIRECT_URL" \

  -X \

  --set ON_ERROR_STOP=1 \

  --command="SELECT current_database(), current_setting('server_version');" \

  --command="SELECT schemaname, tablename FROM pg_tables WHERE schemaname NOT IN ('pg_catalog', 'information_schema') ORDER BY schemaname, tablename;"

The first query should report the Prisma Postgres database and PostgreSQL 17. The second query should not list any application tables.

You can rehearse this process while the Supabase database remains active, but do not use a rehearsal dump for the production cutover. Before the final dump, stop or drain every application, worker, scheduled job, integration, and administrative operation that can write to the Supabase database. Confirm that writes have stopped, and keep the source frozen until step 8 switches traffic to Prisma Postgres.

If you cannot keep the Supabase database frozen for the dump, restore, and validation window, stop here. Use a separately tested migration process that durably captures and replays every post-snapshot write. This snapshot-only process does not provide a zero-downtime cutover.

Create a private, compressed archive of the public schema. See the PostgreSQL 17 pg_dump reference for the other options:

umask 077

pg_dump \

  --format=custom \

  --verbose \

  --no-owner \

  --no-privileges \

  --schema=public \

  --dbname="$SOURCE_DATABASE_URL" \

  --file=supabase-to-prisma-postgres.dump

If you identified another application-owned schema in step 2, add another --schema=SCHEMA_NAME option. Do not add Supabase-managed schemas.

If the application already uses Prisma ORM, also add --schema=prisma_contract. This copies the database marker that connects the imported schema to your existing Prisma ORM contract.

Schema-filtered dumps do not automatically include extensions. For every supported extension from step 2 except plpgsql, add an --extension=EXTENSION_NAME option. For example, add --extension=pgcrypto if the application uses pgcrypto.

pg_dump should finish without an error and create supabase-to-prisma-postgres.dump. Treat this file as sensitive because it contains your application data.

Confirm that PostgreSQL can read the archive:

pg_restore --list supabase-to-prisma-postgres.dump | sed -n '1,20p'

You should see an archive header followed by database objects. If pg_dump reports a version mismatch, make sure the PostgreSQL 17 tools appear first in your PATH.

Prisma Postgres already contains an empty public schema. Create a restore manifest that keeps that schema and restores its contents:

pg_restore --list supabase-to-prisma-postgres.dump \

  | sed -E '/SCHEMA - public |COMMENT - SCHEMA public /s/^/;/' \

  > supabase-restore.list

The SCHEMA - public and COMMENT - SCHEMA public lines in supabase-restore.list should begin with ;.

If the policy check found policies that reference Supabase-only roles, list the policy entries:

grep ' POLICY ' supabase-restore.list

In a text editor, prefix with ; only the POLICY lines for the policy names you recorded. This omits the incompatible policies without omitting their tables or data. Recreate each omitted policy with target-compatible roles after the restore and before switching the application.

Restore the remaining archive entries through the direct Prisma Postgres connection:

pg_restore \

  --verbose \

  --single-transaction \

  --exit-on-error \

  --no-owner \

  --no-privileges \

  --use-list=supabase-restore.list \

  --dbname="$PRISMA_POSTGRES_DIRECT_URL" \

  supabase-to-prisma-postgres.dump

The command should finish with exit code 0. The single transaction leaves the target unchanged if an error stops the restore. Errors about missing roles usually mean a row-level security policy still references a Supabase-only role; errors about extensions mean the source depends on an extension that Prisma Postgres does not provide.

Refresh PostgreSQL's query-planner statistics after the restore:

psql "$PRISMA_POSTGRES_DIRECT_URL" \

  -X \

  --set ON_ERROR_STOP=1 \

  --command="ANALYZE;"

Create a reusable query that returns exact row counts for the migrated schemas:

\pset tuples_only on

\pset format unaligned

SELECT format(

  'SELECT %L || ''='' || count(*) FROM %I.%I;',

  schemaname || '.' || tablename,

  schemaname,

  tablename

)

FROM pg_tables

WHERE schemaname IN ('public', 'prisma_contract')

ORDER BY schemaname, tablename

\gexec

Add any other application schema names from step 2 to the IN list. With source writes still stopped, run the query against both databases and compare the results:

psql "$SOURCE_DATABASE_URL" -X --set ON_ERROR_STOP=1 --file=row-counts.sql > source-row-counts.txt

psql "$PRISMA_POSTGRES_DIRECT_URL" -X --set ON_ERROR_STOP=1 --file=row-counts.sql > target-row-counts.txt

diff -u source-row-counts.txt target-row-counts.txt

diff should print nothing and exit with code 0. Also rerun the extension and policy queries from step 2 against PRISMA_POSTGRES_DIRECT_URL. Resolve every unexpected difference while source writes remain stopped. Do not send production traffic to Prisma Postgres yet.

Choose the path that matches your application:

• I already use Prisma ORM 8
• I use Prisma ORM 7 or earlier
• I do not use Prisma ORM

Every path uses the two connection strings from step 3: the pooled URL for application queries and the direct URL for migrations and other CLI tools.

Keep your existing contract, migrations, and application code. Because you added --schema=prisma_contract in step 4, the imported database still carries the marker that ties it to your contract.

Set the pooled URL for runtime queries and the direct URL for Prisma CLI commands:

DATABASE_URL="postgres://USER:PASSWORD@pooled.db.prisma.io:5432/postgres?sslmode=require"

DIRECT_URL="postgres://USER:PASSWORD@db.prisma.io:5432/postgres?sslmode=require"

If your prisma.config.ts sets db.connection, point it at DIRECT_URL.

Confirm that the imported database still matches your contract:

bunx prisma db verify --db "$DIRECT_URL"

pnpm prisma db verify --db "$DIRECT_URL"

yarn prisma db verify --db "$DIRECT_URL"

npx prisma db verify --db "$DIRECT_URL"

The command exits with code 0 when the marker and schema match the contract. Exit code 4 means the database does not match. Check that the restore included the prisma_contract schema before you change anything else. Do not run orm init or contract infer against the new database; your existing contract already describes it.

Set the pooled URL for runtime queries and the direct URL for Prisma CLI commands:

DATABASE_URL="postgres://USER:PASSWORD@pooled.db.prisma.io:5432/postgres?sslmode=require"

DIRECT_URL="postgres://USER:PASSWORD@db.prisma.io:5432/postgres?sslmode=require"

Prisma ORM 7 reads the CLI connection from datasource.url in prisma.config.ts. Point it at DIRECT_URL as shown in the Prisma ORM 7 PostgreSQL setup. Prisma ORM 6 and earlier read url and directUrl from the datasource block in schema.prisma.

If your application did not use Prisma Accelerate, run npx prisma generate and continue to step 8.

If your application connected through Accelerate, remove it now. Prisma Postgres connection pooling replaces the Accelerate connection pool. It does not replace Accelerate query caching, so remove the cache calls as well.

Uninstall the extension:

bun remove @prisma/extension-accelerate

pnpm remove @prisma/extension-accelerate

yarn remove @prisma/extension-accelerate

npm uninstall @prisma/extension-accelerate

In your Prisma Client setup, remove the @prisma/extension-accelerate import, withAccelerate(), and accelerateUrl. Remove cacheStrategy options from queries, and remove calls to withAccelerateInfo, $accelerate.invalidate, and $accelerate.invalidateAll.

Undo any build settings you added for Accelerate: imports from @prisma/client/edge, engineType = "client" in the generator block, and the --no-engine, --accelerate, or --data-proxy flags on prisma generate. For Prisma ORM 7, connect through the PostgreSQL driver adapter. For Prisma ORM 6 or earlier, use Prisma Client with its bundled query engine or a driver adapter your version supports.

Accelerate reached edge runtimes over HTTP. For an edge or TCP-constrained runtime, use the Prisma Postgres serverless driver. For a conventional Node.js or Bun runtime, use the Prisma Postgres pooled TCP connection.

Regenerate Prisma Client:

bunx prisma generate

pnpm prisma generate

yarn prisma generate

npx prisma generate

Search your project for @prisma/extension-accelerate and prisma://. Neither should appear.

Keep your existing PostgreSQL client library. Point its runtime connection at the pooled URL, and use the direct URL for migrations, pg_dump, pg_restore, and other administrative tools:

DATABASE_URL="postgres://USER:PASSWORD@pooled.db.prisma.io:5432/postgres?sslmode=require"

DIRECT_URL="postgres://USER:PASSWORD@db.prisma.io:5432/postgres?sslmode=require"

Start the application with the new environment variables while production traffic remains paused, then run its existing test suite. At minimum, verify one read and one rolled-back or disposable write through the pooled connection.

Test every feature that previously depended on Supabase Auth, Storage, Realtime, or role-based RLS against its replacement. Only after the database comparison and application checks succeed, route production traffic to Prisma Postgres and resume writes there. Do not re-enable writes on Supabase. Keep the Supabase project available in a read-only state until the application is healthy on Prisma Postgres and the rollback window has ended.

After you have verified the application and retained any audit evidence you need, delete the local dump and row-count files:

rm supabase-to-prisma-postgres.dump supabase-restore.list row-counts.sql source-row-counts.txt target-row-counts.txt

Your database migration is complete. Prisma ORM 8 is the current release, but upgrading is a separate application change. Follow the incremental Prisma ORM 7 to 8 guide after the application is stable on Prisma Postgres.

If you want to complete both changes on the same day, deploy and verify the Prisma Postgres connection first. Upgrade Prisma ORM in a separate commit or deployment so failures have one clear cause.

• Migrate from Neon to Prisma Postgres
• Migrate another PostgreSQL database to Prisma Postgres