전체 글

PlanetScale Neki 플랫폼 프리뷰 공개, Postgres 샤딩과 온라인 리샤딩

xXfacebook페이스북

PlanetScale이 2026년 9월 10일 Neki를 공개했습니다. 이 제품은 Postgres 데이터베이스를 여러 머신에 나눠 담는 샤딩을 서비스 안에 넣습니다. 정식 출시가 아니라 platform preview 단계입니다. 발표문의 첫 문장은 Neki is now available in platform preview. 입니다. 문서도 같은 상태를 Beta Features로 분류해 밝힙니다.

프리뷰 기간의 제약이 먼저입니다. 발표문은 프리뷰 동안 프로덕션 워크로드를 Neki에 올리지 말라고 적습니다. 제품이 계속 바뀌며 그중 일부는 파괴적 변경이 될 것이라고 예고합니다. 문서 쪽은 platform-preview-limitations에서 Beta Features에 적용되는 제한과 면책을 그대로 받습니다. 어떤 서비스 수준 계약으로도 커버되지 않는다고 명시합니다.

이 글의 독자는 단일 Postgres의 쓰기와 용량 한계에 다다라 샤딩을 검토하던 개발자입니다. Neki는 앱이 쓰는 표준 Postgres 프로토콜을 그대로 받는 라우터를 두고 리샤딩까지 온라인 워크플로로 묶어 둔 것이 핵심입니다. 이하 내용은 발표문과 공식 문서에 적힌 것을 정리한 것입니다. 클러스터를 직접 만들어 확인한 내용은 아닙니다.

Neki가 푸는 문제 — Postgres를 여러 머신으로

샤딩은 하나의 테이블에 담긴 행을 키 값을 기준으로 여러 머신에 나눠 담는 방식입니다. 데이터가 한 머신의 쓰기 처리량과 저장 용량에 묶이는 지점이 오면 머신을 키우거나 데이터를 나눠야 합니다. 발표문이 정의하는 Neki는 sharded Postgres from PlanetScale 로, 데이터베이스를 여러 머신으로 확장하면서 모든 샤드에 실제 Postgres를 유지합니다.

이 일을 처음 하는 팀도 아닙니다. 발표문은 Neki가 세계 최대급 샤딩 MySQL 클러스터를 8년간 운영하며 얻은 교훈으로 만들어졌다고 씁니다. 그 경험을 초당 수백만 쿼리를 처리하는 수천 개의 프로덕션 워크로드로 꼽습니다. 제품 페이지는 Neki를 Vitess를 만들고 유지보수하는 팀의 샤딩 Postgres라고 소개합니다. 다만 Neki vs Vitess 문서는 반대쪽도 분명히 밝힙니다. Neki is not Vitess with MySQL swapped for Postgres 라는 문장입니다. Vitess 설계의 상당 부분이 MySQL에 종속적이며 Neki는 비슷한 역할을 Postgres 의미론에 맞춰 라우팅과 클러스터 운영을 구현한 것이라고 설명합니다. 두 원문을 함께 옮기면 이렇게 정리됩니다. 계보는 같지만 파생품이라고 쓰기엔 근거가 부족합니다.

샤딩이 필요해지기 전에도 얻는 것이 있습니다. 발표문은 샤딩을 시작하기 전 단계에서 개선된 커넥션 풀링, 온라인 DDL, zero downtime upgrades, 헬스 모니터링을 얻는다고 적습니다. 임포트 가이드도 처음에는 샤드 하나짜리 샤딩 없는 데이터 토폴로지를 그대로 유지하고 샤딩 전환은 임포트가 끝난 뒤 Reshard 워크플로로 하도록 안내합니다.

라우터 아키텍처 — 표준 프로토콜, 실제 Postgres 샤드

