Connection-Strings
Format, TLS, Rollen- und Passwortregeln für Kisenon-Endpoints.
Jeder Kisenon-Endpoint stellt eine standardmäßige postgresql://-URI bereit:
postgresql://<role>:<pwd>@<endpoint_id>.<region>.kisenon.com:5432/<database>?sslmode=requireKomponenten
| Feld | Bedeutung |
|---|---|
<role> | Eine auf dem Branch erstellte Postgres-Rolle. Die Endpoint-Karte zeigt die automatisch erstellte app-Rolle; weitere können Sie via SQL erstellen. |
<pwd> | Das Passwort der Rolle. Bei der Erstellung einmal angezeigt; via SQL rotieren. |
<endpoint_id> | Pro Endpoint stabil, z. B. ep_4f3c12a9b8e6. SNI-geroutet. |
<region> | Das Regions-Slug Ihres Projekts — heute usc1 (US Central, GCP). Abgeleitet, nicht hartcodiert; siehe Regions. |
kisenon.com | Der Data-Plane-Apex. Routet via TLS-SNI zu Ihrem Endpoint. |
5432 | Standard-Postgres-Port. |
<database> | Standard main; weitere mit CREATE DATABASE erstellen. |
?sslmode=require | TLS ist obligatorisch. verify-full funktioniert ebenfalls und wird empfohlen. |
TLS
Endpoints terminieren TLS mit einem Let's-Encrypt-Zertifikat für
*.<region>.kisenon.com. Standard-Postgres-Clients verifizieren gegen den System-
Trust-Store; keine eigene CA nötig.
sslmode=verify-full wird für Produktionscode empfohlen. Es prüft die
Zertifikatskette und den Hostnamen.
Wie der Proxy zu Ihrem Endpoint routet
Der Data-Plane-Proxy entscheidet anhand von zwei Signalen, in dieser Reihenfolge, zu welchem Endpoint eine Verbindung gehört:
- Die
neon.endpoint_id-Startup-Option, falls der Client eine sendet. - Der TLS-SNI-Hostname (
<endpoint_id>.<region>.kisenon.com) als Fallback.
Das Username-Feld wird für das Routing nicht konsultiert — wählen Sie eine beliebige Rolle, die Ihr Branch definiert. Von der Konsole generierte Connection-Strings tragen den Endpoint im Hostnamen, sodass sie automatisch via SNI routen und Sie nichts Zusätzliches festlegen müssen.
Geben Sie neon.endpoint_id nur explizit an, wenn Ihr Client den
Endpoint nicht in SNI vorlegen kann — zum Beispiel ein TLS-Stack, der keine Server-
Name-Erweiterung sendet, oder ein Tunnel, der den Host umschreibt. Die meisten Postgres-
Treiber senden SNI standardmäßig, sodass dies selten benötigt wird.
Connection-Pooling
Pooling ist GA und standardmäßig aktiviert — jeder Endpoint hat einen gepoolten Host neben seinem direkten (seit 2026-07-18).
Der gepoolte Host ist <endpoint_id>-pooler.<region>.kisenon.com — derselbe
Endpoint, mit -pooler eingefügt in das Host-Label — auf Port 5432
mit sslmode=require:
postgresql://<role>:<pwd>@<endpoint_id>-pooler.<region>.kisenon.com:5432/<database>?sslmode=requireDas Connect-Panel der Konsole und die API-Antwort reichen Ihnen beide einen
connection_uri_pooled neben dem direkten connection_uri.
Der Pooler läuft im Transaction-Pooling-Modus (ein PgBouncer-Sidecar pro Compute). Das ist ideal für viele kurzlebige Verbindungen — serverlose Funktionen, Edge-Runtimes, Agenten — wo jede Transaktion sich eine Server-Verbindung leihen und sofort zurückgeben kann.
Verwenden Sie stattdessen die direkte (ungepoolte :5432) Verbindung, wenn Sie brauchen:
LISTEN/NOTIFY.- Session-Level-Advisory-Locks.
- Session-
SET/ GUCs, die eine einzelne Transaktion überdauern müssen. - Serverseitige Prepared Statements.
Der direkte connection_uri ist immer verfügbar und wird nie entfernt, sodass
diese genau wie zuvor weiter funktionieren. Ein clientseitiger Pool (PgBouncer oder
der eingebaute Pool Ihres Treibers) vor der direkten Verbindung bleibt ebenfalls
gültig.
Nehmen Sie einen Endpoint vom Pooling aus mit dem pooler_enabled: false-Feld zur
Erstellungszeit oder via PATCH /v1/endpoints/{endpointId}. Der Standard ist
true.
Mehrere Endpoints
Sie können mehrere Endpoints auf demselben Branch erzeugen. Sie teilen sich den Speicher, haben aber unabhängige Verbindungslimits und Caches. Verwenden Sie sie zur Isolation:
- App- vs. Analytik-Traffic.
- Read-Replicas (jeder Endpoint auf einem Branch ist im Wesentlichen eine Read-Replica, wenn Sie nicht in ihn schreiben).
- Pro-Umgebung-Endpoints auf Dev-Branches.