接続文字列
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> | エンドポイントごとに安定(例 ep_4f3c12a9b8e6)。SNI でルーティングされます。 |
<region> | プロジェクトのリージョンスラッグ — 現在は usc1(米国中部、GCP)。ハードコードではなく導出されます。リージョン を参照してください。 |
kisenon.com | データプレーンの apex。TLS SNI 経由でエンドポイントにルーティングします。 |
5432 | 標準の Postgres ポート。 |
<database> | デフォルトは main。CREATE DATABASE で追加します。 |
?sslmode=require | TLS は必須。verify-full も動作し、推奨されます。 |
TLS
エンドポイントは *.<region>.kisenon.com 向けの Let's Encrypt 証明書で TLS を終端します。標準的な
Postgres クライアントはシステムのトラストストアに対して検証します。カスタム CA は不要です。
本番コードには sslmode=verify-full を推奨します。証明書チェーン と ホスト名の両方を
チェックします。
プロキシがエンドポイントへルーティングする仕組み
データプレーンのプロキシは、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 です。
複数のエンドポイント
同じブランチ上に複数のエンドポイントを生成できます。それらはストレージを共有しますが、接続 制限とキャッシュは独立しています。次の用途で分離するのに使えます。
- アプリと分析のトラフィック。
- 読み取りレプリカ(ブランチ上の任意のエンドポイントは、書き込まなければ本質的に読み取り レプリカです)。
- 開発ブランチ上の環境ごとのエンドポイント。