Chaos and Order

💡 왼쪽 원문을 읽으면서 오른쪽에 따라 써보세요. Tab 키로 힌트를 받을 수 있습니다.

원문 렌더가 준비되기 전까지 텍스트 가이드로 표시합니다.

프롤로그 — "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년에 흔한 패턴이다.

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

| 축 | 기본 가정 | 잃는 것 | 얻는 것 |

| --- | --- | --- | --- |

이 세 가정 중 어느 것이 자기 워크로드에 맞는지 결정하지 않은 채 도구를 비교하면 답이 나오지 않는다. 그래서 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

- CockroachDB 라이선스 변경 공지 — https://www.cockroachlabs.com/blog/enterprise-license/

- CockroachDB v24 릴리스 노트 — https://www.cockroachlabs.com/docs/releases/

- TiDB 8.x 릴리스 — https://docs.pingcap.com/tidb/stable/release-notes

- TiDB HTAP 아키텍처 — https://docs.pingcap.com/tidb/stable/explore-htap

- YugabyteDB 문서 — https://docs.yugabyte.com/

- Google Spanner 공식 — https://cloud.google.com/spanner

- Spanner: TrueTime 논문(OSDI 2012) — https://research.google/pubs/pub39966/

- Aurora DSQL GA 발표(re:Invent 2024) — https://aws.amazon.com/blogs/aws/aurora-dsql-generally-available/

- AlloyDB for PostgreSQL — https://cloud.google.com/alloydb

- AlloyDB Omni — https://cloud.google.com/alloydb/docs/omni/introduction

- Azure Cosmos DB for PostgreSQL(Citus) — https://learn.microsoft.com/azure/cosmos-db/postgresql/

- Citus OSS — https://github.com/citusdata/citus

- Vitess — https://vitess.io/

- PlanetScale Postgres + Metal — https://planetscale.com/blog/announcing-planetscale-postgres

- Neon 공식 — https://neon.tech/

- Databricks의 Neon 인수 발표 — https://www.databricks.com/blog/databricks-neon

- Xata 문서 — https://xata.io/docs

- Raft 논문(Ongaro & Ousterhout, 2014) — https://raft.github.io/raft.pdf

- Spanner 논문(Corbett et al., OSDI 2012) — https://research.google/pubs/pub39966/

- CAP에서 PACELC로(Daniel Abadi) — http://www.cs.umd.edu/~abadi/papers/abadi-pacelc.pdf