Connection-Strings

Jeder Kisenon-Endpoint stellt eine standardmäßige postgresql://-URI bereit:

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

Komponenten

TLS

Endpoints terminieren TLS mit einem Let's-Encrypt-Zertifikat für *.<region>.kisenon.com, daher ist keine eigene CA nötig.

Der Connection-String, den Kisenon ausgibt — das Format Connection string in der Konsole, keon connection-string und die API — verwendet sslmode=require. Die Verbindung ist verschlüsselt, aber unter require prüfen die meisten Treiber das Serverzertifikat nicht. Er bleibt der Standard, weil es der einzige Wert ist, den jeder Treiber akzeptiert.

Das Serverzertifikat verifizieren

Damit Ihr Treiber die Zertifikatskette und den Hostnamen prüft, verwenden Sie die Parameter für Ihren Treiber. Die treiberspezifischen Formate der Konsole tun das bereits.

Typische Stolperfallen:

• libpq älter als 16 versteht sslrootcert=system nicht. Verwenden Sie dort bewusst sslmode=require als Fallback: verschlüsselt, nicht verifiziert.
• Geben Sie einem Node.js-Treiber nie sslrootcert=system. pg (und Prisma 7, das es verwendet) versucht, eine Datei namens system zu lesen, und scheitert; postgres.js schickt den Parameter an den Server, der die Verbindung ablehnt.
• Python Binary Wheels (psycopg[binary], psycopg2-binary) bringen ihr eigenes OpenSSL mit, dessen System-Trust-Store leer ist, daher scheitert sslrootcert=system mit certificate verify failed. Verweisen Sie mit SSL_CERT_FILE auf das Zertifikatsbündel Ihres Betriebssystems — unter Debian/Ubuntu SSL_CERT_FILE=/etc/ssl/certs/ca-certificates.crt. Auf anderen Systemen ist der Pfad ein anderer.
• Windows hat keinen PEM-Zertifikatsspeicher, daher scheitert sslrootcert=system in jedem libpq-basierten Client — psql, psycopg, das Ruby-Gem pg — mit certificate verify failed. Geben Sie sslrootcert stattdessen eine CA-Bundle-Datei. In Python mit certifi: pip install certifi, dann sslrootcert=certifi.where() (funktioniert auf jedem Betriebssystem, deshalb nutzen es die Python-Formate der Konsole). Für psql oder Rails das Mozilla-Bundle von https://curl.se/ca/cacert.pem herunterladen und den Pfad übergeben: sslrootcert=C:\certs\cacert.pem.
• Prisma 6 prüft das Zertifikat nicht, solange sslaccept=strict nicht gesetzt ist, egal was sslmode sagt.
• postgres.js prüft das Zertifikat unter sslmode=require nicht.
• JDBC sucht mit bloßem sslmode=verify-full nach ~/.postgresql/root.crt; sslfactory=org.postgresql.ssl.DefaultJavaSSLFactory lässt es stattdessen den Trust-Store der JVM verwenden.

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:

1. Die neon.endpoint_id-Startup-Option, falls der Client eine sendet.
2. 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=require

Das 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.