NeonDB

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

Genauer: Neon trennt Storage und Compute: die Rechenleistung kann bei Inaktivität komplett herunterfahren (“Auto-Suspend”) und bei Bedarf innerhalb von Sekunden wieder hochfahren, wodurch man nur für tatsächliche Nutzung zahlt statt für einen dauerhaft laufenden Server.

Im Detail

Die Trennung von Storage (Datenspeicherung) und Compute (Rechenleistung für Abfragen) ist die zentrale architektonische Innovation hinter “Serverless Postgres”: statt einer klassischen Datenbank-Installation, bei der Speicher und Rechenleistung fest an eine laufende Serverinstanz gekoppelt sind, liegen die Daten bei NeonDB in einem separaten, dauerhaften Speicherlayer, während die eigentliche Rechenleistung (der “Compute”-Knoten, der Abfragen tatsächlich ausführt) bei Bedarf gestartet und bei Inaktivität wieder abgeschaltet wird.

Das bringt zwei praktische Vorteile für kleinere/mittlere Projekte: Kosten skalieren mit tatsächlicher Nutzung statt mit einer dauerhaft gebuchten Serverkapazität, und “Branching” wird einfach — ein separater, isolierter Datenbank-Zweig für z. B. eine Testumgebung lässt sich in Sekunden aus dem aktuellen Datenstand erzeugen, ähnlich wie ein Git-Branch, statt eine komplette Kopie der Datenbank manuell anzulegen. Als PostgreSQL-Wrapper bleibt die volle SQL-Kompatibilität erhalten — Anwendungen verbinden sich über einen Standard-Connection-String wie bei jeder anderen PostgreSQL-Instanz.

Cold Starts und Auto-Suspend im Detail

Die Auto-Suspend-Funktion hat einen praktischen Nebeneffekt, den Entwickler kennen sollten: Nach einer konfigurierbaren Zeit ohne Aktivität (oft wenige Minuten) fährt der Compute-Knoten komplett herunter — der nächste Datenbankzugriff löst dann einen “Cold Start” aus, bei dem der Knoten erst wieder hochfahren muss, bevor die Abfrage beantwortet wird. Das kann sich als spürbare Verzögerung (oft im Bereich mehrerer hundert Millisekunden bis wenige Sekunden) beim ersten Request nach einer Ruhephase bemerkbar machen — für Anwendungen mit sehr strikten Latenzanforderungen bei jedem einzelnen Request kann das relevant sein, für die meisten Webanwendungen mit unregelmäßigem Traffic ist der Kostenvorteil aber meist wichtiger als diese gelegentliche Verzögerung.

Branching als Entwicklungswerkzeug

Das Datenbank-Branching-Feature verändert typische Entwicklungsworkflows: Statt eine Staging- oder Test-Datenbank manuell zu pflegen und regelmäßig mit Produktionsdaten zu synchronisieren, lässt sich für jeden Feature-Branch oder Pull Request automatisiert ein eigener, isolierter Datenbank-Branch erzeugen — mit demselben Datenstand wie zum Zeitpunkt der Erstellung, aber komplett unabhängig von Änderungen in der Produktionsdatenbank. Änderungen (z. B. eine neue Migration) lassen sich so gefahrlos gegen echte, realistische Daten testen, ohne die eigentliche Produktionsdatenbank zu berühren, und der Branch kann nach dem Merge einfach wieder gelöscht werden.

Preismodell und Grenzen

NeonDBs kostenlose und günstigere Preisstufen eignen sich gut für kleinere Projekte und Prototypen, haben aber Grenzen bei Speicherplatz, Compute-Zeit und Anzahl paralleler Verbindungen — bei stark wachsendem Traffic wird irgendwann ein kostenpflichtiger Tarif mit dediziertem, dauerhaft laufendem Compute nötig, bei dem der Auto-Suspend-Kostenvorteil an Bedeutung verliert. Für sehr traffic-intensive, latenzkritische Produktionsanwendungen kann eine klassisch selbst verwaltete oder dauerhaft gebuchte PostgreSQL-Instanz dann wieder wirtschaftlicher sein.

Siehe auch: SQL, PostgreSQL, Server