接続文字列
Kisenon エンドポイントの形式、TLS、ロールとパスワードのルール。
すべての Kisenon エンドポイントは、標準的な postgresql:// URI を公開します。
postgresql://<role>:<pwd>@<endpoint_id>.<region>.kisenon.com:5432/<database>?sslmode=require構成要素
| フィールド | 意味 |
|---|---|
<role> | ブランチ上に作成された Postgres ロール。エンドポイントカードには自動作成された app ロールが表示されます。SQL で追加できます。 |
<pwd> | ロールのパスワード。作成時に一度だけ表示されます。SQL でローテーションします。 |
<endpoint_id> | エンドポイントごとに安定（例 5e0c7d1a-8b2f-4e36-9a41-c7d2e8f03b15）。SNI でルーティングされます。 |
<region> | プロジェクトのリージョンスラッグ — 現在は usc1（米国中部、GCP）。ハードコードではなく導出されます。リージョン を参照してください。 |
kisenon.com | データプレーンの apex。TLS SNI 経由でエンドポイントにルーティングします。 |
5432 | 標準の Postgres ポート。 |
<database> | デフォルトは main。CREATE DATABASE で追加します。 |
?sslmode=require | TLS は必須。require は暗号化しますが、ほとんどのドライバーはこのモードではサーバー証明書をチェックしません。サーバー証明書の検証 を参照してください。 |
TLS
エンドポイントは *.<region>.kisenon.com 向けの Let's Encrypt 証明書で TLS を終端するため、
カスタム CA は不要です。
Kisenon が発行する接続文字列（コンソールの Connection string 形式、keon connection-string、
API）は sslmode=require を使います。接続は暗号化されますが、require ではほとんどの
ドライバーがサーバー証明書をチェックしません。すべてのドライバーが受け付ける唯一の値である
ため、これをデフォルトとしています。
サーバー証明書の検証
ドライバーに証明書チェーン と ホスト名の両方をチェックさせるには、ドライバーごとの パラメーターを使ってください。コンソールのドライバー別の形式は、すでにこれを使っています。
| ドライバー | パラメーター |
|---|---|
psql などの libpq ツール（libpq 16 以上） | sslmode=verify-full&sslrootcert=system |
| Python: psycopg 3、psycopg2、SQLAlchemy、Django | sslmode=verify-full&sslrootcert=system（下記のバイナリ wheel を参照） |
Node.js: pg、Drizzle、postgres.js | sslmode=verify-full |
| Prisma 6 および 7 | sslmode=verify-full&sslaccept=strict |
| Go: pgx v5.7.0 以上、lib/pq v1.12.0 以上 | sslmode=verify-full&sslrootcert=system |
| Go: それより古い pgx または lib/pq | sslmode=verify-full |
| Java: JDBC、Spring | sslmode=verify-full&sslfactory=org.postgresql.ssl.DefaultJavaSSLFactory |
| .NET: Npgsql、EF Core | SSL Mode=VerifyFull |
@kisenon/serverless | 追加は不要です。HTTPS/WebSocket で接続し、sslmode は無視します。 |
つまずきやすい点:
- 16 より古い libpq は
sslrootcert=systemを理解しません。その場合は意図的な フォールバックとしてsslmode=requireを使ってください。暗号化はされますが、検証はされません。 - Node.js のドライバーに
sslrootcert=systemを渡さないでください。pg（およびそれを使う Prisma 7）はsystemという名前のファイルを読もうとして失敗します。postgres.js はこれを サーバーに送り、サーバーが接続を拒否します。 - Python のバイナリ wheel（
psycopg[binary]、psycopg2-binary）は独自の OpenSSL を同梱して おり、そのシステムトラストストアは空です。そのためsslrootcert=systemはcertificate verify failedで失敗します。SSL_CERT_FILEで OS のバンドルを指定してください。 Debian/Ubuntu ではSSL_CERT_FILE=/etc/ssl/certs/ca-certificates.crtです。パスは他のシステムでは 異なります。 - Windows には PEM 形式の信頼ストアがないため、libpq ベースのクライアント
（
psql、psycopg、Ruby のpggem）ではsslrootcert=systemがcertificate verify failedで失敗します。代わりにsslrootcertに CA バンドルファイルを指定してください。 Python では certifi を使います:pip install certifiのうえsslrootcert=certifi.where()（どの OS でも動くため、コンソールの Python 形式はこれを使っています）。psqlや Rails ではhttps://curl.se/ca/cacert.pemから Mozilla のバンドルをダウンロードし、そのパスを渡します:sslrootcert=C:\certs\cacert.pem。 - Prisma 6 は、
sslmodeの値にかかわらず、sslaccept=strictを設定しない限り証明書を チェックしません。 - postgres.js は
sslmode=requireでは証明書をチェックしません。 - JDBC は
sslmode=verify-fullだけだと~/.postgresql/root.crtを探します。sslfactory=org.postgresql.ssl.DefaultJavaSSLFactoryを指定すると、代わりに JVM のトラストストアを使います。
プロキシがエンドポイントへルーティングする仕組み
データプレーンのプロキシは、2 つのシグナルから、接続がどのエンドポイントに属するかを順番 に判断します。
- クライアントが送る場合は、
neon.endpoint_idの スタートアップオプション。 - フォールバックとして、TLS の SNI ホスト名（
<endpoint_id>.<region>.kisenon.com）。
ルーティングにユーザー名フィールドは 参照されません — ブランチが定義する任意のロールを 選んでください。コンソールが生成する接続文字列はホスト名にエンドポイントを含むので、自動 的に SNI 経由でルーティングされ、追加で何かを設定する必要はありません。
クライアントが SNI でエンドポイントを提示できない場合にのみ、neon.endpoint_id を明示的
に渡してください — 例えば Server Name 拡張を送らない TLS スタックや、ホストを書き換える
トンネルなどです。ほとんどの Postgres ドライバはデフォルトで SNI を送るので、これが必要に
なることはまれです。
接続プーリング
プーリングは GA でデフォルトオン です — すべてのエンドポイントは、直接ホストと並んで プール化ホストを持ちます（2026-07-18 以降）。
プール化ホストは <endpoint_id>-pooler.<region>.kisenon.com です — 同じエンドポイントで、
ホストラベルに -pooler が挿入されたもの — ポート 5432 で sslmode=require を使用します。
postgresql://<role>:<pwd>@<endpoint_id>-pooler.<region>.kisenon.com:5432/<database>?sslmode=requireコンソールの Connect パネルと API レスポンスはどちらも、直接の connection_uri と並んで
connection_uri_pooled を渡します。
プーラーは トランザクションプーリング モード（コンピュートごとの PgBouncer サイドカー） で動作します。これは、各トランザクションがサーバー接続を借りてすぐに返せる、多数の短命な 接続 — サーバーレス関数、エッジランタイム、エージェント — に理想的です。
代わりに直接（プール化されていない :5432）接続を使うべきなのは、次が必要な場合です。
LISTEN/NOTIFY。- セッションレベルのアドバイザリロック。
- 単一のトランザクションを超えて存続する必要のあるセッションの
SET/ GUC。 - サーバー側のプリペアドステートメント。
直接の connection_uri は常に利用可能で、決して削除されないので、これらは以前とまったく
同じように動作し続けます。直接接続の前段に置くクライアント側プール（PgBouncer やドライバ
組み込みのプール）も引き続き有効です。
エンドポイントをプーリングから除外するには、作成時に pooler_enabled: false フィールドを
使うか、PATCH /v1/endpoints/{endpointId} を使用します。デフォルトは true です。
複数のエンドポイント
同じブランチ上に複数のエンドポイントを生成できます。それらはストレージを共有しますが、接続 制限とキャッシュは独立しています。次の用途で分離するのに使えます。
- アプリと分析のトラフィック。
- 読み取りレプリカ（ブランチ上の任意のエンドポイントは、書き込まなければ本質的に読み取り レプリカです）。
- 開発ブランチ上の環境ごとのエンドポイント。