분산 데이터베이스 2025 완전 가이드 — CockroachDB·Spanner·TiDB·YugabyteDB·Aurora DSQL·Neon·PlanetScale·Turso·D1 심층 비교 (시즌 7 3화)

프롤로그 — "어느 DB 쓸까?"라는 질문이 다시 어려워진 이유

2015년쯤엔 간단했다. "관계형이면 Postgres, 속도면 MySQL, 문서면 Mongo, 캐시면 Redis." 10년이 지나 2026년 현재, "어느 DB?"를 물으면 후보가 10개 넘게 튀어나온다. Neon? Supabase? PlanetScale? CockroachDB? Spanner? TiDB? Yugabyte? Aurora DSQL? Turso? D1? 심지어 "Postgres"라고만 말해도 어떤 Postgres인지가 따로 주제가 된다.

왜 이렇게 됐나. 세 가지 힘이 동시에 움직였다.

1. 서버리스와 엣지의 보편화 — Vercel·Cloudflare·AWS Lambda 같은 단명 런타임이 주류가 되면서, "커넥션 풀을 영원히 들고 있는 DB"가 어울리지 않게 됐다. 연결 폭주와 콜드스타트가 문제.
2. 멀티리전·글로벌 유저 — 한 리전 Postgres 하나로 전 세계 유저를 감당하려니, 지연시간과 데이터 주권이 걸림돌. 분산 SQL이 "더 이상 Google만의 문제"가 아님.
3. 비용 모델 재편 — 유휴 상태에서도 벌크로 과금되는 RDS 대신, 스케일-투-제로가 가능한 서버리스 DB가 스타트업과 사이드 프로젝트의 기본값이 됐다.

이 글은 분산 SQL과 서버리스/엣지 DB가 어떻게 갈라졌고, 각자 어느 문제에 잘 맞는지를 실전 선택 기준으로 정리한다. "어느 게 제일 좋냐"가 아니라 "어느 문제엔 뭐가 맞냐"가 목표다.

1장. CAP·PACELC를 다시 읽는다

10년 전에는 "CAP 중 둘 고르기"로 끝냈지만, 2020년 이후 PACELC(Partition: A vs C / Else: Latency vs Consistency)가 더 유용한 분류 기준이 됐다. 네트워크 파티션이 발생했을 때뿐 아니라, 정상 상황에서도 지연과 일관성은 트레이드오프라는 얘기다.

"강일관성(Strict Serializable)"은 공짜가 아니다. Spanner는 TrueTime(원자시계 + GPS)으로 한 리전 내 쓰기에 수ms를 쓴다. CockroachDB는 하이브리드 논리 클럭과 커밋 대기(commit-wait)로 비슷한 속성을 만들지만, 멀티리전 쓰기는 한 왕복 + 합의 지연을 피할 수 없다. 이 지연을 수용할 수 있느냐가 분산 SQL 선택의 첫 질문이다.

실전 체크

• 쓰기 지연 P99 ≥ 100ms를 받아들일 수 있나? 없다면 단일 리전 설계가 유리.
• 강일관성 트랜잭션이 필요한 비즈니스 규칙이 몇 %인가? 잔액/재고/좌석 예약은 강일관성이 필수. 피드/통계는 아님.
• 지리적 데이터 주권(Data residency)이 있나? EU 유저 데이터는 EU 안에, 한국 금융은 국내에. 이러면 멀티리전 + 리전 피닝이 필수.

2장. 분산 SQL 3대장 — Spanner, CockroachDB, TiDB

2.1 Google Cloud Spanner

무엇인가. 구글이 2012년에 내놓고 지금도 구글 검색·애드워즈 뒤에서 돌아가는 원조 글로벌 분산 RDB. 2023년 말 Postgres 인터페이스가 GA 되면서 "Postgres 문법으로 쓰는 글로벌 DB"라는 포지션이 명확해졌다.

특징.

• TrueTime으로 외부 일관성(External Consistency) 보장.
• 멀티리전 쓰기를 기본 제공. "US + EU + Asia 동시 쓰기 후 강일관성 읽기"가 버튼 하나.
• 2024년 Spanner Graph, Full-text Search 추가 — "Spanner 하나로 OLTP+검색+그래프"를 노리는 흐름.
• 비용이 비싸다. 최소 노드 규모가 있고 스토리지 단가도 높음.

언제 쓰나.