접속 방식부터가 이 제품의 전제를 보여줍니다. 애플리케이션은 표준 Postgres 와이어 프로토콜로 라우터에 접속합니다. 발표문 표현 그대로 기존 드라이버, ORM, 접속 문자열이 계속 동작합니다. connecting 문서는 psql 이나 표준 Postgres 드라이버 무엇으로든 연결할 수 있고 모든 접속이 5432 포트를 쓴다고 적습니다. __neki.target 을 지정하는 방법도 세 가지가 문서에 있습니다: SET __neki.target = 'replica' 를 쓰거나 접속 환경변수 PGOPTIONS='-c __neki.target=REPLICA' 를 두거나 접속 URI의 options 파라미터로 지정합니다.

라우터는 문서 정의로 접속을 받아 각 문장을 어느 샤드가 실행할지 정하는 서비스입니다. 발표문은 여기에 Postgres 쿼리 파서와 분산 쿼리 플래너, 쿼리 버퍼링이 들어 있다고 적습니다. 쿼리를 파싱하고 어느 샤드가 실행할지 정하는 플랜을 만들고 일을 보내고 결과를 하나의 스트림으로 합쳐 돌려준다는 것입니다. 라우터는 수직·수평으로 모두 확장되기 때문에 특정 라우터가 병목이 되지 않는다고 합니다.

병합은 query-planning 문서가 좀 더 구체적으로 적어 둔 부분입니다. 부분 합계를 합치거나 샤드를 넘나드는 정렬과 limit을 적용하거나 조인을 마저 완성할 수 있다고 합니다. 다만 제약이 하나 붙습니다. ORDER BY 가 없는 쿼리에는 샤드를 넘나드는 행 순서 보장이 없습니다.

라우터가 쿼리를 어디로 보내는지는 같은 문서가 세 가지 라우트로 표기합니다.

라우트 표기 문서의 설명
Route [EqualUnique] 샤드 하나로 좁히는 라우팅 선택
Route [IN] 목록에 적힌 값을 가진 샤드들로 쿼리를 좁힌다
Route [Scatter] 모든 샤드에 접촉해야 하는 scatter-gather 쿼리

문서는 빈번한 쿼리의 scatter-gather 실행을 피하라고 경고합니다. 자원 사용률을 올린다는 이유입니다. 같은 쿼리가 어느 라우트로 떨어지는지가 이 구조에서 비용을 가르는 지점이라는 뜻입니다.

샤드 쪽 구성이 두 번째 전제입니다. 각 샤드는 완전한 Postgres 클러스터로 primary 1개와 replica 2개 이상으로 이루어져 3개 가용 영역에 분산됩니다. replica는 Postgres 물리 복제로 primary의 변경을 따라가는 읽기 전용 인스턴스입니다. 커스텀 스토리지 엔진은 없고 확장·SQL 지원·성능이 Postgres가 동작하는 방식 그대로라는 것이 발표문의 반복 문구입니다. 한편 overview 문서는 라우터가 클러스터마다 최소 3개, 3개 가용 영역에 놓인다고 적습니다. 샤드당 노드 수와 라우터 수는 별개의 수치라 섞어 읽지 않아야 합니다.

구성 요소 문서의 수치
샤드 하나 primary 1 + replica 2 이상 — Postgres 노드 최소 3
샤드 배치 가용 영역 3개에 분산
라우터 클러스터당 최소 3개, 가용 영역 3개 분산
Neki 아키텍처를 왼쪽에서 오른쪽으로 보여주는 그림. 애플리케이션이 표준 Postgres 와이어 프로토콜 5432 포트로 라우터에 접속하고, 라우터는 클러스터당 최소 3개가 가용 영역 3개에 놓여 Postgres 쿼리 파서와 분산 쿼리 플래너로 샤드를 정해 일을 보낸 뒤 결과를 한 스트림으로 합쳐 돌려주며, 오른쪽의 각 샤드는 primary 1개와 replica 2개 이상으로 이루어진 실제 Postgres 클러스터로 가용 영역 3개에 분산되어 있다.
라우터는 최소 3개가 가용 영역 3개에 놓이고, 각 샤드는 primary 1 + replica 2 이상의 실제 Postgres 클러스터다.
## 데이터 토폴로지 — 샤드 키 선택과 테이블 매핑

