Neki — PlanetScale의 샤딩 기반 Postgres 서비스

단일 머신의 한계에 도달한 Postgres를 여러 머신으로 확장하는 Neki가 플랫폼 프리뷰로 공개됨. 각 샤드에서 실제 Postgres를 실행하는 PlanetScale의 서비스임 애플리케이션은 표준 Postgres 와이어 프로토콜로 라우터에 연결하며, 기존 드라이버·ORM·연결 문자열을 그대로 사용함. 샤드 키와 JSON 데이터 토폴로지로 테이블 배치를 직접 제어할 수 있음 각 샤드는 프라이머리 1개와 최소 2개 복제본을 3개 가용 영역에 배치함. 별도 스토리지 엔진 없이 Postgres의 확장 기능·SQL 지원·성능 특성을 유지함 스키마 변경·버전 업그레이드·장애 조치·가져오기·리샤딩을 내장 온라인 워크플로로 실행함. 샤딩 없이 시작해 기존 클러스터에서 리샤딩할 수 있으며, Insights·스키마 추천·브랜칭·MCP도 제공함 플랫폼 프리뷰에서는 프로덕션 워크로드를 실행하면 안 됨. 제품이 계속 바뀌고 일부 변경은 호환성을 깨뜨릴 예정이므로, 현재는 클러스터를 시험하고 피드백을 제공하는 단계임 단일 머신의 한계를 넘기 위한 Postgres 샤딩 Neki는 PlanetScale이 8년간 대규모 샤딩 MySQL 클러스터를 운영한 경험을 바탕으로 개발한 Postgres 서비스임 수천 개의 프로덕션 워크로드와 초당 수백만 쿼리를 처리하며, 몇 초의 중단도 공개적으로 드러나는 기업들의 최상위 중요도인 티어 0 워크로드를 지원해 옴 PlanetScale Postgres 출시 후 1년 반 동안 수천 고객이 합류했고, 일부는 최대 규모 MySQL 고객에 필적하는 크기로 성장함 여러 팀이 Postgres 단일 머신의 처리 한계에 접근했으며, Metal로 시간을 벌어도 결국 단일 머신의 상한에 도달함 빠르게 성장하는 Postgres 데이터베이스에서는 운영 작업 자체가 어려워짐 큰 테이블의 vacuum이나 인덱스 작업이 트래픽에 영향을 주고, 백업에는 수시간이 걸림 연결 수 제한, 스키마 변경을 위한 점검 시간, 트랜잭션 ID 순환 문제도 발생함 더 큰 인스턴스로 옮겨도 충분히 큰 머신을 찾을 수 없는 지점에 도달하며, 코어와 IOPS를 늘린다고 문제가 선형적으로 해결되지는 않음 기존 대안에는 애플리케이션 부담과 호환성 절충이 따름 애플리케이션 수준 샤딩은 라우팅 책임을 애플리케이션 코드로 옮김 Postgres 호환 분산 데이터베이스는 샤드 키를 숨기고 확장 기능을 제한하며, 처리와 디버깅을 어렵게 하는 복잡성과 지연을 추가함 ...