• 구글 클라우드를 이미 쓰고 있음 + 멀티리전이 비즈니스 요구사항 + 운영 부담 최소화.
• 결제·예약·재고처럼 절대 틀리면 안 되는 트랜잭션이 전 지구 유저에게 필요할 때.

언제 피하나.

• 단일 리전으로 충분함. 그냥 Cloud SQL for Postgres를 쓰는 게 10배 싸다.
• AWS 주력 환경.

2.2 CockroachDB

무엇인가. 2015년 출시된 "오픈소스 Spanner" 컨셉. Postgres 와이어 프로토콜 호환. Raft 합의 + 하이브리드 논리 클럭.

2024–2025 변화.

• CockroachDB v25.x에서 쿼리 플래너 개선, 벡터 인덱스(pgvector-compatible), 변경 데이터 캡처(CDC) 웹훅 싱크 강화.
• 라이선스 변경(2024): 상용 조건 강화. 자체 호스팅 시 유료 라이선스가 필요한 규모 기준이 생김 → 이 점이 선택에서 가장 민감한 이슈.
• Serverless 상품("Cockroach Cloud Serverless") → "CockroachDB Cloud Standard/Basic"으로 브랜딩 재편.

장점.

• 멀티리전 토폴로지를 SQL 한 줄로 설정: ALTER TABLE ... SET LOCALITY REGIONAL BY ROW.
• 온라인 스키마 변경, 자동 리샤딩, 실패 노드 자동 교체.
• Postgres와의 호환성이 높음 — 드라이버를 거의 그대로 쓸 수 있다.

단점.

• 무거움. 단일 노드로 벤치를 돌리면 Postgres보다 느리다. 3노드 이상에서 의미가 생김.
• 2024년 라이선스 이슈로 일부 팀이 Postgres + Citus나 Yugabyte로 이탈.
• 조인 많은 복잡 쿼리는 여전히 튜닝이 까다롭다.

언제 쓰나.

• 멀티리전 OLTP + Postgres 호환 + AWS/GCP 양쪽 운영이 필요.
• 한 테이블에서 행마다 어느 리전에 살지 다르게 두고 싶을 때(REGIONAL BY ROW).

2.3 TiDB

무엇인가. PingCAP이 만든 MySQL 프로토콜 호환 분산 SQL. "MySQL 대체를 꿈꾸던" 아시아권(특히 중국·일본·한국 일부)에서 큰 존재감.

구조.

• TiDB(SQL 레이어) + TiKV(분산 KV, Raft) + PD(플레이스먼트 드라이버) + TiFlash(컬럼 스토어, 분석용).
• HTAP 노선 — OLTP는 TiKV 행 스토어, OLAP는 TiFlash 컬럼 스토어, 같은 쿼리에서 혼합 가능.

2024–2025 업데이트.

• TiDB Serverless GA 확대(미국·EU·아시아).
• 벡터 타입 + HNSW 인덱스 네이티브 지원 — "MySQL 호환 + 분산 + 벡터"라는 드문 조합.
• AI 에이전트 도구로 TiDB MCP 공개(2025).

강점.

• MySQL 생태계(ORM, 툴, 모니터링)를 그대로 쓰면서 분산 확장.
• HTAP로 분석 쿼리를 OLTP와 같은 클러스터에서 돌릴 수 있음 → 별도 데이터 파이프라인 축소.

약점.

• Postgres 생태가 필요한 팀에는 맞지 않음.
• 멀티리전 쓰기는 CockroachDB/Spanner만큼 성숙하지 않음.

2.4 세 제품 요약

3장. Yugabyte — "정말 Postgres인 분산 SQL"

YugabyteDB는 Spanner/Cockroach와 구조가 비슷하지만 차별점이 분명하다. YSQL은 실제 Postgres 코드를 포크해 쓴다. 즉, Postgres 13+의 문법·함수·확장(특히 pgcrypto, pg_trgm, pgvector)이 "재구현"이 아니라 거의 그대로 동작한다.

주요 포인트

• SQL + CQL 듀얼 API: YSQL(Postgres 호환) + YCQL(Cassandra 쿼리 언어). 한 클러스터에서 둘 다.
• 멀티리전 배포: xCluster(비동기), 지리 분산 배치(동기).
• Yugabyte Aeon: 서버리스 상품. 사용량 기반 과금 + 스케일-투-제로(일정 조건).
• 라이선스: 핵심은 Apache 2.0. Cockroach 라이선스 변경 이후 이주하는 팀의 1순위 후보로 자주 거론.

