Connection strings
Format, TLS, role and password rules for Kisenon endpoints.
Every Kisenon endpoint exposes a standard postgresql:// URI:
postgresql://<role>:<pwd>@<endpoint_id>.kisenon.com:5432/<database>?sslmode=requireComponents
| Field | Meaning |
|---|---|
<role> | A Postgres role created on the branch. The endpoint card shows the auto-created app role; you can create more via SQL. |
<pwd> | The role's password. Surfaced once at creation; rotate via SQL. |
<endpoint_id> | Stable per endpoint, e.g. ep_4f3c12a9b8e6. SNI-routed. |
kisenon.com | The data-plane apex. Routes via TLS SNI to your endpoint. |
5432 | Standard Postgres port. |
<database> | Default main; create more with CREATE DATABASE. |
?sslmode=require | TLS is mandatory. verify-full also works and is recommended. |
TLS
Endpoints terminate TLS with a Let's Encrypt certificate for
*.kisenon.com. Standard Postgres clients verify against the system
trust store; no custom CA needed.
sslmode=verify-full is recommended for production code. It checks the
certificate chain and the hostname.
How the proxy routes to your endpoint
The data-plane proxy decides which endpoint a connection belongs to from two signals, in order:
- The
neon.endpoint_idstartup option, if the client sends one. - The TLS SNI hostname (
<endpoint_id>.kisenon.com) as a fallback.
The username field is not consulted for routing — pick any role your branch defines. Console-generated connection strings carry the endpoint in the hostname, so they route via SNI automatically and you don't need to set anything extra.
Pass neon.endpoint_id explicitly only when your client can't present
the endpoint in SNI — for example a TLS stack that won't send a Server
Name extension, or a tunnel that rewrites the host. Most Postgres
drivers send SNI by default, so this is rarely needed.
Pooling
Each endpoint accepts up to ~100 concurrent connections by default. For short-lived connections (serverless functions, edge runtimes), use a client-side pooler like PgBouncer or your driver's built-in pool.
A managed pooler endpoint is on the roadmap; until then, treat your endpoint as a single Postgres instance.
Multiple endpoints
You can spawn multiple endpoints on the same branch. They share storage but have independent connection limits and caches. Use them to isolate:
- App vs analytics traffic.
- Read replicas (any endpoint on a branch is essentially a read replica if you don't write to it).
- Per-environment endpoints on dev branches.