Skip to content
Published on

분산 SQL / NewSQL 2026 — CockroachDB / TiDB / YugabyteDB / Spanner / Aurora DSQL / Neon 심층 비교

🇰🇷KO🇺🇸EN🇯🇵JA
Split View필사 모드
Authors

프롤로그 — "NewSQL"이라는 단어가 더 이상 묶지 못하는 풍경

2012년에 처음 NewSQL이라는 단어가 등장했을 때, 그 정의는 단순했다. OLTP 워크로드를 NoSQL 수준으로 수평 확장하면서도 ACID와 SQL을 유지하는 데이터베이스. Spanner 논문이 2012년에 나왔고, CockroachDB와 TiDB가 그 직후에 시작됐다. 그때는 후보가 손에 꼽혔고, 다들 비슷한 약속을 했다 — "샤드 매뉴얼 관리를 끝내겠다."

2026년의 풍경은 그 단어 하나로 묶기 어렵다. 이제 분산 SQL은 최소 세 갈래로 갈라져 있다.

  • True distributed (셰어드 낫싱 + 합의 알고리즘): CockroachDB, TiDB, YugabyteDB, Spanner, Aurora DSQL — 모든 노드가 동등하고, Raft 또는 Paxos로 합의하며, 리전을 가로지른다.
  • Sharded SQL (오케스트레이션 레이어): Vitess(MySQL), Citus(Postgres), PlanetScale Metal — 노드는 여전히 일반 MySQL/Postgres지만 그 위에 라우터·코디네이터가 있다.
  • Serverless Postgres (스토리지·컴퓨트 분리): Neon, Aurora Serverless v2, Xata — 한 인스턴스가 분산되는 게 아니라 스토리지가 별도의 분산 시스템이고 컴퓨트는 켰다 끄는 모델.

이 세 가지를 같은 "분산 SQL"이라는 우산 아래 놓고 비교하면 거의 모든 비교가 의미를 잃는다. Aurora DSQL과 Neon은 둘 다 Postgres 호환이지만, 전자는 멀티 리전 활성-활성 OLTP를 지향하고 후자는 단일 리전에서 컴퓨트를 0으로 줄이는 것을 지향한다. CockroachDB와 PlanetScale은 둘 다 "수평 확장 SQL"이라고 마케팅되지만, 한쪽은 합의 알고리즘 위에서 모든 트랜잭션을 조정하고 다른 한쪽은 샤드 키로 미리 나눠 둔다.

이 글은 그 12개의 시스템을 같은 표 안에 우겨넣지 않는다. 대신 각각이 무엇을 우선했는지를 한 줄로 정리하고, 합의 알고리즘·MVCC·하이브리드 논리 시계·온라인 스키마 변경이라는 공통 어휘로 비교한 뒤, 마지막에 "글로벌 / SaaS 멀티테넌트 / HTAP / 서버리스"라는 네 가지 사용처별로 누가 무엇을 골라야 하는지까지 적는다.

1장 · 2026년의 분산 SQL 지도 — 세 축으로 나누기

먼저 한 장의 그림.

                    [SQL을 수평 확장한다]
                            |
        +-------------------+-------------------+
        |                   |                   |
[True Distributed]    [Sharded SQL]      [Serverless Postgres]
   합의 알고리즘         외부 코디네이터       스토리지·컴퓨트 분리
        |                   |                   |
   CockroachDB 24       Vitess               Neon (Databricks)
   TiDB 8               Citus / Cosmos PG    Aurora Serverless v2
   YugabyteDB           PlanetScale (Metal)  Xata
   Google Spanner
   Aurora DSQL (GA)
   AlloyDB Omni

이 그림이 책 한 권 분량을 한 페이지로 압축한다. 같은 축 안의 시스템들은 서로 직접적인 대안이지만, 다른 축의 시스템과는 보통 대안이 아니라 공존한다 — 예를 들어 한 SaaS가 Neon을 메인 OLTP로, CockroachDB를 글로벌 메타데이터 저장소로 같이 쓰는 것은 2026년에 흔한 패턴이다.

