仙kisenon

연결 문자열

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). 하드코딩되지 않고 파생됩니다; Regions를 참조하세요.
kisenon.com데이터 플레인 정점. TLS SNI를 통해 엔드포인트로 라우팅됩니다.
5432표준 Postgres 포트.
<database>기본값 main; CREATE DATABASE로 더 만드세요.
?sslmode=requireTLS는 필수입니다. 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, Djangosslmode=verify-full&sslrootcert=system (아래 바이너리 wheel 참조)
Node.js: pg, Drizzle, postgres.jssslmode=verify-full
Prisma 6 및 7sslmode=verify-full&sslaccept=strict
Go: pgx v5.7.0 이상, lib/pq v1.12.0 이상sslmode=verify-full&sslrootcert=system
Go: 그보다 오래된 pgx 또는 lib/pqsslmode=verify-full
Java: JDBC, Springsslmode=verify-full&sslfactory=org.postgresql.ssl.DefaultJavaSSLFactory
.NET: Npgsql, EF CoreSSL 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 pg gem)에서 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 신뢰 저장소를 사용합니다.

프록시가 엔드포인트로 라우팅하는 방식

데이터 플레인 프록시는 두 가지 신호로부터 연결이 어느 엔드포인트에 속하는지 순서대로 결정합니다:

  1. 클라이언트가 보내는 경우, neon.endpoint_id startup 옵션.
  2. 폴백으로서 TLS SNI 호스트명(<endpoint_id>.<region>.kisenon.com).

라우팅에는 사용자명 필드가 참조되지 않습니다 — 브랜치가 정의하는 아무 역할이나 고르세요. 콘솔이 생성한 연결 문자열은 호스트명에 엔드포인트를 담고 있으므로 SNI를 통해 자동으로 라우팅되며, 추가로 설정할 것이 없습니다.

neon.endpoint_id를 명시적으로 전달하는 것은 클라이언트가 SNI에 엔드포인트를 제시할 수 없을 때뿐입니다 — 예를 들어 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입니다.

다중 엔드포인트

같은 브랜치에 여러 엔드포인트를 띄울 수 있습니다. 이들은 스토리지를 공유하지만 독립적인 연결 한도와 캐시를 가집니다. 다음을 격리하는 데 사용하세요:

  • 앱 대 분석 트래픽.
  • 읽기 복제본(브랜치의 어떤 엔드포인트든 쓰기를 하지 않으면 본질적으로 읽기 복제본입니다).
  • 개발 브랜치의 환경별 엔드포인트.

개념

브랜치, 엔드포인트, 0으로 스케일 — Kisenon 뒤에 있는 모델.

서버리스 / 엣지 드라이버

수정하지 않은 @neondatabase/serverless 드라이버를 HTTP와 WebSocket을 통해 Kisenon에 사용합니다.

이 페이지에서

구성 요소TLS서버 인증서 검증프록시가 엔드포인트로 라우팅하는 방식연결 풀링다중 엔드포인트
연결 문자열 · Kisenon