언제 쓰나

• Postgres 확장 생태계(pgvector, PostGIS 등)를 그대로 유지하면서 분산으로 가야 할 때.
• Cockroach에서 벗어나고 싶은 팀.

단점

• 단일 리전 성능은 여전히 바닐라 Postgres만 못함.
• 커뮤니티가 Cockroach/TiDB보다 작음 → 트러블슈팅 글이 적다.

4장. Aurora DSQL — AWS의 "서버리스 + 분산 + Postgres"

2024년 re:Invent에서 공개된 Amazon Aurora DSQL은 분산 SQL 시장의 판도를 흔든 공식 발표였다.

핵심 주장

• "Spanner처럼 글로벌 + Postgres 호환 + 서버리스(스케일-투-제로) + 초저지연 읽기."
• Active-Active 멀티리전 쓰기를 지원(프리뷰 단계에서 언어 정리 중).
• Postgres 와이어 프로토콜 호환이지만 완전한 Postgres는 아님 — 일부 기능 제한(예: 외래키, 시퀀스, 일부 확장).

특이한 선택

• 분리형 아키텍처: 쿼리 프로세서/트랜잭션 매니저/스토리지가 완전히 분리 + 각각 독립 스케일.
• 결제는 쿼리/IO 단위 — 유휴 시 비용 0에 가깝다.
• AWS IAM 인증 네이티브 지원 — Lambda에서 토큰 기반 접속.

한계

• 2025년 현재 GA 진행 중, 기능 매트릭스가 Postgres 완전 호환은 아님.
• AWS 락인.
• 엄격한 외래키·복잡 트랜잭션 중심 앱은 호환 검증 필수.

언제 쓰나

• AWS 생태, 스케일-투-제로가 중요한 스타트업, "Spanner 스타일"을 원하지만 GCP에 묶이고 싶지 않음.

언제 피하나

• 외래키·트리거·복잡 PL/pgSQL 의존이 크다면 지금은 보수적으로 접근.

5장. 서버리스 Postgres 3대장 — Neon, Supabase, PlanetScale

여기부터는 "글로벌 분산이 아니라 단일 리전 Postgres를 서버리스로" 제공하는 제품군. 서버리스 프론트엔드(Vercel, Cloudflare Pages)와 가장 잘 맞는 조합이다.

5.1 Neon — "Git 같은 브랜칭이 가능한 Postgres"

독특한 점.

• 스토리지와 컴퓨트 분리. 컴퓨트는 유휴 시 자동 중단(스케일-투-제로).
• 브랜칭: main에서 feature-x 브랜치를 만들어 같은 데이터 스냅샷 위에서 마이그레이션 실험 가능. CoW 기반이라 복사 비용 거의 0.
• Point-in-Time Restore를 모든 시점에 대해 가능.
• 2024년 말 Databricks가 Neon을 인수하면서 "AI/에이전트를 위한 DB"라는 포지셔닝이 강화됨(에이전트별 프로젝트/브랜치 즉시 생성).

약점.

• 단일 리전. 글로벌 쓰기는 지원 안 함(리드 리플리카 제한).
• 브랜치가 너무 많아지면 스토리지 비용 주의.

5.2 Supabase — "Postgres + Auth + Storage + RT + Edge Functions"

무엇인가. Postgres를 중심으로 Firebase 스타일 백엔드를 묶은 스택.

2024–2025 포인트.

• Supabase Queues, Supabase Cron, AI Assistant(자연어로 쿼리 작성).
• pgvector 기본 탑재 — 바로 RAG/벡터 검색에 쓰기 좋음.
• Row-Level Security(RLS)를 Auth와 깊이 통합 — 클라이언트에서 직접 PostgREST 호출하는 서버리스 모델.
• 셀프호스팅 가능(오픈소스 코어).

약점.

• RLS 모델은 강력하지만 팀이 처음엔 실수하기 쉬움(누구나 읽을 수 있게 뚫어두는 실수).
• 매니지드 단일 리전. 멀티리전은 리드 리플리카로만.

5.3 PlanetScale — "처음엔 MySQL, 이제 Postgres"

흐름.

• 원래 Vitess 기반 MySQL 호환 서버리스 DB로 시작. 브랜칭/Deploy Request를 원조로 만든 팀.
• 2024년 무료 티어 폐지 → 커뮤니티 충격, Neon/Supabase로의 이탈 가속.
• 2025년 PlanetScale for Postgres 발표 — Neon과 정면 승부.