무엇을 어디에 나눌지는 데이터 토폴로지가 정합니다. 발표문의 정의로는 논리 테이블을 물리 샤드에 매핑하는 JSON 구성입니다. 여기에 샤드 인덱스(어떤 컬럼으로 라우팅하고 그 값을 어떻게 해시할지)와 샤드 그룹(테이블 묶음을 몇 개 샤드에 펼치고 어느 샤드인지)을 정의합니다. 라우터는 이 토폴로지를 캐시하고 플랜을 세울 때마다 참조합니다. data-topology 문서는 이를 document 라 부르며 네 종류의 객체를 선언한다고 적습니다. 용어집은 데이터 토폴로지를 Neki의 라우팅 지도 — 샤드 그룹, 샤드 인덱스, 키 범위, 테이블 바인딩, 범위별 소유 샤드를 정의하는 것 — 라고 풀어 씁니다.

샤드 인덱스는 테이블의 샤드 키를 라우팅 키로 바꾸는 이름 붙은 라우팅 함수입니다. 해시 타입의 정확한 함수는 XXH3-64 라고 문서가 적습니다. 타입은 xxhash, modulo, range 세 종류입니다. 기본값과 테이블별 오버라이드를 해석하고 나면 columns 목록에는 정확히 하나의 컬럼이 들어 있어야 합니다.

샤드 그룹은 이름 붙은 키 범위 배치입니다. 키 범위의 목록이고 각 범위가 샤드 하나를 가리키며 테이블은 샤드 그룹에 붙습니다. 문서가 보여주는 JSON의 뼈대는 이렇습니다.

{
  "authoritative_shard_group": "authoritative",
  "shard_indexes": {
    "xxhash_tenant_id": { "type": "xxhash", "columns": ["tenant_id"] }
  },
  "shard_groups": [{
    "uid": "tenant_data",
    "default_shard_index": "xxhash_tenant_id",
    "key_ranges": [
      { "shard_uid": "shard-a", "end": "40" },
      { "shard_uid": "shard-b", "start": "40", "end": "80" }
    ]
  }],
  "tables": { "events": { "shard_group": "tenant_data" } }
}

여기에 보조 개념이 더 있습니다. reference table은 같은 논리 행들의 사본을 여러 샤드 그룹에 저장하는 테이블입니다. GSI(global secondary index, 전역 보조 인덱스)는 다른 키를 소유 행의 샤드 키로 연결하는 룩업 테이블입니다. authoritative 샤드 그룹은 정규 Postgres OID와 스키마 이벤트를 제공하며 전체 keyspace를 포괄하는 단일 키 범위를 갖습니다.

토폴로지를 다루는 경로는 세 가지입니다. 대시보드의 Clusters > Data topology 에서 JSON 문서를 보고 편집하거나 pscale branch data-topology get <DATABASE> <BRANCH> --org <ORGANIZATION> 으로 가져오고 pscale branch data-topology update <DATABASE> <BRANCH> --format json < data-topology.json 으로 갱신하거나 SQL 메타함수 __neki.set_data_topology 를 쓰는 것입니다. 갱신이 모든 곳에 보이기를 기다릴 때는 __neki.wait_for_data_topology(<revision>) 를 씁니다. 데이터 토폴로지의 매핑과 라우팅을 보여주는 그림. 논리 테이블 events가 shard_group 지정으로 샤드 그룹 tenant_data에 붙고, 샤드 그룹의 키 범위가 end 40의 shard-a와 start 40·end 80의 shard-b를 가리키며, 아래 샤드 인덱스 xxhash_tenant_id는 tenant_id 컬럼을 XXH3-64 해시로 라우팅 키로 바꾼다. 토폴로지는 논리 테이블을 물리 샤드에 매핑하는 JSON 문서이고, 라우터가 이를 캐시해 매 플랜에서 참조한다.

내장 워크플로 — 스키마 변경부터 리샤딩까지

