Strings de conexão
Formato, TLS, regras de role e senha para endpoints do Kisenon.
Todo endpoint do Kisenon expõe uma URI postgresql:// padrão:
postgresql://<role>:<pwd>@<endpoint_id>.<region>.kisenon.com:5432/<database>?sslmode=requireComponentes
| Campo | Significado |
|---|---|
<role> | Um role Postgres criado no branch. O card do endpoint mostra o role app auto-criado; você pode criar mais via SQL. |
<pwd> | A senha do role. Exposta uma vez na criação; rotacione via SQL. |
<endpoint_id> | Estável por endpoint, ex. ep_4f3c12a9b8e6. Roteado por SNI. |
<region> | O slug de região do seu projeto — usc1 hoje (US Central, GCP). Derivado, não fixado no código; veja Regiões. |
kisenon.com | O apex do data plane. Roteia via TLS SNI para o seu endpoint. |
5432 | Porta padrão do Postgres. |
<database> | Padrão main; crie mais com CREATE DATABASE. |
?sslmode=require | TLS é obrigatório. verify-full também funciona e é recomendado. |
TLS
Endpoints terminam TLS com um certificado Let's Encrypt para
*.<region>.kisenon.com. Clientes Postgres padrão verificam contra o trust store
do sistema; nenhuma CA customizada é necessária.
sslmode=verify-full é recomendado para código de produção. Ele verifica a
cadeia de certificados e o hostname.
Como o proxy roteia para o seu endpoint
O proxy do data plane decide a qual endpoint uma conexão pertence a partir de dois sinais, em ordem:
- A startup option
neon.endpoint_id, se o cliente enviar uma. - O hostname SNI do TLS (
<endpoint_id>.<region>.kisenon.com) como fallback.
O campo de username não é consultado para roteamento — escolha qualquer role que o seu branch defina. Strings de conexão geradas pelo console carregam o endpoint no hostname, então elas roteiam via SNI automaticamente e você não precisa configurar nada extra.
Passe neon.endpoint_id explicitamente apenas quando o seu cliente não puder apresentar
o endpoint no SNI — por exemplo uma stack TLS que não envia uma extensão Server
Name, ou um túnel que reescreve o host. A maioria dos drivers Postgres
envia SNI por padrão, então isso raramente é necessário.
Pooling de conexões
O pooling está em GA e ligado por padrão — todo endpoint tem um host pooled ao lado do direto (desde 2026-07-18).
O host pooled é <endpoint_id>-pooler.<region>.kisenon.com — o mesmo
endpoint, com -pooler inserido no rótulo do host — na porta 5432
com sslmode=require:
postgresql://<role>:<pwd>@<endpoint_id>-pooler.<region>.kisenon.com:5432/<database>?sslmode=requireO painel Connect do console e a resposta da API ambos lhe entregam um
connection_uri_pooled ao lado do connection_uri direto.
O pooler roda em modo de transaction pooling (um sidecar PgBouncer por compute). Isso é ideal para muitas conexões de vida curta — funções serverless, runtimes de edge, agentes — onde cada transação pode pegar emprestada uma conexão de servidor e devolvê-la imediatamente.
Use a conexão direta (não pooled :5432) quando você precisar de:
LISTEN/NOTIFY.- Locks de aviso no nível de sessão.
SETde sessão / GUCs que devem sobreviver a uma única transação.- Prepared statements do lado do servidor.
O connection_uri direto está sempre disponível e nunca é removido, então
esses continuam funcionando exatamente como antes. Um pool do lado do cliente (PgBouncer ou
o pool embutido do seu driver) à frente da conexão direta também
permanece válido.
Opte por retirar um endpoint do pooling com o campo pooler_enabled: false no
momento da criação ou via PATCH /v1/endpoints/{endpointId}. O padrão é
true.
Múltiplos endpoints
Você pode criar múltiplos endpoints no mesmo branch. Eles compartilham storage mas têm limites de conexão e caches independentes. Use-os para isolar:
- Tráfego de app vs analytics.
- Réplicas de leitura (qualquer endpoint em um branch é essencialmente uma réplica de leitura se você não escrever nele).
- Endpoints por ambiente em branches de dev.