장점.

• 대규모 트래픽 운영 노하우(Vitess 경험).
• 스키마 변경 프로세스가 가장 세련됨: branch → deploy request → safe migrations.

단점.

• 무료 티어 없음. 스타트업·사이드 프로젝트에는 접근성 떨어짐.
• Postgres 제품은 Neon에 비해 아직 신생.

5.4 세 제품 요약

6장. 엣지 SQLite — Turso/libSQL, Cloudflare D1

"DB를 유저 가까이 둔다"는 아이디어는 오래됐지만, 2023–2024년에야 실전 제품이 됐다.

6.1 Turso / libSQL

구조. SQLite 포크인 libSQL을 사용. 임베디드 복제(Embedded Replicas)가 핵심:

1. 마스터(쓰기)는 특정 리전에 있음.
2. 각 엣지 노드/서버가 로컬에 SQLite 파일 복제본을 유지.
3. 읽기는 로컬 파일에서 → 마이크로초 지연.
4. 쓰기는 마스터로 전송 → 읽기와 분리된 지연.

장점.

• 읽기 지연이 "네트워크 왕복 없음" 수준.
• SQLite의 단순함 유지(파일 기반, 백업 쉬움).
• 멀티테넌트 SaaS에서 "테넌트당 DB 하나"가 현실적으로 가능(DB 생성이 초 단위).

약점.

• 쓰기 처리량 한계(SQLite 라이터 단일성).
• 복잡 조인·애널리틱스는 여전히 Postgres가 유리.

6.2 Cloudflare D1

무엇인가. Cloudflare Workers 환경에 통합된 SQLite 기반 DB.

2024–2025.

• D1 Read Replicas 등장(2025) — 읽기를 다수 리전 자동 복제.
• Workers에서 env.DB.prepare(...) 한 줄로 접근, 콜드스타트 없음.
• Queryable Logs/Analytics Engine과 조합해 서버리스 분석까지.

약점.

• 한 DB 최대 크기 제한, 대용량 운영엔 부적합.
• 트랜잭션 격리·고부하 쓰기 한계가 아직 진화 중.

6.3 언제 쓰나

• 글로벌 읽기 중심 제품(문서, 상품 카탈로그, CMS, 블로그): 엣지 SQLite가 지연 면에서 압도.
• 테넌트당 DB 모델이 자연스러운 SaaS: Turso가 최적.
• 글로벌 쓰기 중심(협업, 실시간 편집): 엣지 SQLite 대신 분산 SQL이 맞다.

7장. "Postgres 확장 전쟁" — pgvector, Citus, TimescaleDB, pgmq

Postgres 자체가 "단순 RDB"에서 "데이터 플랫폼"으로 진화한 게 2022–2025년의 큰 흐름이다. 확장이 핵심.

대표 확장

• pgvector — 벡터 임베딩, HNSW/IVFFlat 인덱스. RAG 스택의 기본값.
• Citus — 분산 Postgres. Microsoft가 인수 후 Azure Database for PostgreSQL에 내장. 샤딩 기반.
• TimescaleDB — 시계열 전용 하이퍼테이블. IoT·관측에 강함. 2024년 모든 매니지드 Postgres에서 사용 가능하도록 라이선스 변화.
• pgmq — Postgres로 메시지 큐. SQS/Kafka 대체를 꿈꾸는 소규모 이벤트 시스템에 매력적.
• PostgREST — 테이블을 REST API로 즉시 노출. Supabase의 기반.
• pg_graphql — GraphQL 자동화.
• pg_bigm / pg_trgm — 전문 검색(한국어·일본어 N-gram 포함).

실전 조언

• 필요 확장 목록을 먼저 만들고, 그걸 지원하는 매니지드 서비스를 골라라. 확장이 안 되면 갈아타기가 매우 어렵다.
• Neon: pgvector·pg_trgm·postgis 등 주요 확장 지원.
• Supabase: 확장 선택지가 가장 넓음(공식 지원 40+).
• RDS/Aurora: 확장은 AWS 허용 목록에 있어야 씀 — TimescaleDB는 오래 안 됐다.

8장. 커넥션 관리 — 서버리스의 진짜 병목

서버리스 환경에서 Postgres를 쓸 때 진짜 문제는 "DB 성능"이 아니라 커넥션이다. Lambda 1000개가 각각 DB 직결하면 Postgres는 수백 연결에서 무너진다.