운영에서 가장 아픈 작업들을 제품이 워크플로로 묶어 둡니다. 발표문의 문장은 이렇습니다: Schema changes, version upgrades, failovers, imports, and resharding all run as built-in fully online workflows. 같은 내용을 다른 문장에서는 계획된 페일오버와 비계획 페일오버까지 포함해 다시 열거합니다. 이 워크플로들을 조율하는 것은 컨트롤 플레인입니다. 모든 노드의 상태를 추적하며 계획된 스위치오버와 비계획 페일오버를 실행합니다.

워크플로의 뼈대는 서로 같습니다. 새 대상 노드를 프로비저닝하고 복제로 따라잡히기를 기다리고 __neki 메타함수로 트래픽을 전환하고 이전 노드를 폐기합니다. 발표문은 이 모든 것이 애플리케이션이 쓰는 같은 psql 접속으로 이루어진다고 적습니다. 워크플로의 공통 패턴을 네 단계 타임라인으로 보여주는 그림. 새 대상 노드를 프로비저닝하고, 복제로 따라잡히기를 기다리고, __neki 메타함수로 트래픽을 전환한 뒤, 이전 노드를 폐기하는 순서가 왼쪽에서 오른쪽으로 이어지고, 이 전체가 애플리케이션이 쓰는 같은 psql 접속으로 진행된다고 아래에 표시되어 있다. 전환이 진행되는 동안 Neki는 영향을 받는 쿼리를 버퍼에 쌓고, 옮기는 테이블에 대한 소스의 새 쓰기를 막고, 이미 받아들인 변경이 대상에 도달하기를 기다린다.

트래픽 전환 함수와 되돌리기

data-migration 문서의 전환 함수는 세 개입니다. __neki.workflow_switch_reads(workflow) 는 읽기를, __neki.workflow_switch_writes(workflow, options) 는 쓰기를, __neki.workflow_switch_traffic(workflow, options) 는 읽기와 쓰기를 함께 옮깁니다. 전환은 단계적으로 진행됩니다. primary가 아닌 읽기(replica와 rdonly)를 먼저 옮기고 primary 읽기와 쓰기는 소스에 남깁니다. 전환이 진행되는 동안 Neki는 영향을 받는 쿼리를 버퍼에 쌓습니다. 옮기는 대상 테이블에 대한 소스의 새 쓰기를 막고 이미 받아들인 변경이 대상에 도달하기를 기다립니다.

마무리와 취소는 __neki.workflow_complete(workflow, options) 와 __neki.workflow_cancel(workflow, options) 입니다. 권한은 나뉘어 있습니다: 값을 바꾸는 함수에는 neki_operator, 상태와 보고 함수에는 neki_viewer 가 필요합니다. 여기에 실전용 경고가 붙습니다. 쓰기가 옮겨간 뒤 소스로 트래픽을 되돌리는 것은 문서화된 프리뷰 롤백 경로가 아닙니다. 그리고 트래픽이 옮겨진 뒤에는 Cancel을 쓸 수 없습니다.

온라인 DDL

스키마 변경은 그림자 테이블을 만드는 것부터 시작합니다. 라이브 테이블 옆에 그림자 테이블을 만들고 기존 행을 배치로 복사합니다. 진행 중인 insert·update·delete를 그림자 테이블로 스트리밍합니다. 영향을 받는 테이블에 대한 새 쿼리를 라우터에 버퍼링시킨 뒤 전환합니다. 제어는 전용 메타함수가 맡습니다: __neki.online_ddl_create(name, database, ddl, migration_id) 로 시작하고 __neki.online_ddl_status(workflow) 로 진행을 보며 __neki.online_ddl_cleanup(workflow) 으로 정리합니다. 완료 대기는 __neki.wait_for_ddl(schema_version, cluster_version) 이 담당합니다.

온라인 경로가 맡는 작업은 문서가 열거합니다: 컬럼 추가·삭제, 컬럼 타입 변경, 제약 조건 추가·삭제, 인덱스 추가. CREATE INDEX 와 DROP INDEX 도 온라인 경로를 쓰지만 이때 CONCURRENTLY 를 포함하지 말라고 못박습니다. CREATE TABLE, DROP TABLE 같은 문장은 직접 경로로 가서 모든 관리 샤드에 전달됩니다. 온라인 경로를 쓰지 않고 강제로 직접 실행하려면 다섯 번째 인수로 {"applyDirect": true} 를 넘깁니다. 완료의 의미도 정확히 읽어야 합니다. 각 샤드가 자체 Postgres 트랜잭션으로 커밋하며 완료는 조율되지만 하나의 원자적 트랜잭션은 아닙니다.