축마다 다음과 같은 가정이 깔려 있다.

축기본 가정잃는 것얻는 것
True distributed모든 트랜잭션은 합의 알고리즘으로 조정한다단일 리전 OLTP의 극한 latency멀티 리전 활성-활성, 자동 리밸런싱
Sharded SQL샤드 키를 잘 골랐다면 합의는 필요 없다크로스 샤드 트랜잭션의 단순함단일 노드 OLTP latency를 유지
Serverless Postgres컴퓨트는 작고 자주 켰다 꺼진다멀티 리전 쓰기분 단위 비용, 빠른 브랜칭

이 세 가정 중 어느 것이 자기 워크로드에 맞는지 결정하지 않은 채 도구를 비교하면 답이 나오지 않는다. 그래서 1장은 이 표 한 장으로 끝낸다.

2장 · CockroachDB 24 — 라이선스 변경 이후의 좌표

CockroachDB는 2024년 8월에 가장 큰 외부 사건을 겪었다. Cockroach Labs가 BSL(Business Source License)에서 한 발 더 나아가, 모든 신규 릴리스를 사실상 프로프라이어터리(소스 사용 가능, 상업 사용 제한)로 전환했다. 기존 v23.x까지의 Apache 2.0 코드는 그대로지만, v24부터는 자체 호스팅 옵션을 쓰려면 엔터프라이즈 계약이 필요해졌다.

이 변경은 두 가지 효과를 낳았다.

  • 클라우드 매니지드(Cockroach Cloud) 사용자에게는 거의 영향이 없다. 가격은 약간 조정됐지만 기능은 그대로다.
  • 자체 호스팅 OSS 사용자는 v23.x에 남거나 다른 길을 찾았다. 일부는 YugabyteDB(Apache 2.0 유지)로, 일부는 Postgres + Citus로, 일부는 그대로 v23.x에 머물렀다.

라이선스 논쟁을 빼고 보면 v24의 기술적 변화도 작지 않다.

  • PostgreSQL 17 와이어 호환 강화. Cockroach는 처음부터 Postgres 와이어 프로토콜을 쓰지만, v24에서 시퀀스·트리거·CTE·확장 함수 호환이 한층 좁아졌다.
  • Multi-region이 더 단순해졌다. ALTER DATABASE ... PRIMARY REGION = 'aws-us-east-1' 같은 한 줄로 리전 정책을 설정한다.
  • Vector 자료형 추가. pgvector 호환 인덱스가 v24.1에 들어왔다. RAG 워크로드를 Cockroach 안에서 처리하는 패턴이 늘었다.
  • Logical Data Replication. v24.2부터 두 클러스터 간 양방향 활성-활성 복제가 베타로 들어왔다.

CockroachDB의 핵심 자산은 여전히 Raft 기반 합의로 멀티 리전 쓰기를 자동으로 처리한다는 점이다. 한 키의 모든 쓰기는 그 키의 Raft 그룹 리더에게 라우팅되고, 리더는 과반수 리플리카에 로그를 복제한 뒤 커밋한다. 멀티 리전 클러스터에서 리더 위치를 어떻게 배치하느냐가 latency를 결정한다 — REGIONAL BY ROW는 행마다 홈 리전을 다르게 두고, GLOBAL 테이블은 모든 리전에서 빠르게 읽힌다.

-- 멀티 리전 테이블 예시
CREATE DATABASE app PRIMARY REGION 'aws-us-east-1'
  REGIONS 'aws-us-east-1', 'aws-eu-west-1', 'aws-ap-northeast-1';

ALTER TABLE app.users SET LOCALITY REGIONAL BY ROW;
ALTER TABLE app.products SET LOCALITY GLOBAL;