해결책 맵

골라주기

• Vercel/Lambda + Postgres → HTTP 드라이버(Neon serverless driver, Prisma Accelerate) 먼저 고려.
• 컨테이너/ECS/Fargate + Postgres → PgBouncer 또는 매니지드 풀러.
• 대규모 단일 앱 → 앱 내부 커넥션 풀(HikariCP, pgBouncer 로컬 사이드카).

9장. 마이그레이션·스키마 변경 — 2025년의 모범

DB 제품의 "진짜 차이"는 상당 부분 마이그레이션 UX에서 나온다.

전통적 고통

• ALTER TABLE 락이 큰 테이블에서 몇 분~몇 시간.
• 롤백 어려움.
• 환경 간 드리프트(dev/staging/prod 스키마 미묘하게 다름).

2025년 해법들

도구 계열

• Atlas (ariga.io) — 선언형 스키마 + 진단 + CI 통합. Postgres·MySQL 모두.
• pgroll — Postgres 온라인 마이그레이션 도구. 쉐도우 스키마 + 양방향 뷰.
• Neon Branch — "브랜치에서 변경 → deploy."
• PlanetScale Deploy Request — 원조. 브랜치 + 리뷰 + 안전 마이그레이션.
• Prisma Migrate / Drizzle Kit / Sqitch — 각 ORM/도구의 마이그레이션 파이프라인.

원칙 — "Expand & Contract"

1. 새 컬럼 추가(null 허용, 기본값 없음).
2. 앱에서 양쪽 쓰기(새/구 컬럼 동시).
3. 백필.
4. 읽기를 새 컬럼으로 전환.
5. 구 컬럼 삭제.

각 단계는 역방향 호환. 배포 중 롤백하더라도 깨지지 않음.

10장. 관측성·백업·재해복구

기능은 다 비슷해 보여도, 운영 단계 품질은 제품마다 격차가 크다.

체크 항목

• 관측성: 슬로우 쿼리 로그, pg_stat_statements 노출, EXPLAIN UX, 메트릭 대시보드.
• 백업: Point-in-Time Restore 얼마나 촘촘한가? 교차 리전 복사?
• 재해복구: 리전 장애 시 페일오버 자동? RPO/RTO 수치?
• 보안: IP 알로우리스트, VPC Peering/Private Link, 저장/전송 암호화, 감사 로그.
• 규정: SOC2/ISO27001/HIPAA/PCI/GDPR/개인정보보호법.

간단 매트릭스

11장. 비용 구조 이해 — "돈이 새는 곳" 5가지

1. IOPS·스토리지 분리 과금

Aurora·DSQL·Neon류는 스토리지와 컴퓨트가 분리되어 따로 과금. 컴퓨트만 줄여도 스토리지 고정비는 남는다.

2. 이탈 트래픽(Egress)

크로스-리전/클라우드-외부로 나가는 데이터가 비싸다. 리드 리플리카를 다른 리전에 두면 Egress 폭탄.

3. 커넥션당 메모리

커넥션 풀러 없이 Lambda 수천 개가 직결하면, 인스턴스 메모리가 커넥션 오버헤드로 소진 → 스펙 업 → 비용.

4. 브랜치·스냅샷 누적

Neon/PlanetScale처럼 브랜치가 많아지면 "CoW 스토리지 비용"이 쌓인다. CI가 매 커밋 브랜치를 만들면 빠르게 누적.

5. 벡터 인덱스 크기

pgvector HNSW는 빠르지만 메모리 쿵쿵 먹는다. "10M 벡터 × 1536d = 60GB+" 같은 계산을 미리.

12장. 의사결정 트리 — 요약

질문 1: 강일관성 + 글로벌 쓰기가 필수인가?
├─ 예: Spanner / CockroachDB / Yugabyte / Aurora DSQL
└─ 아니오 → 질문 2

질문 2: 서버리스/엣지 런타임이 주력인가?
├─ 읽기 중심 + 엣지: Turso(libSQL), Cloudflare D1
├─ 쓰기도 자주 + 일반적 CRUD: Neon, Supabase, PlanetScale
└─ 아니오 → 질문 3

질문 3: 대형 분석·HTAP가 필요한가?
├─ 예: TiDB(HTAP), BigQuery/Snowflake/ClickHouse 분리
└─ 아니오 → 질문 4

