Dies ist jedoch kein universelles Konzept. Supabase und Aurabase, die dedizierte Postgres-Instanzen bereitstellen, stellen denselben Mechanismus nicht auf die gleiche Weise bereit. In diesem Artikel wird detailliert beschrieben, was Neon bei seinem eigenen Kaltstart tatsächlich dokumentiert, wie sich Vercel Postgres und Supabase vergleichen und wo das Aurabase-Modell passt, das direkt im Provisioner-Code überprüft und nicht von einer Marketingseite abgeleitet wird.
Das Wesentliche
- Der serverlose Kaltstart bezieht sich auf die Verzögerung, die hinzugefügt wird, wenn eine angehaltene Datenbank ihre Rechenleistung aufwecken muss, bevor sie auf die erste Anfrage antwortet.
- Neon trennt Speicherung und Berechnung: Der Computer geht nach einer dokumentierten Zeit der Inaktivität in den Ruhezustand (standardmäßig 5 Minuten beim kostenlosen Plan, konfigurierbar bei den kostenpflichtigen Plänen).
- Neon dokumentiert einen Neustart typischerweise in der Größenordnung von einigen hundert Millisekunden bis einigen Sekunden, eine vom Herausgeber veröffentlichte Zahl, die live über das Community-Tool neon-latency-benchmarks.vercel.app messbar ist.
- Vercel Postgres setzt auf die Neon-Infrastruktur: Das Weckverhalten folgt der gleichen Mechanik, unter einer anderen Marke.
- Supabase bietet eine dedizierte Datenbank pro Projekt, ohne Kaltstart pro Verbindung. Nur der kostenlose Plan pausiert inaktive Projekte mit manueller Wiederherstellung.
- Aurabase stellt pro Projekt eine dedizierte Postgres-Datenbank, einen dedizierten CNPG-Cluster oder eine dedizierte Basis auf einem gemeinsam genutzten Cluster bereit: Dies ist kein serverloses Neon-Modell, das im Bereitstellungscode überprüft wird.
Was ist ein Kaltstart für eine serverlose Postgres-Datenbank?
Ein Kaltstart erfolgt, wenn die Recheneinheit, die Ihre Datenbank ausführt, aufgrund von Inaktivität in den Ruhezustand versetzt wurde und eine neue Abfrage sie zunächst neu starten muss, bevor sie ausgeführt werden kann. Dies ist nicht die übliche Netzwerklatenz einer typischen TCP/TLS-Verbindung: Dies ist die Zeit, einen neuen Postgres-Prozess zu starten und seinen Zustand wiederherzustellen, noch bevor die erste Anforderung ausgeführt wird.
Der Begriff stammt im Allgemeinen aus dem Bereich Serverless Computing, bei dem eine Nullausführungsumgebung neu gestartet werden muss, bevor eine Anforderung verarbeitet wird, unabhängig davon, ob es sich um eine Serverfunktion oder eine WebAssembly-Laufzeit am Edge handelt. Wir beschreiben diesen Mechanismus auf der Seite der Randfunktionen in unserem Artikel über -Kaltstart von WebAssembly gegenüber-Containern. Bei einer Datenbank sind die Mechanismen unterschiedlich: Es wird keine kompilierte Binärdatei gestartet, sondern ein vollständiger Postgres-Server, der seine Dateien erneut öffnen, seinen Status validieren und dann neue Verbindungen akzeptieren muss.
1. Kundenlogin
Eine Anfrage geht bei einem Projekt ein, dessen Rechenleistung angehalten ist.
2. Schlaferkennung
Die Plattform stellt fest, dass die Rechenleistung nicht mehr aktiv ist.
3. Starten Sie die Berechnung neu
Der Postgres-Prozess startet neu, der notwendige Zustand wird wiederhergestellt.
4. Anfrage bearbeitet
Die Verbindung ist erfolgreich, die Anfrage wird normal ausgeführt.
Darstellung des Kaltstartmechanismus, vereinfachter Ablauf, ohne gemessenen Zeitwert.
Warum Neon seine Rechenleistung in den Ruhezustand versetzt und mit welcher Geschwindigkeit
Neon unterteilt seine Datenbankarchitektur in zwei unterschiedliche Schichten: persistenten Speicher, der die Daten speichert, und Berechnung, den Postgres-Prozess selbst, der unabhängig gestoppt und neu gestartet werden kann. Diese Trennung ermöglicht es Neon, die Berechnung eines inaktiven Projekts auszusetzen, ohne die Daten zu berühren, und es dann bei Bedarf neu zu starten, heißt es in der offiziellen Dokumentation.
Beim kostenlosen Plan dokumentiert Neon ein standardmäßiges Inaktivitäts-Timeout von 5 Minuten, bevor der Computer in den Ruhezustand versetzt wird. Mit kostenpflichtigen Plänen können Sie diesen Schwellenwert konfigurieren oder ihn für die Verwendung bei konstantem Datenverkehr sogar erheblich erhöhen. Diese Art von Standardänderungen erfolgt bei Produktaktualisierungen: Sehen Sie sich die zum Zeitpunkt der Lektüre aktuelle Neon-Dokumentation an und nicht diese isolierte Abbildung.
Dieses Design dient einem bestimmten Zweck, nämlich kurzlebigen Umgebungen. Eine Datenbank pro Git-Zweig, eine Vorschauumgebung per Pull-Request, eine Testdatenbank, die nur wenige Minuten pro Tag verwendet wird: Der kontinuierliche Betrieb einer Rechenleistung für diese Zwecke ist teuer und bringt keinen wirklichen Nutzen. Das Aussetzen der Rechenleistung zwischen zwei Nutzungen reduziert die Kosten, ohne dass die Daten gelöscht werden. Dies ist das zentrale Argument des serverlosen Modells von Neon.
Wie lange hält ein Neon-Wecker und wie kann man ihn selbst überprüfen?
Neon gibt in seiner Dokumentation einen Rechenneustart an, der typischerweise in der Größenordnung von einigen hundert Millisekunden bis einigen Sekunden liegt, abhängig von der Größe des Projekts und der Menge der Transaktionsprotokolle, die wiedergegeben werden müssen, bevor die Rechenleistung bereit ist. Hierbei handelt es sich um eine vom Herausgeber selbst veröffentlichte Zahl, nicht um eine unabhängige Prüfung: Betrachten Sie sie als dokumentierte Größenordnung und nicht als vertragliche Garantie.
Für reale Messungen fragt ein öffentliches Community-Tool, neon-latency-benchmarks.vercel.app, in regelmäßigen Abständen suspendierte Neon-Projekte ab und zeigt die beobachtete Aktivierungslatenz an. Dies ist die Art von Methodik, die wichtiger ist als eine bloße Dokumentationszahl: Die Testbedingungen bleiben sichtbar und werden nicht hinter einem Marketingdurchschnitt verborgen. Wir wenden das gleiche Prinzip in unserer eigenen Backend-Benchmark-Methodik an: Veröffentlichen Sie das Protokoll, bevor Sie eine Zahl veröffentlichen.
| Projektgröße | Mehr Beziehungen und WAL-Volumen zur Validierung verlängern den Neustart. |
|---|---|
| Region und Netzwerkentfernung | Erhöht die Verbindungslatenz, unabhängig vom Kaltstart selbst. |
| Preisplan | Mit kostenpflichtigen Plänen können Sie den Inaktivitätsschwellenwert konfigurieren oder erweitern. |
| Häufigkeit der Verbindungen | Bei einer regelmäßig angeforderten Rechenleistung kommt es nie zu dieser Verzögerung. |
Vercel Postgres und Neon: derselbe Motor unter einer anderen Marke?
Vercel hat sein Postgres-Datenbankangebot auf Basis der Neon-Infrastruktur aufgebaut, eine Partnerschaft, die 2024 veröffentlicht wurde. Zum Zeitpunkt des Verfassens dieses Artikels wird diese Postgres-Integration zusammen mit anderen Anbietern auf dem Vercel Marketplace als Speicheroption angeboten. Schauen Sie sich die aktualisierte Vercel-Produktseite an: Diese Art von Partnerschaft entwickelt sich schnell in einem Markt, der sich jedes Quartal ändert.
Konkret folgt das Schlaf- und Aufwachverhalten einer über Vercel bereitgestellten Postgres-Datenbank denselben Mechanismen wie oben direkt für Neon beschrieben. Es handelt sich nicht um eine separate Engine mit eigenem Kaltstartmodell, sondern um dieselbe Infrastruktur, die hinter einer Vercel-Integration zur Verfügung steht.
Hat Supabase einen vergleichbaren Kaltstart?
Nein, nicht auf die gleiche Weise. Supabase stellt eine dedizierte Postgres-Instanz pro Projekt bereit und nicht eine serverlose Rechenleistung, die pro Verbindung unterbrochen wird. Im Gegensatz zum Neon-Modell gibt es daher keine Aufwachverzögerung bei jeder neuen Sitzung nach einigen Minuten Inaktivität.
Beim kostenlosen Plan gibt es jedoch einen anderen Mechanismus: Supabase dokumentiert eine automatische Pause inaktiver Projekte nach einem längeren Zeitraum, der laut Dokumentation in der Größenordnung von einer Woche liegt, mit manueller Wiederherstellung über das Dashboard anstelle eines automatischen Aufwachens bei der ersten Anfrage. Es handelt sich um einen Schwellenwert, der in Tagen und nicht in Minuten gemessen wird, und eher eine explizite Aktion als eine transparente Wiederherstellung: zwei strukturelle Unterschiede zum Neon-Kaltstart, keine einfache Variation desselben Mechanismus. Für einen vollständigen Architekturvergleich dokumentiert unser detaillierter Vergleich zwischen Aurabase und Supabase weitere Diskrepanzen.
Und das Aurabase-Modell: Warum der Vergleich nicht so gilt, wie er ist
Aurabase bietet kein serverloses Modell wie Neon an. Verifiziert im Provisioner-Code (aura-provisioner, Open Source auf github.com/daylami555/aurabase): Jedes Projekt erhält je nach gewähltem Plan entweder einen dedizierten Postgres-Cluster, der von CloudNativePG, dem Kubernetes-CNPG-Betreiber, verwaltet wird, oder eine dedizierte Basis auf einem CNPG-Cluster, der von mehreren Projekten derselben Organisation gemeinsam genutzt wird. In beiden Fällen handelt es sich nicht um einen einzelnen Rechner, der bei jeder Verbindung anhält und wieder aufwacht: Es handelt sich um einen vollständigen Postgres-Cluster mit primären und möglichen Replikaten.
Auf der Aurabase-Seite gibt es zwar einen Ruhezustandsmechanismus, der jedoch einem anderen Zweck dient. Bei längerer Inaktivität, standardmäßig 7 Tage und über eine Umgebungsvariable konfigurierbar, Schwellenwert im Code überprüft, versetzt der Provisioner inaktive Instanzen in den Ruhezustand, um Ressourcen freizugeben, nicht um die Latenz der intermittierenden Nutzung zu optimieren. Beim Aufwecken eines schlafenden CNPG-Clusters werden seine Pods aus persistenten Volumes neu erstellt. Dies ist ein strukturell schwererer Mechanismus als ein einfacher serverloser Prozessneustart.
Aurabase hat bisher keine Zahlen zur Aufwachlatenz veröffentlicht, weder um eine schnelle Aufwachzeit zu behaupten, noch um es mit Neon zu vergleichen. Es handelt sich nicht um dasselbe Produkt und es wäre unehrlich, es ohne veröffentlichte Messungen als solches auszugeben.
Diese dedizierte Architektur hat ein direktes Gegenstück in Bezug auf Isolation und Leistungsvorhersagbarkeit: Ein Projekt teilt seine Rechenleistung nicht mit einem anderen Projekt, anders als bei einem gemeinsam genutzten Cluster mit geringer Größe. Wir beschreiben diese Schlichtung in einem speziellen Artikel: dedizierte vs. gemeinsam genutzte Basis, tatsächliche Auswirkungen auf Leistung und Isolation.
Wählen Sie entsprechend Ihrem Anwendungsfall
Das serverlose Neon-Modell bedient einen bestimmten Anwendungsfall: viele kurzlebige Umgebungen oder Umgebungen mit sehr intermittierendem Datenverkehr, in denen es wirtschaftlich keinen Sinn macht, für eine kontinuierlich laufende Rechenleistung zu bezahlen. Eine Datenbank pro Git-Zweig, eine Vorschauumgebung per Pull-Request, ein mehrmals pro Woche getesteter Prototyp: Der gelegentliche Kaltstart wird zu einem akzeptablen Kompromiss gegenüber einer Rechnung, die proportional zur tatsächlichen Nutzung ist.
Umgekehrt ist eine dedizierte, immer verfügbare Postgres-Architektur immer dann vorzuziehen, wenn die Latenz der ersten Verbindung vorhersehbar bleiben muss: eine Produktions-API mit regelmäßigem Datenverkehr, ein Backend, das sich einen gelegentlichen Latenzanstieg bei einer Benutzeranfrage nicht leisten kann, oder ein System, bei dem p99 wichtiger ist als die Kosten eines isolierten Testzweigs.
| Lieferant | Berechnungsmodell | Schlafauslöser | Typischer Wecker |
|---|---|---|---|
| Neon | Vom Speicher getrenntes serverloses Computing | Inaktivität, ab 5 Minuten (kostenloser Plan) | Automatisch, Subsekunde bis Sekunde (angeblicher Editor) |
| Vercel Postgres | Neon Infrastructure (Partnerschaft) | Das Gleiche wie Neon | Das Gleiche wie Neon |
| Supabase | Eigenes Gremium pro Projekt | Längere Inaktivität, nur kostenloser Plan | Manuell, Wiederherstellung über das Dashboard |
| Aurabase | Dedizierter oder gemeinsam genutzter CNPG-Cluster | Längere Inaktivität, standardmäßig 7 Tage | Nicht als Subsekunde gedacht, nicht veröffentlicht |
Neon-Wecker: Größenordnung vom Verlag dokumentiert, nicht unabhängig geprüft. Aurabase-Ruhezustandsschwellenwert: eingecheckt aura-provisioner, Variable HIBERNATE_INACTIVITY_DAYS, Standard 7 Tage.
Häufig gestellte Fragen
Woran Sie sich erinnern sollten
Der serverlose Kaltstart von Postgres ist kein universelles Konzept: Er ist eine direkte Folge der Neon-Architektur, die Speicherung und Berechnung trennt, um letztere zwischen zwei Verwendungen zu unterbrechen. Vercel Postgres erbt es direkt über seine Partnerschaft mit Neon. Supabase und Aurabase, die dedizierte Postgres-Instanzen bereitstellen, stellen einen anderen Mechanismus zur Verfügung, der in Tagen statt in Minuten gemessen wird und nicht für denselben Zweck konzipiert ist.
Bevor Sie einen Anbieter allein aufgrund dieses Kriteriums auswählen, prüfen Sie drei Dinge: den tatsächlichen, vom Anbieter dokumentierten Inaktivitätsschwellenwert, ob er in Ihrem Plan konfigurierbar ist und ob Ihr Anwendungsverkehr eine Unterbrechung der Datenverarbeitung rechtfertigt. Für den Einsatz bei echtem intermittierenden Datenverkehr, Testverzweigungen oder Vorschauen bietet das serverlose Modell einen klaren wirtschaftlichen Vorteil. Für eine Produktion mit regelmäßigem Datenverkehr entfällt diese Frage durch eine dedizierte Architektur einfach.