리샤딩

리샤딩은 Reshard 워크플로가 맡습니다. 문서 정의로는 한 소스 샤드 그룹에 선언된 테이블들을 새 샤드 그룹으로 재분배하는 것입니다. __neki.reshard_create(...) 로 만들어 __neki.workflow_start 로 시작합니다. 두 방향 분할이라면 새 샤드 2개를 추가하고 각 목적지 샤드에 준비된 primary가 생길 때까지 기다립니다. 동작은 리샤딩답게 온라인입니다. 기존 행을 복사하면서 새 쓰기가 들어오면 대상을 계속 갱신하고 소스는 트래픽이 대상으로 넘어갈 때까지 서비스를 계속합니다.

여기서 붙는 제약 두 개가 실무에서 걸립니다. 첫째, 토폴로지 업데이트는 부분 수정이 아니라 완전 교체입니다. 소스 그룹으로 해석되는 모든 물리 base 테이블을 선언해야 합니다. 둘째, Reshard는 테이블 식별자를 그대로 유지하기 때문에 소스 테이블 이름을 바꿀 수 없습니다. 그리고 MoveTables와 Reshard는 PlanetScale 대시보드에서 관리되지 않고 별도 CLI 워크플로도 없습니다.

임포트

기존 데이터를 옮기는 길은 프리뷰 중에는 수동뿐입니다. 임포트 문서는 pg_dump 로 커스텀 포맷 덤프를 만들고 pg_restore 로 새 Neki 데이터베이스에 복원하는 절차를 안내합니다. 소스의 쓰기를 중단하고 덤프를 뜨고 복원하고 검증한 뒤 애플리케이션 트래픽을 옮깁니다. 자동화된 Neki 임포트는 프리뷰 기간에 제공되지 않는다고 명시합니다.

이 경로가 오프라인이라는 것도 문서의 문장 그대로입니다. 소스 애플리케이션은 덤프 전에 쓰기를 멈추고 검증과 전환이 끝날 때까지 멈춰 있어야 합니다. 그리고 pg_restore 는 토폴로지를 인식하는 샤딩 임포트 워크플로가 아니므로 임포트는 샤드 하나짜리 샤딩 없는 토폴로지로 받고 샤딩 전환은 임포트 후 Reshard로 합니다.

장애 조치와 버전 업그레이드

primary가 죽었을 때의 동작은 replicas 문서가 이렇게 적습니다: Neki는 적격 replica를 승격하고 샤드 토폴로지를 갱신할 수 있으며 페일오버 동안에는 쿼리나 접속이 잠깐 끊길 수 있습니다. 유지보수 창의 절차는 반대 방향입니다. 고가용성 샤드에서는 primary 유지보수 전에 계획된 스위치오버를 수행합니다. replica가 따라잡기를 기다린 뒤 승격하므로 이전 primary의 커밋이 보존됩니다. 그래도 유지보수가 활성 접속을 끊을 수 있으므로 애플리케이션은 자동으로 재접속해야 한다고 같은 문서는 덧붙입니다.

여기서 발표문과 문서의 온도차가 하나 보입니다. 발표문의 표현은 zero downtime upgrades 이지만 유지보수 문서는 접속이 끊길 수 있다고 씁니다. 무중단을 단정하려면 그것이 발표문의 표현이라는 점을 함께 적어야 합니다. 버전 업그레이드를 단계별로 다루는 Neki 전용 문서는 아직 없습니다. 유지보수 문서는 설정된 메이저 버전 안에서의 Postgres minor 버전 업데이트만 말합니다. 구성 프로필 문서에는 선택 가능한 버전 번호 목록이 없고, 메이저 버전을 바꾸는 절차도 문서화돼 있지 않습니다. 다만 Cloudflare Workers 가이드는 Neki가 Postgres 18로 식별된다고 밝힙니다.

