Cadenas de conexión

Cada endpoint de Kisenon expone una URI postgresql:// estándar:

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

Componentes

TLS

Los endpoints terminan TLS con un certificado de Let's Encrypt para *.<region>.kisenon.com, así que no se necesita una CA personalizada.

La cadena de conexión que entrega Kisenon — el formato Connection string de la consola, keon connection-string y la API — usa sslmode=require. La conexión va cifrada, pero con require la mayoría de los drivers no comprueban el certificado del servidor. Sigue siendo el valor por defecto porque es el único que aceptan todos los drivers.

Verificar el certificado del servidor

Para que tu driver compruebe la cadena del certificado y el nombre de host, usa los parámetros de tu driver. Los formatos por driver de la consola ya lo hacen.

Lo que suele dar problemas:

• libpq anterior a 16 no entiende sslrootcert=system. Usa ahí sslmode=require como alternativa deliberada: cifrado, sin verificar.
• Nunca le pases sslrootcert=system a un driver de Node.js. pg (y Prisma 7, que lo usa) intenta leer un archivo llamado system y falla; postgres.js lo envía al servidor, que rechaza la conexión.
• Los wheels binarios de Python (psycopg[binary], psycopg2-binary) incluyen su propio OpenSSL, cuyo almacén de confianza del sistema está vacío, así que sslrootcert=system falla con certificate verify failed. Apúntalo al bundle de tu sistema operativo con SSL_CERT_FILE — en Debian/Ubuntu, SSL_CERT_FILE=/etc/ssl/certs/ca-certificates.crt. La ruta es distinta en otros sistemas.
• Windows no tiene un almacén de confianza PEM, así que sslrootcert=system falla con certificate verify failed en cualquier cliente basado en libpq — psql, psycopg, la gema pg de Ruby. Apunta sslrootcert a un archivo de CA. Desde Python, usa certifi: pip install certifi y luego sslrootcert=certifi.where() (funciona en cualquier sistema operativo; por eso lo usan los formatos Python de la consola). Para psql o Rails, descarga el bundle de Mozilla desde https://curl.se/ca/cacert.pem y pasa su ruta: sslrootcert=C:\certs\cacert.pem.
• Prisma 6 no comprueba el certificado a menos que se defina sslaccept=strict, diga lo que diga sslmode.
• postgres.js no comprueba el certificado con sslmode=require.
• JDBC con sslmode=verify-full a secas busca ~/.postgresql/root.crt; sslfactory=org.postgresql.ssl.DefaultJavaSSLFactory hace que use el almacén de confianza de la JVM en su lugar.

Cómo el proxy enruta a tu endpoint

El proxy del plano de datos decide a qué endpoint pertenece una conexión a partir de dos señales, en orden:

1. La opción de arranque neon.endpoint_id, si el cliente envía una.
2. El nombre de host SNI de TLS (<endpoint_id>.<region>.kisenon.com) como respaldo.

El campo de nombre de usuario no se consulta para el enrutamiento — elige cualquier rol que tu rama defina. Las cadenas de conexión generadas por la consola llevan el endpoint en el nombre de host, de modo que enrutan por SNI automáticamente y no necesitas configurar nada extra.

Pasa neon.endpoint_id explícitamente solo cuando tu cliente no puede presentar el endpoint en SNI — por ejemplo una pila TLS que no envía una extensión Server Name, o un túnel que reescribe el host. La mayoría de los controladores de Postgres envían SNI por defecto, así que esto rara vez es necesario.

Agrupación de conexiones (pooling)

El pooling está GA y activado por defecto — cada endpoint tiene un host agrupado junto a su host directo (desde 2026-07-18).

El host agrupado es <endpoint_id>-pooler.<region>.kisenon.com — el mismo endpoint, con -pooler insertado en la etiqueta de host — en el puerto 5432 con sslmode=require:

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

El panel Connect de la consola y la respuesta de la API te entregan ambos un connection_uri_pooled junto al connection_uri directo.

El pooler funciona en modo de agrupación por transacción (un sidecar de PgBouncer por cómputo). Eso es ideal para muchas conexiones de corta duración — funciones serverless, runtimes edge, agentes — donde cada transacción puede tomar prestada una conexión de servidor y devolverla de inmediato.

Usa la conexión directa (sin agrupar, :5432) en su lugar cuando necesites:

• LISTEN / NOTIFY.
• Bloqueos consultivos a nivel de sesión.
• SET de sesión / GUCs que deban sobrevivir a una sola transacción.
• Sentencias preparadas del lado del servidor.

El connection_uri directo siempre está disponible y nunca se elimina, así que estos siguen funcionando exactamente como antes. Un pool del lado del cliente (PgBouncer o el pool integrado de tu controlador) delante de la conexión directa también sigue siendo válido.

Excluye un endpoint del pooling con el campo pooler_enabled: false en el momento de la creación o mediante PATCH /v1/endpoints/{endpointId}. El predeterminado es true.

Múltiples endpoints

Puedes generar múltiples endpoints en la misma rama. Comparten almacenamiento pero tienen límites de conexión y cachés independientes. Úsalos para aislar:

• Tráfico de app vs. analítica.
• Réplicas de lectura (cualquier endpoint en una rama es esencialmente una réplica de lectura si no escribes en él).
• Endpoints por entorno en ramas de desarrollo.