CockroachDB가 잘하는 자리는 분명하다: 멀티 리전 OLTP, 강한 일관성, 자동 페일오버. 못하는 자리도 분명하다: 단일 리전 단일 노드 워크로드에서는 그냥 Postgres가 더 빠르고 싸다.

3장 · TiDB 8 (PingCAP) — HTAP를 실전으로 끌어내린 곳

TiDB는 처음부터 두 가지를 노렸다. MySQL 와이어 호환 + 행/열 저장소 동시 운영. 8.x 시리즈(2024-2025)에서 그 두 가지가 다듬어졌다.

  • TiKV(행 저장소) + TiFlash(컬럼 저장소) 가 같은 Raft 그룹의 학습자(learner) 리플리카로 묶인다. 같은 트랜잭션이 OLTP와 OLAP 두 쪽 모두에서 일관된 스냅샷으로 보인다.
  • Pinterest, Square, Shopee 가 페타바이트 단위로 운영 중인 사례를 공개했다. Pinterest는 광고 메트릭 워크로드를, Shopee는 e-commerce 주문/재고를, Square는 결제 분석을 TiDB에 올렸다.
  • TiDB Serverless(2024 출시, 2025 정식 GA) 는 사용량 기반 과금과 자동 스케일링을 가져왔다. 신규 SaaS가 진입할 때 가장 자주 거론되는 옵션이다.
  • HTAP 쿼리 라우팅 은 옵티마이저가 자동으로 처리한다. SELECT COUNT(*)처럼 집계가 크면 TiFlash로, 단건 조회는 TiKV로 보낸다.

TiDB의 아키텍처는 세 층으로 나뉜다.

+----------+   +-------+   +--------+
| TiDB SQL |-->|  PD   |-->|  TiKV  |  (행 저장, Raft)
+----------+   |(Meta) |   +--------+
                 |             |
                 v             v
              ratchet     +---------+
                          | TiFlash | (컬럼 저장, Raft learner)
                          +---------+

PD(Placement Driver)가 메타데이터·리전 매핑·리더 선출을 담당하고, TiKV가 데이터를 키 범위로 자른 리전 단위로 저장하며, TiFlash가 같은 데이터의 컬럼 사본을 학습자 리플리카로 들고 있다. SQL 노드는 stateless라서 자유롭게 추가/제거된다.

MySQL 와이어 호환은 5.7 수준에서 시작했다가 8.x로 올라왔다. 이름이 같다고 100% 호환은 아니다 — 트리거, 외래키 제약(부분 지원), 일부 스토어드 프로시저는 다른 동작을 보일 수 있다.

TiDB가 잘하는 자리: MySQL 호환이 필요한 SaaS, HTAP가 필요한 워크로드, 페타바이트급 수평 확장. 단점은 운영 복잡도(세 종류 노드를 관리)와 RAM 요구량.

4장 · YugabyteDB — Postgres 호환 분산의 단단한 한 자리

YugabyteDB는 두 개의 API를 가졌다. YSQL(PostgreSQL 와이어 + Postgres 코드를 일부 차용) 과 YCQL(Cassandra 와이어 호환). 실전에서는 거의 YSQL이 쓰인다.

설계상 결정적인 차이는 Postgres의 쿼리 레이어 코드를 거의 그대로 재사용한다는 점이다. CockroachDB는 처음부터 Go로 새로 짰지만, YugabyteDB는 Postgres 코드를 분산 스토리지(DocDB) 위에 얹는 길을 택했다. 그 덕에 확장 함수, 트리거, 스토어드 프로시저 호환이 상당히 높다 — Postgres에서 돌던 백엔드 코드를 옮길 때 마찰이 작은 편이다.

DocDB는 RocksDB + Raft 조합으로, CockroachDB의 스토리지 엔진과 개념적으로 비슷하지만 키 인코딩과 트랜잭션 매니저가 다르다. Hybrid Logical Clock(HLC) 로 멀티 리전 트랜잭션 순서를 결정한다.

