Chaînes de connexion

Chaque endpoint Kisenon expose un URI postgresql:// standard :

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

Composants

TLS

Les endpoints terminent TLS avec un certificat Let's Encrypt pour *.<region>.kisenon.com ; aucune CA personnalisée n'est donc nécessaire.

La chaîne de connexion fournie par Kisenon — le format Connection string de la console, keon connection-string et l'API — utilise sslmode=require. La connexion est chiffrée, mais avec require la plupart des pilotes ne vérifient pas le certificat du serveur. Elle reste la valeur par défaut parce que c'est la seule que tous les pilotes acceptent.

Vérifier le certificat du serveur

Pour que votre pilote vérifie la chaîne de certificats et le nom d'hôte, utilisez les paramètres propres à votre pilote. Les formats par pilote de la console le font déjà.

Les pièges courants :

• libpq antérieur à 16 ne comprend pas sslrootcert=system. Utilisez-y sslmode=require comme repli délibéré : chiffré, non vérifié.
• Ne donnez jamais sslrootcert=system à un pilote Node.js. pg (et Prisma 7, qui l'utilise) tente de lire un fichier nommé system et échoue ; postgres.js l'envoie au serveur, qui refuse la connexion.
• Les wheels binaires Python (psycopg[binary], psycopg2-binary) embarquent leur propre OpenSSL, dont le magasin de confiance système est vide : sslrootcert=system échoue donc avec certificate verify failed. Indiquez le bundle de votre OS avec SSL_CERT_FILE — sous Debian/Ubuntu, SSL_CERT_FILE=/etc/ssl/certs/ca-certificates.crt. Le chemin diffère sur les autres systèmes.
• Windows n'a pas de magasin de confiance PEM : sslrootcert=system échoue avec certificate verify failed dans tout client basé sur libpq — psql, psycopg, la gem Ruby pg. Indiquez plutôt un fichier de CA à sslrootcert. En Python, utilisez certifi : pip install certifi, puis sslrootcert=certifi.where() (valable sur tous les OS, c'est pourquoi les formats Python de la console l'utilisent). Pour psql ou Rails, téléchargez le bundle Mozilla depuis https://curl.se/ca/cacert.pem et passez son chemin : sslrootcert=C:\certs\cacert.pem.
• Prisma 6 ne vérifie pas le certificat tant que sslaccept=strict n'est pas défini, quelle que soit la valeur de sslmode.
• postgres.js ne vérifie pas le certificat avec sslmode=require.
• JDBC avec un simple sslmode=verify-full cherche ~/.postgresql/root.crt ; sslfactory=org.postgresql.ssl.DefaultJavaSSLFactory lui fait utiliser le magasin de confiance de la JVM à la place.

Comment le proxy route vers votre endpoint

Le proxy du plan de données décide à quel endpoint appartient une connexion à partir de deux signaux, dans l'ordre :

1. L'option de démarrage neon.endpoint_id, si le client en envoie une.
2. Le nom d'hôte SNI TLS (<endpoint_id>.<region>.kisenon.com) en repli.

Le champ nom d'utilisateur n'est pas consulté pour le routage — choisissez n'importe quel rôle que votre branche définit. Les chaînes de connexion générées par la console portent l'endpoint dans le nom d'hôte, elles routent donc via SNI automatiquement et vous n'avez rien d'extra à définir.

Passez neon.endpoint_id explicitement seulement lorsque votre client ne peut pas présenter l'endpoint dans SNI — par exemple une pile TLS qui n'envoie pas d'extension Server Name, ou un tunnel qui réécrit l'hôte. La plupart des pilotes Postgres envoient SNI par défaut, cela est donc rarement nécessaire.

Regroupement de connexions

Le regroupement est GA et activé par défaut — chaque endpoint dispose d'un hôte regroupé en plus de son hôte direct (depuis le 2026-07-18).

L'hôte regroupé est <endpoint_id>-pooler.<region>.kisenon.com — le même endpoint, avec -pooler inséré dans le libellé d'hôte — sur le port 5432 avec sslmode=require :

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

Le panneau Connect de la console et la réponse de l'API vous fournissent tous deux un connection_uri_pooled en plus du connection_uri direct.

Le pooler fonctionne en mode regroupement par transaction (un sidecar PgBouncer par compute). C'est idéal pour de nombreuses connexions de courte durée — fonctions serverless, runtimes edge, agents — où chaque transaction peut emprunter une connexion serveur et la rendre immédiatement.

Utilisez plutôt la connexion directe (non regroupée :5432) lorsque vous avez besoin de :

• LISTEN / NOTIFY.
• Verrous consultatifs au niveau session.
• SET de session / GUC qui doivent survivre à une seule transaction.
• Instructions préparées côté serveur.

Le connection_uri direct est toujours disponible et n'est jamais supprimé, de sorte que ceux-ci continuent de fonctionner exactement comme avant. Un pool côté client (PgBouncer ou le pool intégré de votre pilote) devant la connexion directe reste également valide.

Excluez un endpoint du regroupement avec le champ pooler_enabled: false à la création ou via PATCH /v1/endpoints/{endpointId}. La valeur par défaut est true.

Endpoints multiples

Vous pouvez générer plusieurs endpoints sur la même branche. Ils partagent le stockage mais ont des limites de connexion et des caches indépendants. Utilisez-les pour isoler :

• Le trafic app vs analytique.
• Les réplicas de lecture (tout endpoint sur une branche est essentiellement un réplica de lecture si vous n'y écrivez pas).
• Des endpoints par environnement sur les branches de dev.