Neon und Vercel Postgres zu Supabase migrieren

Soll Neon oder eine frühere Vercel-Postgres-Datenbank zu Supabase wechseln? WZ-IT übernimmt die Supabase-Migration ab 3.490 € nach Prüfung von Branches, Anwendung und Cutover-Anforderungen.

Eine Migration von Neon zu Supabase ist technisch ein PostgreSQL-Umzug, besitzt aber eigene Besonderheiten: serverless Compute, Branches, gepoolte Endpunkte und spezielle Treiber beeinflussen Entwicklung und Laufzeit. Der weiterhin gesuchte Begriff Vercel Postgres zu Supabase bezeichnet inzwischen meist denselben Quelltyp.

Vercel weist in seiner aktuellen Dokumentation darauf hin, dass Vercel Postgres nicht mehr als eigenständiges Produkt existiert und bestehende Datenbanken im Dezember 2024 zu Neon übertragen wurden. Eine getrennte, nahezu identische Vercel-Seite würde deshalb unnötig konkurrieren. Beide Intents werden auf dieser Seite zusammengeführt.

Neon-Projekt und Vercel-Integration aufnehmen

Vor dem Umzug erfassen wir:

• Neon-Organisation, Projekt und Region
• Produktions- und Entwicklungsbranches
• Compute-Endpunkte je Branch
• direkte und gepoolte Connection Strings
• Autosuspend- und Skalierungsverhalten
• PostgreSQL-Version und Extensions
• Rollen, Schemas und Datenbankgröße
• Vercel-Projekte und Environment Variables
• Nutzung des Neon Serverless Drivers oder eines ORM
• Preview Deployments und deren Branch-Zuordnung

Der produktive Branch ist nicht immer die einzige relevante Datenquelle. Preview- oder Staging-Branches können Schemaänderungen enthalten, die vor dem Cutover in die reguläre Migrationshistorie überführt werden müssen.

Was übertragbar ist

Die Datenbank ist portabel; das serverless Betriebsmodell und die Branch-Verknüpfung sind es nicht automatisch.

Dump, Restore und Replikation

Supabase bietet eine offizielle Neon-Migrationsanleitung. Für überschaubare Datenbanken eignet sich ein Testdump mit anschließendem finalen Export im Wartungsfenster.

Bei hoher Schreiblast kann die allgemeine PostgreSQL-Strategie mit logischer Replikation geprüft werden. Ob sie möglich ist, hängt von Replikationsrechten, Quellkonfiguration, Primärschlüsseln und den verwendeten Objekten ab.

Der Testlauf verifiziert:

• Tabellen, Zeilenzahlen und Sequenzen
• Extensions, Views, Trigger und Funktionen
• Eigentümer, Rollen und Grants
• kritische Queries und Transaktionen
• Importdauer und erforderliche Zielkapazität

Branching sauber neu ordnen

Neon-Branches können für Preview Deployments, Tests oder kurzlebige Entwicklungsstände verwendet werden. Supabase-Projekte und Supabase Branching folgen einem anderen Modell und sind nicht als unveränderte Kopie zu betrachten.

Vor der Migration wird entschieden:

• Welche Branches enthalten relevante Daten?
• Welche sind reine Schema- oder Preview-Umgebungen?
• Werden Staging und Produktion als getrennte Supabase-Projekte aufgebaut?
• Wie wird das Schema künftig über versionierte Migrationen ausgerollt?
• Welche Preview Deployments benötigen eigene Datenbanken?

Das verhindert, dass veraltete Branches ungeprüft als produktionsrelevante Datenbestände behandelt werden.

Vercel-App auf Supabase umstellen

Die Anwendung kann weiterhin auf Vercel laufen. Geändert werden je nach Stack:

• DATABASE_URL und getrennte Direktverbindung
• Supabase URL und Publishable Key
• Server-Secrets und service_role
• Neon Serverless Driver oder PostgreSQL-Treiber
• Pooling-Modus und Prepared Statements
• Variablen für Development, Preview und Production

Preview und Staging werden zuerst umgestellt. Dabei werden Kaltstarts, Verbindungsgrenzen, Transaktionen und Latenz geprüft. Die Produktion folgt erst nach erfolgreicher Abnahme.

Preview-Umgebungen nach der Migration

Der Wechsel ist eine Gelegenheit, die Kopplung zwischen Deployment und Datenbank zu bereinigen. Eine produktive Datenbank darf nicht versehentlich von beliebigen Preview-Deployments beschrieben werden. Für jede Vercel-Umgebung wird daher festgelegt, ob sie eine dauerhafte Supabase-Instanz, eine isolierte Branch-Umgebung, anonymisierte Testdaten oder überhaupt keinen Datenbankzugriff erhält.

Auch der Lebenszyklus braucht Regeln: Wer erstellt die Umgebung, wie werden Migrationen angewendet, wann wird sie entfernt und welche Secrets darf sie lesen? Die Zielarchitektur wird mit einem Preview-Deployment getestet, bevor Produktionsvariablen geändert werden. So bleibt die Migration reproduzierbar und erzeugt keine unkontrollierten Nebenpfade auf den neuen Datenbestand.

Wenn Supabase-Funktionen hinzukommen

Der Wechsel kann auf PostgreSQL begrenzt bleiben. Werden Auth, Storage, Realtime, RLS oder Edge Functions eingeführt, entsteht zusätzlicher Anwendungsscope. Diese Funktionen werden nicht durch den Datenbankimport aktiviert und benötigen eigene Sicherheits- und Funktionstests.

Die PostgreSQL-zu-Supabase-Anleitung beschreibt das generische Datenbankverfahren. Für den Gesamtprozess dient die Supabase-Migrationscheckliste.

Nach dem Cutover kann WZ-IT die Zielumgebung als Managed Supabase betreiben.

Quellen

• Supabase: Migrate from Neon to Supabase
• Vercel: Vercel Postgres
• Neon: Branching