Neon

Kurz: Ein “Serverless Postgres”-Anbieter — eine waschechte PostgreSQL-Datenbank, aber ohne eigenen Server zu verwalten, mit Connection String statt manueller Installation.

Genauer: Man bekommt im Dashboard einen Connection String (“Connection Details”), der jederzeit im Klartext einsehbar ist (anders als z. B. ein einmalig sichtbarer API-Key). Läuft technisch stinknormales SQL, kompatibel mit Standard-Tools wie pg_dump/psql.

Kontext bei uns: Die Datenbank hinter Emzett — neue eigene Neon-Datenbank angelegt, vier Tabellen (challenges, custom_roles, rewards, site_settings) per pg_dump/psql aus der alten Bellator-DB übernommen.

Im Detail

Storage/Compute-Trennung

Neon trennt Storage und Compute technisch voneinander: Die eigentlichen Daten liegen auf einem verteilten Storage-Layer (intern ein eigens entwickeltes, auf Log-structured Storage basierendes System, nicht das klassische Postgres-eigene Dateisystem-Layout), während die “Compute”-Instanz — der eigentliche PostgreSQL-Prozess, der Anfragen beantwortet — bei Bedarf gestartet und wieder heruntergefahren werden kann, ohne dass Daten verloren gehen. Genau das macht Neon Auto-Suspend möglich, und ist der Kernunterschied zu klassischem “Miete einen ganzen Server, der rund um die Uhr läuft”-Hosting (z. B. eine klassische RDS-Instanz bei AWS oder ein selbst verwalteter Postgres-Server). Diese Architektur ist Teil eines breiteren Trends im Datenbank-Hosting der letzten Jahre — “Serverless Postgres” — zu dem neben Neon auch Anbieter wie Supabase (das zusätzlich Auth, Storage und Realtime-Features um Postgres herum bündelt) oder AWS Aurora Serverless zählen, allerdings mit unterschiedlich tiefer Trennung von Storage und Compute.

Branching

Ein Feature, das bei einer klassischen Postgres-Installation so nicht existiert: Branching. Man kann von der Produktionsdatenbank jederzeit eine vollständige Kopie (“Branch”) erstellen, die anfangs praktisch keinen zusätzlichen Speicherplatz kostet (Copy-on-Write — erst wenn sich Daten im Branch tatsächlich ändern, werden neue Blöcke geschrieben). Das ist nützlich, um z. B. eine riskante Migration erst an einer Kopie zu testen, bevor man sie gegen die echte Produktionsdatenbank fährt, oder um für jede Pull-Request-Preview-Deployment automatisch eine eigene, isolierte Datenbank-Kopie zu erzeugen (ein verbreitetes CI/CD-Muster: Branch pro PR, automatisch gelöscht sobald der PR gemerged/geschlossen wird). Branches lassen sich sowohl über das Dashboard als auch über die Neon-CLI/API erzeugen, was sich gut in automatisierte Deploy-Pipelines integrieren lässt.

Connection String und Pooling

Der Connection String hat typischerweise die Form:

postgresql://<user>:<password>@<endpoint>.neon.tech/<database>?sslmode=require

sslmode=require ist bei Neon Pflicht — unverschlüsselte Verbindungen werden serverseitig abgelehnt, was bei einer versehentlich lokal getesteten Verbindung ohne dieses Flag zu einer kryptischen Fehlermeldung führen kann. Für Verbindungen aus Serverless-Umgebungen (z. B. Vercel Functions, die pro Request potenziell neue Verbindungen aufbauen) bietet Neon zusätzlich einen “Pooled Connection”-String über PgBouncer (ein separater Connection-Pooler, der zwischen App und der eigentlichen Postgres-Instanz sitzt) im “Transaction Pooling”-Modus. Das ist wichtig, weil Postgres selbst nur eine begrenzte Anzahl gleichzeitiger Verbindungen erlaubt (typischerweise niedrige Hundert bei kleineren Compute-Größen) — bei vielen kurzlebigen Serverless-Function-Aufrufen, die jeweils eine eigene Verbindung öffnen, würde man dieses Limit sonst schnell erschöpfen (“Connection Exhaustion”). Der Nachteil des Pooled-Connection-Strings: Manche Postgres-Features, die eine langlebige Sitzung voraussetzen (z. B. LISTEN/NOTIFY, vorbereitete Anweisungen über Sitzungsgrenzen hinweg, oder Advisory Locks), funktionieren im Transaction-Pooling-Modus nicht zuverlässig — dafür braucht man dann die direkte, ungepoolte Verbindung.

Abgrenzung zu Alternativen

Im Vergleich zu Supabase (das viel breiter aufgestellt ist, inklusive eigenem Auth-System und Storage-Buckets) ist Neon bewusst schlank gehalten — reine Postgres-Datenbank mit Serverless-Eigenschaften, ohne zusätzliche Plattform-Features. Im Vergleich zu PlanetScale (das auf MySQL-kompatiblem Vitess basiert, nicht auf echtem Postgres) bleibt man bei Neon vollständig kompatibel mit dem Postgres-Ökosystem — jedes Tool, das mit “echtem” Postgres spricht (inklusive pg_dump/psql, siehe pg_dump und psql), funktioniert unverändert.

Siehe auch: pg_dump und psql, Drizzle ORM