프리뷰 단계의 제한과 확인된 사실

프리뷰 상태의 의미를 다시 모읍니다. 발표문은 프리뷰 동안 프로덕션 워크로드를 돌리지 말 것과 파괴적 변경 가능성을 밝힙니다. 문서는 Beta Features의 제한과 면책을 받으며 어떤 서비스 수준 계약으로도 커버되지 않는다고 적습니다. 구성의 자유도도 좁습니다. 단일 노드, 고가용성 아닌 구성은 프리뷰에서 지원되지 않아 샤드는 최소 3노드 구성이 됩니다.

가입은 조직 관리자가 합니다. 퀵스타트는 PlanetScale 조직의 관리자가 먼저 Neki Platform Preview에 합류해야 한다고 안내합니다. 동의 절차 자체는 퀵스타트가 아니라 Neki 문서에 있고, 조직 대시보드의 Organization settings > Platform Preview 에서 약관에 동의하는 것입니다. 발표문의 요약도 같은 순서입니다: PlanetScale에 로그인하고 platform preview에 옵트인하고 Neki 클러스터를 만듭니다.

프리뷰 기간의 수치 제한은 cluster-configuration 문서에 적혀 있습니다. 조직은 한 Neki 클러스터에서 샤드 최대 16개, 총 51개 클러스터 노드까지 쓸 수 있습니다. 이는 기본 한도이며 조직별로 다를 수 있습니다.

항목 기본 한도·상태 근거
프로덕션 워크로드 금지 — 파괴적 변경 예고 발표문
SLA 적용되지 않음 platform-preview-limitations
샤드 수 기본 최대 16개 cluster-configuration
클러스터 노드 기본 총 51개 cluster-configuration
단일 노드(비고가용성) 구성 미지원 platform-preview-limitations

라우터가 받지 않는 SQL과 객체는 platform-preview-limitations 문서에 목록으로 공개돼 있습니다. 전부가 아니라 읽고 넘어갈 만한 것들을 옮기면 이렇습니다.

  • SELECT ... INTO
  • 애플리케이션 테이블을 대상으로 플랜을 세워야 하는 INTERSECT와 EXCEPT — UNION은 지원됩니다
  • COMMIT AND CHAIN, ROLLBACK AND CHAIN
  • 데이터베이스를 넘나드는 객체 참조
  • 자식 테이블이 있는 상속 부모를 ONLY 없이 읽기
  • pg_temp를 포함하는 search_path
  • COPY — simple query protocol만 허용되고 쿼리에서 유일한 문장이어야 합니다. extended query protocol의 COPY는 거부되고 COPY TO는 샤딩 없는 테이블만 지원하며 COPY FROM PROGRAM, COPY TO PROGRAM, COPY (SELECT ...) TO, WHERE 절이 붙은 COPY FROM은 거부됩니다
  • 사용자 정의 텍스트 검색 구성·사전 생성, tablespace 생성·이동, Postgres large objects, 커스텀 핸들러 절차 언어, LOAD로 공유 라이브러리 적재
  • 외부에서 관리되는 Postgres 소스를 Neki 마이그레이션 워크플로에 연결 — 프리뷰에서 미지원

트랜잭션 제약은 이 목록과 별도로 기억할 가치가 있습니다. 크로스 샤드 트랜잭션은 모든 샤드에 걸친 원자적 커밋을 제공하지 않고 원자적 분산 트랜잭션 모드는 지원되지 않습니다. query-planning 문서에는 Neki commits each shard separately. It does not use two-phase commit to make every shard succeed or fail together 라는 문장이 있습니다. 각 샤드를 따로 커밋하고, 모든 샤드를 함께 성공시키거나 함께 실패시키는 2단계 커밋을 쓰지 않는다는 것입니다. 샤딩이 트랜잭션 문제를 대신 풀어 주는 것은 아닙니다.