질문 4: Postgres 확장 생태계를 100% 원하는가?
├─ 예, 매니지드: Supabase, Neon, RDS for Postgres
├─ 예, 셀프호스팅: Postgres + Citus(분산) + TimescaleDB
└─ 아니오 → 일반적 RDB: RDS MySQL, Aurora MySQL, Cloud SQL

13장. 2026년 이후 — 향후 주시 포인트

1. AI 네이티브 DB: Neon(Databricks 산하), TiDB, MotherDuck 등이 "에이전트를 위한 DB" 기능(즉석 브랜치, 대화형 쿼리)에 집중. DB = 에이전트의 작업 공간이 됨.
2. 분산 벡터 인덱싱: pgvector HNSW는 샤딩이 어려움. 분산 환경에서 벡터 검색 성능이 2026년의 격전지.
3. Aurora DSQL GA 이후: AWS 본류 서비스이므로 파급력이 크다. 기존 Aurora, RDS, DynamoDB 포지셔닝이 흔들릴 수 있음.
4. 주권 클라우드(Sovereign Cloud): 유럽·중동·일본에서 데이터 주권 규제 강화 → 멀티리전 배포가 선택이 아닌 필수로.
5. ZFS·DuckDB의 서버 쪽 침투: 스토리지 레이어에 DuckDB나 Parquet을 끼우는 "lakehouse-ish" DB가 소수 등장(MotherDuck, Trino 등).

실전 도입 체크리스트 — 12개 질문

1. 현재 쿼리·커넥션 패턴을 측정했나(P50/P99, 동시 커넥션 피크)?
2. 강일관성이 필요한 테이블/트랜잭션을 명시했나?
3. 데이터 주권 요구사항이 명문화되어 있나?
4. 필요한 Postgres 확장 목록이 있는가? 후보 DB가 모두 지원하는가?
5. 스케일-투-제로가 필요한가? 아니면 24/7 부하가 있나?
6. 브랜칭이 진짜 워크플로에 의미 있는가(PR당 브랜치 만들 것인가)?
7. 백업/PITR 요구 RPO·RTO 숫자가 있나?
8. 커넥션 풀러 전략을 정했나(HTTP 드라이버 vs PgBouncer vs RDS Proxy)?
9. 스키마 변경 프로세스는? Atlas/pgroll/Deploy Request?
10. 관측성 스택(Datadog·Grafana·pg_stat_statements)과 통합 가능한가?
11. 락인 비용(떠날 때 얼마나 힘든가)을 계산했나?
12. 3년 뒤 예상 데이터량·트래픽에서도 가격 모델이 유효한가?

흔한 실수 10가지

1. "그냥 Postgres"라고 뭉뚱그리기 — RDS/Aurora/Neon/Supabase는 세부 동작이 다 다르다.
2. 강일관성을 모든 테이블에 요구하기 — 80%는 결과적 일관성으로 충분. 비용 급증의 원인.
3. 멀티리전을 "나중에"로 미루기 — 설계 단계에서 안 넣으면 나중에 리팩토링 지옥.
4. 브랜치 청소 안 함 — Neon/PlanetScale에서 수천 브랜치 누적 → 비용 폭주.
5. 커넥션 풀러 없이 서버리스 — 서비스 다운의 가장 흔한 원인.
6. 벤더 락인 안 따짐 — Spanner·DSQL은 떠나기 어렵다. Yugabyte·Cockroach는 상대적으로 이식성 있음.
7. EXPLAIN ANALYZE 안 돌림 — 분산 DB일수록 실행 계획이 중요.
8. 타임존 혼란 — UTC로 저장, 표시에서만 변환. 분산이면 더욱 중요.
9. 외래키 없이 시작 — 나중에 추가가 엄청 비싸다. 분산 DB에서 제약은 미리 검토.
10. "DB는 안 바꿔도 돼" — 서비스 수명 5년 이상이면 마이그레이션은 한 번쯤 일어난다. 추상화 레이어를 미리.

다음 편 예고

시즌 7의 4화는 메시지 큐와 이벤트 스트리밍 2025 — Kafka·Pulsar·NATS·Redpanda·NSQ·pgmq·AWS SQS/SNS·GCP Pub/Sub를 비교하고, "우리 시스템엔 큐가 필요한가?"를 판단하는 기준을 다룹니다. 분산 트랜잭션이 어려운 이유, 이벤트 소싱과 CQRS의 실전 적용, Exactly-once가 거짓말인 이유까지.

— 분산 데이터베이스 편 끝.