Move Neon or a former Vercel Postgres database through a controlled cutover. WZ-IT provides a Supabase migration from €3,490 after reviewing branches, application and operational requirements.
A Neon-to-Supabase migration is a PostgreSQL move with platform-specific concerns: serverless compute, branches, pooled endpoints and specialised drivers affect development and runtime. The still-common search term Vercel Postgres to Supabase now normally refers to the same source.
Vercel's current documentation states that Vercel Postgres is no longer a separate product and that existing databases moved to Neon in December 2024. A separate, near-identical Vercel page would create unnecessary competition, so this guide serves both intents.
Inventory Neon and the Vercel integration
Capture before migration:
- Neon organisation, project and region
- production and development branches
- compute endpoints per branch
- direct and pooled connection strings
- autosuspend and scaling behaviour
- PostgreSQL version and extensions
- roles, schemas and database size
- Vercel projects and environment variables
- Neon Serverless Driver or ORM use
- preview deployments and branch mapping
The production branch may not be the only relevant source. Preview or staging branches can contain schema work that needs to enter the normal migration history before cutover.
What transfers
| Element | Treatment |
|---|---|
| Schema and data | PostgreSQL dump or another suitable transfer method |
| Functions and triggers | Transfer after compatibility review |
| Extensions | Compare against Supabase and enable on the target |
| Roles and grants | Reorganise for Supabase |
| Neon branches | Not portable one-to-one; define a target model |
| Compute endpoints | Replace with Supabase connections and pooling |
| Vercel variables | Change URLs and keys per environment |
| Monitoring and backups | Configure and accept on the target |
The database is portable; the serverless operating model and branch integration are not automatic.
Dump, restore and replication
Supabase publishes an official Neon migration guide. A rehearsal dump followed by a final maintenance-window export works well for manageable databases.
For high write rates, assess the general PostgreSQL logical-replication strategy. Feasibility depends on replication rights, source configuration, primary keys and object types.
The rehearsal validates:
- tables, row counts and sequences
- extensions, views, triggers and functions
- ownership, roles and grants
- critical queries and transactions
- import duration and required target capacity
Redesign branching deliberately
Neon branches may support preview deployments, tests or short-lived development states. Supabase projects and Supabase Branching use a different model and should not be treated as unchanged copies.
Decide:
- Which branches contain relevant data?
- Which are schema-only or preview environments?
- Will staging and production become separate Supabase projects?
- How will versioned migrations deploy schema changes?
- Which preview deployments need their own databases?
This prevents stale branches from being handled as production data by default.
Point the Vercel application at Supabase
The application can remain on Vercel. Depending on the stack, change:
DATABASE_URLand a separate direct connection- Supabase URL and publishable key
- server secrets and
service_role - Neon Serverless Driver or PostgreSQL driver
- pooling mode and prepared statements
- variables for development, preview and production
Switch preview and staging first. Test cold starts, connection limits, transactions and latency before production follows.
Preview environments after migration
The move is an opportunity to remove unsafe coupling between deployments and databases. Arbitrary preview deployments must not be able to write to the production database by accident. For each Vercel environment, decide whether it receives a persistent Supabase project, an isolated branch environment, anonymised test data or no database access at all.
Define the lifecycle too: who creates the environment, how migrations are applied, when it is removed and which secrets it may read. Validate the target design with a preview deployment before changing production variables. This keeps the migration reproducible and avoids uncontrolled secondary paths into the new data set.
Adding Supabase capabilities
The move can remain database-only. Adding Auth, Storage, Realtime, RLS or Edge Functions expands the application scope. Database import does not activate these functions, and each requires security and functional testing.
The PostgreSQL-to-Supabase guide covers the generic database process. Use the Supabase migration checklist for the complete sequence.
WZ-IT can operate the target as managed Supabase after cutover.