확장 목록도 문서에 명시돼 있습니다. 항상 활성인 5종과 사용자가 설정할 수 있는 12종입니다.

분류 확장 (버전)
항상 활성 5종 neki_xxhash (0.4), pg_pscale_utils, pgextwlist, pginsights, plpgsql (1.0)
설정 가능 12종 citext (1.8), cube (1.5), fuzzystrmatch (1.2), hstore (1.8), intarray (1.5), ltree (1.3), pg_trgm (1.6), pgcrypto (1.4), unaccent (1.1), uuid-ossp (1.1), vector·pgvector (0.8.6), vectorscale (0.9.0)

문서가 붙이는 조건 두 개는 이렇습니다. Neki는 확장을 활성화해도 Postgres가 단일 노드에서 받아들이는 모든 함수·캐스트·크로스 샤드 쿼리 형태를 구현하지 않을 수 있습니다. 그리고 구성 프로필에 확장을 켜는 것과 데이터베이스 객체를 설치하는 것은 별개 동작입니다.

가격은 이 글에서 오해하기 쉬운 부분입니다. 발표문 본문에는 가격 언급이 없습니다. 발표 페이지 상단 배너의 from $5/month 는 Neki 가격이 아니라 일반 광고 문구라서 그대로 인용하면 틀립니다. 가격 문서 자체는 존재하고 종량 구조를 공개합니다. 클러스터 SKU는 샤드마다 한 번 적용되고 인스턴스 크기를 기준으로 밀리초 단위로 일할 계산됩니다. 라우터 컴퓨트는 라우터 크기와 개수를 기준으로 밀리초 단위로 계산됩니다. 문서의 예시 단가(AWS us-east-1 기준)는 스토리지 GB당 $0.125, IOPS 개당 $0.009, 처리량 MiB/s당 $0.073, 백업 초과분 GB당 월 $0.023, 프라이빗 트래픽 GB당 $0.01 입니다. SKU 가격은 클라우드 제공자와 리전, 조직의 상업 조건에 따라 달라지므로 현재 요금은 대시보드 추정이나 요금 계산기로 확인하라고 같은 문서가 안내합니다. 프리뷰 과금에 대해 확인된 문장은 한 문장입니다: Admin is not billed during Platform Preview (cluster-sizing 문서). 프리뷰가 전체적으로 무료인지 유료인지는 이 자료들로는 판단할 수 없습니다.

지금 단계에서 할 수 있는 일은 이 정도입니다. 조직 관리자가 프리뷰에 가입해 클러스터를 만들고 비프로덕션 데이터로 접속과 워크플로를 돌려 보는 것입니다. 확인해 볼 지점도 문서가 미리 좁혀 줍니다: 접속이 표준 프로토콜이라 기존 드라이버와 접속 문자열이 그대로 되는지, 쓰고 있는 SQL이 거부 목록과 겹치지 않는지(INTERSECT·EXCEPT, COPY 형태, 크로스 샤드 트랜잭션의 원자성 요구), 기존 데이터는 pg_dump와 pg_restore의 오프라인 경로로만 들어온다는 것. 프리뷰가 언제 정식으로 바뀌는지는 이 글이 근거로 삼은 자료들에는 적혀 있지 않습니다. 프리뷰 제한을 네 칸과 두 줄 주석으로 정리한 그림. 프로덕션 워크로드 금지와 SLA 미적용, 조직당 샤드 최대 16개와 클러스터 노드 총 51개 한도, SELECT INTO와 INTERSECT·EXCEPT 등 SQL 거부 항목, 단일 노드 비고가용성 구성 미지원이 각 칸에 있고, 아래 주석에는 크로스 샤드 트랜잭션이 원자적 커밋이 아니라는 점과 자동 임포트가 없다는 점이 적혀 있다. 프리뷰 중에는 단일 노드 비고가용성 구성도 지원되지 않아 샤드는 최소 3노드 구성이 된다.

근거와 참고

Published Sep 11, 2026

이 글 공유하기xXfacebook페이스북

긱뉴스에서 고른 소식을 읽고 정리합니다.