YugabyteDB의 2026년 좌표는 두 가지로 정리된다.

  • CockroachDB의 라이선스 이탈 수혜자. v2.20 이후 Apache 2.0 유지가 명시적으로 마케팅 포인트가 됐다. 자체 호스팅을 원하는 OSS 진영의 일부가 옮겨왔다.
  • Postgres 호환이 진짜 호환이라는 평판. Django, Rails, Hibernate 등 ORM 호환이 비교적 매끄럽다.

YugabyteDB가 잘하는 자리: Postgres 호환을 유지하면서 글로벌 분산이 필요한 워크로드, Apache 2.0이 중요한 자체 호스팅. 약한 자리: 쿼리 옵티마이저가 분산 환경에서 항상 최선의 계획을 내는 것은 아니라서 큰 조인을 튜닝해야 할 일이 적지 않다.

5장 · Google Spanner — 외부 일관성의 챔피언

Spanner는 다른 모든 분산 SQL의 기준점이다. 2012년 OSDI 논문이 나온 이래 14년이 지났고, 그 핵심 자산은 여전히 외부 일관성(external consistency) 이다. 모든 트랜잭션은 글로벌하게 합의된 타임스탬프를 받고, 전 세계 어디서 읽어도 그 타임스탬프 이후의 트랜잭션만 보인다.

이 보장을 가능하게 하는 것이 TrueTime API 다. GPS와 원자 시계를 기반으로, Google 데이터센터의 모든 노드가 "현재 시각이 이 구간 안에 있다"는 좁은 불확실성 구간(보통 7ms 이하)을 안다. 트랜잭션은 이 구간이 지나가기를 기다린 뒤 커밋되고, 그 결과 시계 동기화 가정 없이도 글로벌 순서를 보장한다.

2026년의 Spanner는 다음 변화를 거쳤다.

  • PostgreSQL 인터페이스가 정식 GA 후 폭넓게 채택됐다. 처음 Spanner SQL이 자체 방언이었던 시절을 넘어, 이제 PostgreSQL 와이어로 접근할 수 있다.
  • Spanner Graph(2024 출시) 가 SQL 안에서 그래프 쿼리를 지원한다. GRAPH_QUERY 구문이 ISO GQL을 따른다.
  • Vector search 통합. Vertex AI 임베딩을 그대로 색인할 수 있게 됐다.
  • Spanner Data Boost — 서버리스 분석 컴퓨트가 OLTP에 영향을 주지 않고 큰 집계를 처리한다.

Spanner의 약점은 오랫동안 변하지 않았다. 싸지 않다. 최소 노드 비용이 다른 OLTP DB와 비교가 안 되고, 트래픽이 적은 SaaS에서는 Cloud SQL이 훨씬 합리적이다. 또 GCP 외부에서는 쓸 수 없다.

Spanner가 잘하는 자리: 글로벌 SaaS, 외부 일관성이 비즈니스 요구사항인 금융/거래 시스템, 한 곳의 장애가 다른 곳을 멈추면 안 되는 도메인.

6장 · Aurora DSQL (2024.12 GA) — AWS의 분산 SQL 답안지

Aurora DSQL은 2024년 re:Invent에서 GA가 발표됐다. PostgreSQL 호환 + 멀티 리전 활성-활성 + 서버리스. 이 세 단어가 동시에 들어간 AWS의 첫 응답이었다.

설계상의 핵심은 트랜잭션을 region quorum이 아니라 글로벌 quorum에 commit한다는 점이다. Aurora 일반판은 한 리전 안에서 6개 사본(3 AZ × 2)을 유지하지만, DSQL은 여러 리전이 함께 트랜잭션을 결정한다.

다음은 단순화된 DSQL 트랜잭션의 흐름이다.

1) 클라이언트 → 가까운 리전의 endpoint에 BEGIN
2) 쿼리들은 로컬에서 OCC(낙관적 동시성)로 실행
3) COMMIT 시점에 글로벌 timestamp 서비스가 순서를 결정
4) Storage 레이어에 그 timestamp로 기록
5) 모든 리전이 같은 순서로 본다

