LabHub

블로그

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

2026-05-15 · 34 분 읽기 · #database#distributed-sql#newsql#cockroachdb#tidb#yugabytedb#spanner#aurora-dsql#alloydb#citus#vitess#planetscale#neon#xata#postgresql#deep-dive

한국어English日本語

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

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

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

이 세 가지를 같은 "분산 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부터는 자체 호스팅 옵션을 쓰려면 엔터프라이즈 계약이 필요해졌다.

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

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

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)에서 그 두 가지가 다듬어졌다.

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년 좌표는 두 가지로 정리된다.

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

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

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

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

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

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은 다음을 추가했다.

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

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

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

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

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가 강한 자리:

Vitess가 약한 자리:

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

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

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

PlanetScale의 2026년 좌표:

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

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

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

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

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

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

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

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

Xata의 매력은 두 가지다.

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

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

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

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

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

참고 / References

원문 보기: https://www.youngju.dev/blog/culture/2026-05-15-distributed-sql-newsql-2026-cockroachdb-tidb-yugabytedb-spanner-aurora-dsql-neon-deep-dive

댓글

아직 댓글이 없습니다.

로그인하면 댓글을 쓸 수 있습니다