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>.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. |
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
*.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>.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.
Pooling
Jeder Endpoint akzeptiert standardmäßig bis zu ~100 gleichzeitige Verbindungen. Für kurzlebige Verbindungen (serverlose Funktionen, Edge-Runtimes) verwenden Sie einen clientseitigen Pooler wie PgBouncer oder den eingebauten Pool Ihres Treibers.
Ein verwalteter Pooler-Endpoint steht auf der Roadmap; bis dahin behandeln Sie Ihren Endpoint als eine einzelne Postgres-Instanz.
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.