OCC 기반이라는 점이 중요하다. 충돌이 일어나면 한쪽이 retry해야 한다. 모든 쓰기가 같은 행을 노리는 워크로드는 잘 맞지 않는다. 반대로 충돌이 드물고 멀티 리전 활성-활성이 진짜로 필요한 워크로드에는 강력한 선택이다.

2025-2026 사이 DSQL은 다음을 추가했다.

  • 3 리전 클러스터 정식 지원 (처음 GA는 2 리전).
  • IAM 인증 + Secrets Manager 통합.
  • CDC를 통한 Kinesis Data Streams 출력.
  • Aurora PostgreSQL과의 데이터 마이그레이션 도구.

DSQL이 잘하는 자리: AWS 안에서 멀티 리전 활성-활성 OLTP, Postgres 호환, 운영 자동화가 우선인 팀. 못하는 자리: 핫 키 쓰기, OCC 충돌이 많은 패턴, Postgres의 모든 확장(특히 PL/Python 같은 서버 사이드 코드)이 필요한 경우.

7장 · AlloyDB (Google) — Postgres + 분석을 단일 리전 안에서

AlloyDB는 Spanner와 같은 자리에 서지 않는다. 단일 리전 안에서 Postgres를 빠르게 + 분석을 같이. 글로벌 분산을 추구하지 않는다. 대신 Google이 내부적으로 갈고닦은 스토리지 레이어(Disaggregated storage)와 컬럼 엔진(Columnar engine)을 Postgres와 결합한다.

AlloyDB의 차별점은 다음과 같다.

  • Postgres 100% 호환. 확장, 트리거, 함수 모두 그대로 돌아간다.
  • Columnar engine. 같은 데이터를 메모리에 컬럼으로도 들고 있어, 집계 쿼리가 표준 Postgres 대비 수십 배 빠르다.
  • AlloyDB Omni. 같은 엔진을 GCP 밖(온프레미스, 다른 클라우드)에서도 돌릴 수 있는 컨테이너 배포 버전.
  • AlloyDB AI(2024 출시) — pgvector + Vertex AI 임베딩을 같은 트랜잭션 안에서 호출한다.

AlloyDB가 잘하는 자리: 단일 리전 안에서 Postgres OLTP + 가벼운 OLAP를 같이 하는 워크로드, GCP에 이미 들어가 있고 Spanner는 과한 경우. 못하는 자리: 멀티 리전 활성-활성, 다른 클라우드의 매니지드 옵션.

8장 · Citus / Azure Cosmos for Postgres — 샤딩 Postgres의 정도(正道)

Citus는 2011년에 시작해서 2019년에 Microsoft에 인수됐고, 2022년에 Azure Cosmos DB for PostgreSQL 로 이름이 바뀌었다. 하지만 OSS 버전(Citus extension)은 Apache 2.0으로 계속 살아 있고, 그냥 Postgres에 CREATE EXTENSION citus만 해도 동작한다.

Citus의 모델은 단순하다. 분산 테이블(distributed table)과 참조 테이블(reference table).

-- 분산 테이블: tenant_id를 샤드 키로 나눈다
SELECT create_distributed_table('users', 'tenant_id');

-- 참조 테이블: 모든 노드에 복제된다
SELECT create_reference_table('countries');

각 워커 노드는 그냥 평범한 Postgres다. 코디네이터 노드가 쿼리를 받아 샤드 키에 따라 워커로 라우팅한다. 같은 샤드 키의 행은 같은 워커에 모여 있으므로, 단일 테넌트 트랜잭션은 단일 노드 트랜잭션이 된다 — 이게 SaaS 멀티테넌트에 Citus가 잘 맞는 이유다.

Citus가 못하는 것도 분명하다. 샤드 키를 가로지르는 트랜잭션은 2PC(2-phase commit)에 기댄다. 글로벌 자동 페일오버는 없다 — 그건 호스트가 알아서 한다. 멀티 리전 활성-활성도 아니다.

