Moving a production database should not depend on an untested import. WZ-IT delivers a Supabase migration from €3,490 with technical assessment, rehearsal and planned cutover.
An existing PostgreSQL-to-Supabase migration is a homogeneous database move at its core. Both sides run PostgreSQL. It is still more than replacing a DATABASE_URL: roles, extensions, ownership, pooling, RLS and the target platform's operating boundaries can change application behaviour.
The other central decision is whether only the database moves or whether the application will adopt Supabase Auth, Storage, Realtime, Edge Functions and generated APIs.
What a PostgreSQL migration can transfer
pg_dump and pg_restore can normally move:
- schemas, tables and data
- indexes, constraints and sequences
- views and materialised views
- database functions and triggers
- supported extensions
- RLS policies as database objects
Ownership, superuser privileges, provider-internal roles, replication objects and platform-specific extensions should not be imported blindly. The official Supabase PostgreSQL migration guide therefore recommends exports without ownership and privileges, followed by explicit target role configuration.
Assess the source first
Before migration, capture at least:
| Area | Required review |
|---|---|
| Version | Source and target versions, upgrade or downgrade risks |
| Extensions | Availability and version on Supabase |
| Roles | Login roles, ownership, grants and superuser dependencies |
| Data | Size, large tables, large objects and write rate |
| Schema | Functions, triggers, partitioning, views and sequences |
| Application | Drivers, connection pool, transactions and SQL assumptions |
| Operations | Maintenance window, RPO, RTO, rehearsal and rollback path |
Functions that rely on filesystem access, custom background workers or superuser rights deserve particular attention. They need replacement or need to move outside the database before cutover.
PostgreSQL sources covered by this path
The same technical base path applies to managed PostgreSQL services. Provider-specific concerns belong in the assessment or a dedicated guide:
- self-managed PostgreSQL and on-premises databases
- Render Postgres, Railway Postgres and Fly Postgres
- Google Cloud SQL and Azure Database for PostgreSQL
- DigitalOcean Managed PostgreSQL, Aiven and similar services
- AWS RDS and Aurora PostgreSQL
- Heroku Postgres
- Neon and former Vercel Postgres
A separate provider page is worthwhile only when networking, roles, branching, add-ons or cutover produce genuinely distinct content. Replacing a brand name alone would not help readers or search engines.
Dump and restore or logical replication?
Maintenance window with dump and restore
For manageable databases, a controlled export and import is often the clearest path:
- Prepare the target project and extensions.
- Create a test dump and restore it into Supabase.
- Resolve errors, roles and incompatible objects.
- Record transfer duration and validation queries.
- Stop writes for cutover, export the final state and switch.
This method is easy to verify but needs a write pause appropriate to the data volume.
Logical replication for a short cutover
Supabase also documents logical replication for PostgreSQL 10 and later. It is useful when the source must keep accepting writes while the initial data is copied. Prerequisites include replication privileges, wal_level=logical, replication slots and a replica identity for changing tables.
DDL changes, sequences and large objects are not replicated automatically. A schema freeze, sequence reconciliation and final write stop therefore remain part of the plan.
Roles, RLS and APIs after import
An existing PostgreSQL application often uses custom login roles or one central database user. Supabase adds anon, authenticated and service_role, plus PostgREST and Auth.
After import, decide:
- Will the application retain a direct PostgreSQL connection?
- Will tables be exposed through the Supabase Data API?
- Which tables require RLS?
- Which access paths will use user JWTs?
- Which server processes may use
service_role?
RLS must work in real user journeys, not merely exist as SQL. Test allowed and denied access explicitly. See the dedicated guide to auditing Supabase RLS.
Change connections and pooling
Supabase provides direct connections plus Supavisor session and transaction pooling. The modes are not interchangeable for every framework:
- migration tools and long-running sessions need session mode or a direct connection
- serverless applications often benefit from transaction pooling
- prepared statements and session-dependent behaviour need testing
- firewall access, IPv4/IPv6 reachability and TLS belong in acceptance
Point a staging deployment at Supabase first. Production secrets and DATABASE_URL change only after it passes.
Database-only move or complete Supabase backend?
A PostgreSQL migration can intentionally remain database-only. Adopting more Supabase services creates separate workstreams:
- move existing identity management to Supabase Auth
- transfer files into Supabase Storage
- implement access rules as RLS
- connect REST, GraphQL or Realtime clients
- move jobs or backend code to Edge Functions or external workers
These changes should not be hidden inside a database import. They alter the application and need their own acceptance criteria.
Acceptance and rollback
Acceptance should compare more than total row count. Verify:
- row counts and samples of critical records
- constraints, indexes, sequences and defaults
- functions, triggers and scheduled work
- performance of critical queries
- write and transaction behaviour
- roles, grants and negative RLS tests
- application, API and background processes
Use the Supabase migration checklist for the final sequence. After cutover, WZ-IT can operate the target as managed Supabase.
