Endpoints

Ein Endpoint ist der Postgres-Prozess, der Client-Verbindungen akzeptiert. Endpoints sind ephemer: Sie suspendieren im Leerlauf, wachen beim ersten Paket auf und laufen auf der separierten Speicherschicht des Projekts. Zahlen Sie nur für die Sekunden, in denen Compute tatsächlich läuft.

Typen

Typ	Schreibvorgänge?	Wann verwenden
`rw`	Ja	Der Standard. App-Traffic, Migrationen, alles, was mutiert. Ein `rw`-Endpoint pro Branch reicht für typische Workloads.
`ro`	Nein	Read-Replicas. Mehrere `ro`-Endpoints können an denselben Branch angehängt werden und Speicher teilen; ihre lokalen Caches bleiben unabhängig. Verwenden Sie sie, um Analytik-Traffic von App-Traffic zu isolieren.

Beide Typen hängen sich an genau einen Branch. Ein Endpoint kann nicht zu einem anderen Branch wechseln; erstellen Sie stattdessen einen neuen Endpoint auf dem Ziel-Branch.

Suspend-on-Idle

Endpoints suspendieren nach einem konfigurierbaren Fenster ohne Client-Aktivität. Der Standard sind 300 Sekunden (5 Minuten). Setzen Sie suspend_after_seconds zur Erstellungszeit, um ihn zu überschreiben; das neue Fenster wird in der nächsten Leerlaufphase des Endpoints wirksam.

Während der Suspendierung:

Der Compute-Pod ist weg. Keine CPU, kein Speicher abgerechnet.
Der Speicher ist unberührt — Ihre Daten sind dauerhaft im Pageserver.
Die Endpoint-ID und der Connection-String bleiben gültig.

Wake

Das Senden eines Pakets an einen suspendierten Endpoint weckt ihn. Die Cold-Start-Latenz beträgt typischerweise 300–500 ms, sobald der Cluster den warmen Pageserver- Cache hat; das allererste Aufwachen nach einer langen Leerlaufzeit (oder nach einem frischen Projekt) kann 10–30 Sekunden dauern, während der Pageserver-Page-Cache sich aufwärmt. Standard-Postgres-Treiber sehen dies in typischen Konfigurationen nicht als Timeout — siehe Fehlerbehebung, falls doch.

Routinemäßige Wakes sind schnell, weil die Plattform einen Pool von Compute vorgewärmt vor der Nachfrage hält: Ein Wake hängt sich in der Regel an bereits laufendes Compute an, statt es von Grund auf zu booten. Sie verwalten den Pool weder noch zahlen Sie dafür — er beeinflusst nur, wie schnell Ihr Endpoint zurückkommt.

Zustandsautomat

Ein Endpoint durchläuft folgende Übergänge:

Pending → Starting → Running → Stopping → Stopped → (Failed)

Pending — die Control Plane hat die Erstellungsanfrage akzeptiert und plant den Compute-Pod ein. Wenn Sie einen Endpoint hier mehr als ein paar Sekunden festhängen sehen, siehe Fehlerbehebung.
Starting — der Compute-Pod ist oben; Postgres initialisiert und spielt WAL bis zum HEAD des Branches ab.
Running — akzeptiert Client-Verbindungen.
Stopping — Leerlauffenster abgelaufen; Verbindungen werden geleert und lokaler Zustand wird geflusht.
Stopped — suspendiert. Wartet auf das nächste Paket zum Aufwachen.
Failed — terminaler Fehler. Die Endpoint-Karte zeigt den Grund; selten, passiert aber, wenn die Einplanung fehlschlägt oder das Compute- Image nicht starten kann.

Connection-URI

Das Wire-Format ist in Connection-Strings dokumentiert:

postgresql://<role>:<pwd>@<endpoint_id>.kisenon.com:5432/<database>?sslmode=require

Der Hostname wird aus der Endpoint-ID abgeleitet, nicht aus der Projekt-ID — jeder Endpoint terminiert TLS unabhängig. TLS ist erforderlich.

Erstellen

keon endpoints create --branch <branch-id> --type rw

Optionale Flags:

--suspend-after-seconds <n>, um das Standard-Suspend-Fenster zu überschreiben.
--type ro für einen Read-Only-Endpoint.

Die CLI gibt die Endpoint-ID und den Connection-String zurück. Der Endpoint ist Running und bereit, Verbindungen zu akzeptieren, innerhalb weniger Sekunden nach Rückkehr des Aufrufs.

Löschen

keon endpoints delete <endpoint-id>

Offene Client-Verbindungen werden getrennt. Die Endpoint-ID wird stillgelegt und ihr DNS-Hostname löst nicht mehr auf. Der Branch und seine Daten bleiben unberührt.