Citus가 잘하는 자리: SaaS 멀티테넌트(tenant_id로 자연스럽게 샤드), 시계열 데이터(시간 컬럼으로 샤드), 단일 리전 안에서 Postgres를 100TB 이상으로 확장.

9장 · Vitess — MySQL 샤딩의 표준이 되어 살아남다

Vitess는 YouTube에서 시작했다. 2010년대 중반에 CNCF에 들어갔고, MySQL을 수십 PB로 확장한 실전 사례가 많다 — Slack, Square, GitHub의 일부 데이터셋이 Vitess 위에 있다.

Vitess의 모델은 Citus와 비슷하지만 MySQL이라는 점이 다르다.

[Client] → [VTGate] → [VTTablet] → [MySQL shard]
              |           |
       (라우터/QP)    (관리 daemon)

VTGate가 SQL을 받고, VSchema(샤딩 규칙)에 따라 적절한 VTTablet으로 보낸다. 각 VTTablet은 한 개의 MySQL 인스턴스를 감싸고 백업·복제·페일오버를 관리한다.

Vitess가 강한 자리:

  • 수평 확장 MySQL. 한 클러스터에서 수만 개의 샤드를 운영한 사례가 공개돼 있다.
  • 온라인 스키마 변경. gh-ost/pt-online-schema-change와 통합된 워크플로우.
  • CNCF 거버넌스. 단일 회사 종속이 없다.

Vitess가 약한 자리:

  • 일반 MySQL 사용자가 처음 마주하면 운영 복잡도가 높다.
  • 크로스 샤드 트랜잭션은 가능하지만 비싸다.
  • MySQL이 아닌 워크로드에는 의미가 없다.

10장 · PlanetScale — Vitess에서 Postgres/Metal로 (2024)

PlanetScale은 2018년에 Vitess를 매니지드 서비스로 포장하면서 시작했다. 2021-2023년 사이에 "브랜치를 만들고 배포 직전에 merge한다"는 워크플로우로 개발자 인지도를 끌어올렸다. 그리고 2024년에 큰 두 가지를 바꿨다.

  • 무료 티어 폐지(2024년 4월). 가격 정책이 바뀌면서 작은 사이드 프로젝트는 다른 곳으로 옮겼다. 이 사건이 Neon·Supabase·Turso 같은 대안의 채택을 가속했다.
  • PlanetScale Postgres + Metal 발표(2024년 후반). MySQL 샤딩 전문이라는 이미지에서 벗어나, Postgres + 베어메탈 NVMe라는 새 노선을 추가했다.

Metal은 흥미로운 결정이다. NVMe로 직결된 베어메탈 인스턴스에서 Postgres를 돌리고, 백업·복제를 PlanetScale이 관리한다. AWS Aurora처럼 스토리지를 분리하지 않고, 로컬 디스크의 IOPS를 그대로 쓴다. 단일 인스턴스 OLTP 성능에서 Aurora/RDS를 압도하는 벤치마크가 공개됐다.

PlanetScale의 2026년 좌표:

  • MySQL/Vitess — 여전히 메인 제품. 큰 고객들은 그대로 있다.
  • PostgreSQL/Metal — 신규 고객을 받기 위한 두 번째 트랙. 단일 인스턴스에서 매우 빠른 Postgres가 필요한 자리에서 강하다.
  • 개발자 워크플로우(브랜칭, deploy request) 가 양쪽 트랙에 공통으로 깔린다.

11장 · Neon — Postgres 서버리스 + Databricks 인수 (2025)

Neon은 Postgres를 두 부분으로 쪼갰다. 컴퓨트(EC2 같은 stateless Postgres 프로세스)와 스토리지(자체 분산 페이지 서버). 컴퓨트는 켰다 꺼지고, 스토리지는 S3에 페이지를 영속화한다.

