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. Les clients Postgres standard vérifient contre le magasin de confiance système ; aucune CA personnalisée nécessaire.

sslmode=verify-full est recommandé pour le code de production. Il vérifie la chaîne de certificats et le nom d'hôte.

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.