Migrate Heroku Postgres to Supabase: separate database and app

Move Heroku Postgres through a tested process rather than an improvised export. WZ-IT provides a Supabase migration from €3,490 after reviewing the database, application and Heroku dependencies.

A Heroku Postgres to Supabase migration can be a clearly bounded database move or part of a complete Heroku exit. These are different projects: Supabase provides PostgreSQL and optional backend services, but it does not replace Heroku dynos or every add-on automatically.

Define the actual Heroku scope first

Heroku applications often combine:

• web and worker dynos
• Heroku Postgres and possibly followers
• Redis or queue add-ons
• Heroku Scheduler
• one database attached to multiple apps
• config vars and application secrets
• logging, monitoring and email add-ons
• domains, TLS and pipelines

The first decision is whether only the database moves or the entire application leaves. An app can remain on Heroku and use Supabase as an external PostgreSQL service. A complete PaaS exit also needs a new deployment and operating model.

Assess Heroku Postgres

Capture before the test export:

Larger databases require enough target compute, storage and IOPS before import. Supabase recommends provisioning suitable target capacity for larger Heroku data sets.

Rehearse export and import

The official Supabase guide uses pg_dump and psql. Excluding ownership and privileges matters because Heroku and Supabase use different managed roles.

A rehearsal answers:

• Can every extension be enabled on the target?
• Which roles or owners need remapping?
• Do views, triggers and database functions work?
• Do table, row and sequence states match?
• How long do export, transfer, restore and validation take?
• Which application tests fail after the switch?

The maintenance window is based on this evidence.

Connection string and application

Heroku commonly exposes database access through DATABASE_URL. Host, credentials, TLS and possibly pooling mode change after migration.

Test:

• session or transaction pooling
• prepared statements and ORM behaviour
• maximum connections across dynos and workers
• network distance between the Heroku and Supabase regions
• SSL mode and certificate verification
• jobs using separate database roles

Apply the new URL to a staging app or Heroku pipeline first. Replacing the production variable without a rehearsal is not a controlled cutover.

Dynos, workers and add-ons

Supabase provides a database, Auth, Storage, Realtime, APIs and Edge Functions. That does not create automatic one-to-one mappings:

These components stay unchanged in a database-only move. A complete Heroku exit plans each as a separate workstream.

Cut over with a rollback checkpoint

A dump-and-restore cutover normally follows this sequence:

1. Enable maintenance mode or a write freeze.
2. Stop workers and scheduled jobs.
3. Create the final export.
4. Import data into Supabase.
5. Verify sequences, counts and critical records.
6. Change DATABASE_URL and related secrets.
7. Deploy the app and workers and run smoke tests.

Keep Heroku Postgres unchanged during the rollback window. Do not resume writes until the treatment of any rollback is clear.

Introduce Supabase capabilities deliberately

The database move can later expand to Supabase Auth, Storage, Realtime or the Data API. Those changes are not hidden inside a simple PostgreSQL import. Each service needs its own data model, permissions, SDK and user-flow tests.

The general PostgreSQL-to-Supabase guide covers dump, replication, RLS and pooling in more detail. Use the Supabase migration checklist for the complete process.

WZ-IT can operate the target as managed Supabase after migration.

Sources

• Supabase: migrate from Heroku to Supabase
• Heroku: Heroku Postgres
• Supabase: migrate from Postgres to Supabase