이 분리의 결과는 세 가지다.

  • 0으로 줄어드는 컴퓨트. 트래픽이 없으면 컴퓨트가 멈추고 비용이 0이 된다. 다시 요청이 오면 1-2초 안에 깨어난다.
  • 즉시 브랜칭. 같은 페이지를 copy-on-write로 공유하므로, 100GB 데이터베이스의 브랜치를 1초 안에 만든다.
  • 타임머신. 페이지 히스토리가 보존되므로, 과거 시점으로 데이터베이스를 복원할 수 있다(point-in-time restore가 분 단위가 아니라 초 단위).

2025년 5월에 Databricks가 Neon을 약 10억 달러에 인수했다. 이 인수의 명시적 이유는 AI 에이전트가 자기 작업용으로 즉석에서 만드는 데이터베이스 — 즉, "에이전트 1만 개가 각자 자기 Postgres 브랜치를 만든다"는 시나리오에서 Neon의 브랜칭 모델이 압도적이라는 판단이었다.

인수 이후 Neon은 다음을 추가했다.

  • Neon Auth. 인증/RBAC를 빌트인으로.
  • Postgres 17 지원.
  • MCP 서버 통합. Claude/Cursor 같은 AI 코딩 도구에서 Neon 인스턴스를 직접 만들고 쿼리한다.
  • Databricks Lakebase와의 통합 — Lakehouse 데이터를 Postgres 인터페이스로 접근.

Neon이 잘하는 자리: 개발/스테이징 환경의 브랜칭, 트래픽이 들쑥날쑥한 워크로드, AI 에이전트의 격리된 작업 공간. 못하는 자리: 멀티 리전 활성-활성 쓰기, 한 인스턴스를 24/7 풀로 돌리는 거대 OLTP(이 경우는 일반 Aurora/RDS가 더 싸다).

12장 · Xata — Postgres + search + files를 한 인터페이스로

Xata는 다른 카테고리에 속한다. 그것은 Postgres + 검색(Elasticsearch 호환) + 파일 첨부를 하나의 데이터 모델 안에 묶는 백엔드 플랫폼이다. 2024년부터는 호스팅 Postgres 자체도 매니지드로 제공한다.

Xata의 매력은 두 가지다.

  • REST/SDK 우선. Postgres 와이어로도 접근 가능하지만, 1차 인터페이스는 TypeScript SDK다.
  • 검색이 일급 시민. 같은 테이블에 풀텍스트 색인이 자동으로 생성되고, fuzzy/typo-tolerant 검색이 SQL과 같은 인터페이스로 노출된다.
  • 파일 컬럼. S3에 저장되지만 SQL 컬럼처럼 보인다.

Xata가 잘하는 자리: 빠르게 MVP를 띄우는 풀스택 앱, 검색이 필요한 카탈로그/CMS, 백엔드 코드를 최소화하고 싶은 프론트엔드 팀. 못하는 자리: 거대 OLTP, 복잡한 트랜잭션, 멀티 리전 분산.

13장 · Raft / Paxos / MVCC / HLC — 한 줄씩 설명

여기까지의 시스템들을 같은 어휘로 비교하려면 네 가지 개념을 알아야 한다.

1) Raft / Paxos (합의 알고리즘)

복수의 노드가 같은 로그 순서에 동의하기 위한 프로토콜. Paxos는 1989년에 제안된 원형이고 증명이 까다롭다. Raft는 2014년에 단순함을 우선해 재설계됐고, 그 결과 거의 모든 NewSQL이 Raft를 쓴다(CockroachDB, TiDB의 TiKV, YugabyteDB의 DocDB). Spanner는 변형된 Multi-Paxos를 쓴다.

한 줄 요약: 데이터를 키 범위로 자르고, 각 범위마다 3-5개의 리플리카가 Raft 그룹을 이뤄 리더를 뽑고 로그를 합의한다.

2) MVCC (Multi-Version Concurrency Control)

