Chaînes de connexion
Format, TLS, règles de rôle et de mot de passe pour les endpoints Kisenon.
Chaque endpoint Kisenon expose un URI postgresql:// standard :
postgresql://<role>:<pwd>@<endpoint_id>.kisenon.com:5432/<database>?sslmode=requireComposants
| Champ | Signification |
|---|---|
<role> | Un rôle Postgres créé sur la branche. La carte de l'endpoint affiche le rôle app auto-créé ; vous pouvez en créer d'autres via SQL. |
<pwd> | Le mot de passe du rôle. Exposé une fois à la création ; faites-le tourner via SQL. |
<endpoint_id> | Stable par endpoint, p. ex. ep_4f3c12a9b8e6. Routé par SNI. |
kisenon.com | L'apex du plan de données. Route via SNI TLS vers votre endpoint. |
5432 | Port Postgres standard. |
<database> | main par défaut ; créez-en d'autres avec CREATE DATABASE. |
?sslmode=require | TLS est obligatoire. verify-full fonctionne aussi et est recommandé. |
TLS
Les endpoints terminent TLS avec un certificat Let's Encrypt pour
*.kisenon.com. Les clients Postgres standard vérifient par rapport au magasin
de confiance du 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 :
- L'option de démarrage
neon.endpoint_id, si le client en envoie une. - Le nom d'hôte SNI TLS (
<endpoint_id>.kisenon.com) en repli.
Le champ de nom d'utilisateur n'est pas consulté pour le routage — choisissez n'importe quel rôle que définit votre branche. Les chaînes de connexion générées par la console portent l'endpoint dans le nom d'hôte, donc elles routent automatiquement via SNI et vous n'avez rien d'autre à régler.
Passez neon.endpoint_id explicitement seulement quand votre client ne peut pas
présenter l'endpoint dans le 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 drivers
Postgres envoient le SNI par défaut, donc c'est rarement nécessaire.
Pooling
Chaque endpoint accepte jusqu'à environ 100 connexions concurrentes par défaut. Pour les connexions de courte durée (fonctions serverless, runtimes edge), utilisez un pooler côté client comme PgBouncer ou le pool intégré de votre driver.
Un endpoint pooler géré est sur la feuille de route ; d'ici là, traitez votre endpoint comme une instance Postgres unique.
Plusieurs endpoints
Vous pouvez engendrer 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 application 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).
- Les endpoints par environnement sur les branches de dev.