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:
| Area | Review |
|---|---|
| Plan and size | Data volume, connections, write load and maintenance window |
| PostgreSQL | Version, extensions, schemas, functions and triggers |
| Roles | Ownership, grants and Heroku-specific roles |
| Availability | Followers, HA requirements and rollback path |
| Application | Framework, ORM, pooling and direct database access |
| Add-ons | Redis, Scheduler, logging, ETL and external integrations |
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:
| Heroku component | Possible treatment |
|---|---|
| Web dyno | Keep on Heroku or deploy separately |
| Worker dyno | External worker, container platform or a targeted Function |
| Heroku Scheduler | Cron, workflow system or scheduled database job |
| Redis | Retain or migrate to a compatible service |
| Heroku Postgres | Transfer to Supabase PostgreSQL |
| Auth add-on | Assess independently and optionally migrate to Supabase Auth |
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:
- Enable maintenance mode or a write freeze.
- Stop workers and scheduled jobs.
- Create the final export.
- Import data into Supabase.
- Verify sequences, counts and critical records.
- Change
DATABASE_URLand related secrets. - 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.