읽기와 쓰기가 락으로 서로를 막지 않게 하기 위해, 모든 행이 여러 버전을 동시에 갖는다. 트랜잭션은 시작 시점의 타임스탬프 이전 버전만 본다. Postgres가 1990년대부터 써온 모델이고, CockroachDB/Spanner/TiDB 모두 MVCC를 한다.

3) HLC (Hybrid Logical Clock)

물리 시계와 논리 시계를 합친 시계. 노드 간 시계가 약간 어긋나도, 인과 관계가 있는 이벤트의 순서를 보장한다. CockroachDB와 YugabyteDB가 트랜잭션 타임스탬프 결정에 HLC를 쓴다. Spanner는 HLC 대신 TrueTime을 쓴다 — 물리 시계의 불확실성 구간을 직접 추정한다.

4) Online Schema Change

기본 Postgres/MySQL에서 큰 테이블에 컬럼을 추가하는 것은 락을 잡고 모든 행을 재작성하는 비싼 작업이다. 분산 SQL은 보통 이중 쓰기 + 점진적 백필 패턴으로 이를 해결한다 — TiDB의 ALTER TABLE은 동기 락 없이 끝나고, CockroachDB도 마찬가지, Vitess의 gh-ost 통합도 같은 아이디어다.

14장 · 누가 무엇을 골라야 하나 — 사용처 4종

지금까지 12개 시스템을 다뤘다. 마지막 장은 네 가지 사용처별로 누가 우선 후보인지 정리한다. 정답은 없고, 우선 후보가 있을 뿐이다.

A) 글로벌 SaaS / 멀티 리전 활성-활성 OLTP

  • 1순위: Google Spanner(GCP에 있으면), Aurora DSQL(AWS에 있으면), CockroachDB(클라우드 중립).
  • 가산점: 외부 일관성이 비즈니스 요구사항이면 Spanner.
  • 주의: 모두 비싸다. 트래픽이 작은데 멀티 리전이 필요해 보이면, 한 번 더 의심하라.

B) SaaS 멀티테넌트 (tenant_id로 자연스럽게 샤드)

  • 1순위: Citus / Azure Cosmos for Postgres, PlanetScale(Vitess/MySQL 또는 Metal/Postgres).
  • 가산점: Postgres 확장을 많이 쓰면 Citus, MySQL 생태계가 익숙하면 Vitess/PlanetScale.
  • 대안: TiDB도 가능. 단일 노드 + 읽기 복제로 시작하는 것도 한참 동안 충분하다는 점을 잊지 마라.

C) HTAP (OLTP + 가벼운 OLAP 같은 인터페이스로)

  • 1순위: TiDB(TiKV + TiFlash), AlloyDB(컬럼 엔진).
  • 가산점: MySQL 호환이면 TiDB, Postgres 호환이면 AlloyDB.
  • 대안: 무거운 분석은 Snowflake/BigQuery/Databricks를 따로 두는 게 표준 — HTAP 한 시스템에 다 욱여넣지 마라.

D) 서버리스 / 브랜칭 / 개발 환경

  • 1순위: Neon(Databricks 진영), Aurora Serverless v2(AWS), Xata(풀스택 백엔드).
  • 가산점: AI 에이전트 인프라면 Neon의 브랜칭이 압도적, AWS 안에 있고 자동 스케일이 핵심이면 Aurora Serverless v2.
  • 대안: Supabase, Turso(SQLite 기반)도 같은 자리의 후보. 워크로드가 진짜 Postgres가 필요한지 먼저 따져라.

마지막으로 한 줄: 분산 SQL은 답이 아니라 선택지다. 단일 노드 Postgres 한 대로 잘 굴러가는 워크로드가 2026년에도 여전히 가장 흔하다. 글로벌 활성-활성이 진짜로 필요한지, 단순히 "수평 확장"이라는 단어가 멋있어 보였는지 한 번 더 묻고 시작하라.

참고 / References

Discuss on Twitter • View on GitHub