PostgreSQL ist die erste Wahl für relationale Datenbanken in modernen Webanwendungen – leistungsstark, standards-konform und mit einem riesigen Ökosystem. Das Problem: Traditionelle PostgreSQL-Instanzen laufen rund um die Uhr, auch wenn keine Anfragen eingehen. Für Entwicklungsumgebungen, Staging-Systeme oder Anwendungen mit unregelmäßigem Traffic ist das kostspielig und ineffizient. Neon löst dieses Problem mit einer vollständig serverlosen Architektur, die PostgreSQL auf eine neue Basis stellt.
Was ist Neon?
Neon ist ein verwalteter PostgreSQL-Dienst, der Compute und Storage konsequent voneinander trennt. Die Datenspeicherung erfolgt auf einem verteilten, objektbasierenden Storage-Layer (ähnlich wie AWS S3). Der Compute – also die eigentliche PostgreSQL-Instanz – kann unabhängig davon hoch- und heruntergefahren werden.
Das Ergebnis ist ein PostgreSQL, das sich wie eine serverlose Funktion verhält: Es startet bei der ersten Anfrage, verarbeitet sie, und fährt nach einem konfigurierbaren Leerlauf-Zeitraum (standardmäßig 5 Minuten) automatisch herunter. Kosten entstehen nur für tatsächlich genutzte Compute-Zeit.
Neon ist vollständig PostgreSQL-kompatibel – dieselben Treiber, dieselben Extensions (pg_vector, PostGIS, pgcrypto usw.), dieselbe SQL-Syntax. Ein Wechsel von einer klassischen PostgreSQL-Instanz zu Neon erfordert nur die Anpassung der Connection-String.
Scale-to-Zero: Wie es funktioniert
Das Scale-to-Zero-Verhalten von Neon ist möglich, weil der Zustand vollständig im Storage-Layer liegt. Wenn der Compute-Prozess heruntergefahren wird, gehen keine Daten verloren – sie liegen sicher im verteilten Speicher. Kommt eine neue Anfrage, wird ein neuer Compute-Prozess gestartet und mit dem Storage verbunden. Dieser Kaltstart dauert bei Neon typischerweise unter 500 Millisekunden, was für die meisten Anwendungsfälle akzeptabel ist.
Für latenzempfindliche Produktionsanwendungen bietet Neon auch einen Always-On-Modus, der den Compute dauerhaft aktiv hält. Das hebelt den kostensparenden Aspekt teilweise aus, ermöglicht aber konsistente Antwortzeiten.
Datenbank-Branching: Git für Datenbanken
Das herausragendste Feature von Neon ist das Branching-System. Analog zu Git-Branches können Entwickler einen Branch der Datenbank erstellen – eine vollständige, unabhängige Kopie des aktuellen Datenbankzustands, die sofort verfügbar ist.
Dank Copy-on-Write-Mechanismus verbraucht ein neuer Branch initial keinen zusätzlichen Speicherplatz. Erst wenn Daten im Branch verändert werden, entstehen neue Speicherblöcke. Das macht Branches extrem günstig zu erstellen – auch für Datenbanken im Gigabyte-Bereich dauert die Branch-Erstellung weniger als eine Sekunde.
Typische Einsatzszenarien für Neon-Branches:
- Feature-Entwicklung: Jeder Feature-Branch im Code erhält einen eigenen Datenbank-Branch – isoliert, reproduzierbar, ohne Risiko für die Produktionsdaten.
- Preview-Deployments: Vercel erstellt für jeden Pull-Request automatisch einen Neon-Branch, der die Produktionsdaten spiegelt.
- Testing: Integrationstests laufen gegen einen frischen Branch und können ihn nach dem Test einfach löschen oder zurücksetzen.
Connection Pooling mit PgBouncer
Ein bekanntes Problem bei PostgreSQL in serverlosen Umgebungen ist die Verbindungserschöpfung. Jede Serverless-Funktion öffnet eine neue Datenbankverbindung – bei hunderten gleichzeitiger Aufrufe entstehen schnell Engpässe. PostgreSQL kann nur eine begrenzte Anzahl aktiver Verbindungen halten.
Neon löst das durch einen integrierten Connection Pooler auf Basis von PgBouncer. Für jeden Neon-Branch gibt es zwei Connection-Strings: einen direkten für Migrationen und Tools, und einen gepoolten für Anwendungsverbindungen. Der gepoolte Endpunkt multiplext tausende von Clients über eine überschaubare Anzahl echter PostgreSQL-Verbindungen.
Bei Next.js-Projekten verwendet man den @neondatabase/serverless-Treiber, der HTTP-basierte Verbindungen ermöglicht – ideal für Edge-Umgebungen, in denen TCP-Sockets eingeschränkt sind.
Free-Tier und Kostenmodell
Der kostenlose Plan von Neon umfasst 0,5 GB Speicher, 191,9 Compute-Stunden pro Monat und unbegrenzte Branches. Damit lassen sich kleine Projekte und Entwicklungsumgebungen vollständig kostenfrei betreiben.
Beim bezahlten Launch-Plan (ab 19 $/Monat) steigen die Limits deutlich: 10 GB Speicher, mehr Compute-Stunden und erweiterte Branch-Funktionen. Pro-Plan-Nutzer können außerdem mehrere Projekte anlegen und profitieren von höheren Skalierungsgrenzen.
Integration mit Vercel und Next.js
Die Kombination aus Neon und Vercel gehört zu den am weitesten verbreiteten Datenbanksetups im Next.js-Ökosystem. Die offizielle Integration installiert die notwendigen Umgebungsvariablen automatisch und aktiviert das Branch-Preview-Feature. Mit dem @neondatabase/serverless-Paket und dem vercelspezifischen @vercel/postgres-Adapter (der intern ebenfalls Neon nutzt) lassen sich Datenbankabfragen direkt in Server-Komponenten und Route-Handlern ausführen.
Vergleich: Neon vs. Supabase vs. PlanetScale vs. CockroachDB
| Kriterium | Neon | Supabase | PlanetScale | CockroachDB Serverless |
|---|---|---|---|---|
| Datenbank-Engine | PostgreSQL | PostgreSQL | MySQL (Vitess) | CockroachDB (Postgres-kompatibel) |
| Serverless / Scale-to-Zero | Ja | Eingeschränkt (Pause) | Ja (eingestellt*) | Ja |
| DB-Branching | Ja (Copy-on-Write) | Nein | Ja | Nein |
| Free-Tier Speicher | 0,5 GB | 500 MB | — | 10 GB |
| Connection Pooling | Integriert (PgBouncer) | Integriert (PgBouncer) | Integriert | Integriert |
| Postgres-Kompatibilität | Vollständig | Vollständig | Nein (MySQL) | Weitgehend |
| Vercel-Integration | Offiziell, tief | Ja | Ja | Ja |
* PlanetScale hat seinen serverlosen Free-Tier 2024 eingestellt
Fazit
Neon hat das Konzept des serverless PostgreSQL konsequent und durchdacht umgesetzt. Das Branching-Feature ist ein echter Gamechanger für Teams, die Datenbankisolation in ihrer CI/CD-Pipeline wünschen, ohne komplexe Infrastruktur aufzubauen. Die enge Vercel-Integration macht Neon zur natürlichsten Wahl für Next.js-Projekte. Wer vollständige PostgreSQL-Kompatibilität mit modernen serverlosem Betrieb kombinieren möchte, findet in Neon einen überzeugenden Dienst.
Häufige Fragen zu Neon
- Kann ich PostgreSQL-Extensions bei Neon verwenden?
- Ja, Neon unterstützt eine breite Auswahl an Extensions, darunter pg_vector (Vektorsuche für KI-Anwendungen), PostGIS (Geodaten), pgcrypto und viele weitere. Eine vollständige Liste findet sich in der Neon-Dokumentation.
- Wie lange dauert ein Kaltstart bei Neon?
- Neon gibt für Kaltstarts typischerweise unter 500 Millisekunden an. In der Praxis liegen die Zeiten oft bei 200–400 ms. Für Anwendungen, die auch nach Ruhephasen sofort reagieren müssen, empfiehlt sich der Always-On-Modus oder regelmäßige Warm-up-Pings.
- Ist Neon für Produktionsanwendungen geeignet?
- Ja. Neon wird von zahlreichen Unternehmen in der Produktion eingesetzt. Für hochkritische Anwendungen mit strengen SLAs empfiehlt sich der Business-Plan mit garantierter Verfügbarkeit und Support. Das Scale-to-Zero-Feature kann für Produktionsinstanzen deaktiviert werden.
- Kann ich meine bestehende PostgreSQL-Datenbank zu Neon migrieren?
- Ja, eine Migration ist mit Standard-PostgreSQL-Tools wie
pg_dumpundpg_restoremöglich. Neon empfiehlt für größere Datenbanken den Import über den Neon-eigenen Import-Assistenten, der direkt im Dashboard verfügbar ist und den Prozess automatisiert.