Neon Auto-Suspend

Kurz: Eine Neon-spezifische Funktion, bei der die Datenbank-Compute-Instanz nach einer Zeit ohne Anfragen automatisch “einschläft” (herunterfährt) — spart Kosten, bedeutet aber, dass der allererste Request nach einer Ruhephase länger dauert, weil die Instanz erst wieder hochfahren muss (“Cold Start”).

Genauer: Wie lange die Inaktivität bis zum Einschlafen dauert (Auto-Suspend-Timeout) und ob man das überhaupt abschalten kann (“Always Active”), hängt vom Neon-Tarif ab — höhere Tarife erlauben das Deaktivieren dieses Verhaltens.

Kontext bei uns: Als möglicher Mit-Verursacher der gelegentlichen Ausfälle bei Emzett identifiziert, aber nicht per Code behebbar — das ist eine Neon-Projekteinstellung (Dashboard → Settings → Compute) bzw. eine Tarif-Frage, kein offener technischer Punkt im Repo selbst.

Im Detail

Warum der Cold Start entsteht

Der Cold Start nach dem Aufwachen entsteht dadurch, dass Neon die Compute-Instanz (den eigentlichen Postgres-Prozess) komplett stoppt, nicht nur pausiert — beim nächsten Request muss dieser Prozess neu gestartet werden und seinen Zustand (Shared Buffers/Caches, Verbindungspool, ggf. temporäre Objekte) neu aufbauen, bevor er die erste Query beantworten kann. Bei den meisten Neon-Tarifen liegt dieser Cold Start im Bereich von wenigen hundert Millisekunden bis zu ein bis zwei Sekunden — spürbar, aber i. d. R. nicht dramatisch, solange nicht mehrere Nutzer gleichzeitig auf denselben aufwachenden Prozess treffen und dadurch Anfragen sich stauen (Neon queued eingehende Verbindungen während des Aufwachens, statt sie sofort mit einem Fehler abzulehnen — die Anfragen werden also langsamer statt komplett zu scheitern).

Weil die Daten selbst getrennt vom Compute-Layer auf einem eigenen Storage-System liegen (siehe Neon), ist ein Auto-Suspend-Vorgang risikofrei bezüglich Datenverlust — es wird nur der Rechenprozess beendet, nicht der Speicherort der Daten.

Vergleich zu anderen “Scale-to-Zero”-Systemen

Ein verwandtes Konzept aus derselben Kategorie “Kosten sparen durch Skalierung nach null” ist Serverless-Compute allgemein (z. B. Vercel Functions oder AWS Lambda selbst) — auch dort gibt es Cold Starts, aus ähnlichen Gründen (ein Prozess/Container muss erst gestartet werden, bevor er Anfragen beantworten kann). Der Unterschied bei Neon: Bei einer typischen Serverless-Funktion betrifft ein Cold Start meist nur EINEN Request (jeder Request bekommt potenziell eine frische Funktionsinstanz), bei einer aufwachenden Datenbank betrifft die Verzögerung dagegen potenziell ALLE gleichzeitig eintreffenden Anfragen, die auf dieselbe Datenbankverbindung warten — es gibt schließlich nur eine Compute-Instanz pro Datenbank(-Branch), nicht beliebig viele parallele Instanzen wie bei Serverless-Functions.

Andere Cloud-Datenbanken mit ähnlichem Prinzip: AWS Aurora Serverless v2 skaliert Compute-Kapazität dynamisch, fährt aber im Vergleich zu Neon üblicherweise nicht komplett auf null herunter (es bleibt eine Mindest-Kapazität aktiv, entsprechend geringerer Kostenersparnis, aber auch kein echter Cold Start). PlanetScale (MySQL-kompatibel über Vitess) hat ein anderes Skalierungsmodell ohne direktes Äquivalent zu Auto-Suspend.

Umgang damit in der Praxis

Wer Cold Starts vermeiden will/muss (z. B. bei Latenz-kritischen Anwendungen oder häufigen kurzen Nutzungspausen, die das Timeout ständig triggern), hat im Wesentlichen drei Optionen: das Auto-Suspend-Timeout im Dashboard verlängern (verschiebt das Problem, löst es aber nicht), auf einen Tarif mit “Always Active”-Option upgraden (deaktiviert Auto-Suspend komplett gegen höhere Grundkosten), oder die Datenbank künstlich “warm halten” durch einen periodischen Health-Check-Request (z. B. per Cron-Job alle paar Minuten eine triviale Query ausführen) — Letzteres untergräbt allerdings den eigentlichen Kostenvorteil von Auto-Suspend und wird von Neon selbst eher nicht empfohlen.

Siehe auch: Neon, React.cache()