Skip to content
Published on

데이터베이스 엔진 2026 딥다이브 — Postgres가 API를 이겼고, ClickHouse·DuckDB가 분석을 이겼다

Authors

2026년의 데이터베이스 풍경은 두 가지 명제로 정리할 수 있다. 첫째, Postgres가 API를 이겼다. 새로 시작하는 SaaS의 기본값, AI 에이전트가 만들어 내는 코드의 표준 dialect, 서버리스의 캐치프레이즈, 모든 ORM의 1순위 타깃 — Neon, Supabase, Prisma Postgres, Xata, Render Postgres, Fly Postgres, Vercel Postgres(=Neon), Crunchy Bridge, Tembo, Convex SQL까지 모두 Postgres wire protocol을 흉내내거나 직접 호스팅한다. 둘째, ClickHouse와 DuckDB가 분석을 이겼다. ClickHouse는 페타바이트급 클라우드 OLAP의 사실상 표준이 되었고, DuckDB는 노트북·엣지·브라우저·Lambda·Worker 어디서든 도는 "Embedded Snowflake" 포지션을 굳혔다. 그 사이에서 StarRocks·Doris·Druid·Pinot은 실시간 OLAP을, Cassandra·Scylla·Aerospike·FoundationDB는 초고QPS 워크로드를, TiDB·CockroachDB·YugabyteDB·Spanner는 분산 SQL을 차지한다.

이 글은 2026년 5월 기준으로 OLTP, OLAP, NewSQL, NoSQL, 임베디드, ORM, 그리고 서버리스 Postgres 경제학까지 데이터베이스 엔진 지형도를 한 장으로 펼친다. PostgreSQL 18 RC, MySQL 9.x, MariaDB 12, ClickHouse 24.x, DuckDB 1.x의 실제 기능을 짚고, 한국·일본 빅테크의 운영 사례를 곁들인다.

2026년의 큰 그림

  • Postgres: Greenplum, Aurora Limitless, Citus, Neon, Supabase, PlanetScale Postgres까지 모두 PG 위에 올라간다. AI/벡터(pgvector)·시계열(timescaledb)·검색(tsvector)·지리(postgis)·큐(pgmq)가 한 엔진에서 돈다.
  • MySQL/MariaDB: Oracle MySQL 9, MariaDB 12, Vitess(이제는 PlanetScale에서 분리), TiDB가 wire-protocol 호환을 유지. 그러나 신규 채택은 감소 추세.
  • OLAP: ClickHouse Cloud, Snowflake, BigQuery, Databricks, Redshift Serverless, StarRocks, Doris, Druid, Pinot — 그리고 "데이터 레이크 위 ClickHouse/DuckDB" 패턴이 압도적.
  • 분산 SQL: TiDB, CockroachDB 25, YugabyteDB, Spanner GA on-prem, AlloyDB Omni, Aurora DSQL.
  • NoSQL: Cassandra 5, ScyllaDB, Aerospike, DynamoDB, Mongo 8, Cosmos DB.
  • 임베디드: SQLite, libSQL/Turso, DuckDB, rqlite, Cloudflare D1, LiteFS.
  • 개발자 도구: Drizzle ORM이 TypeScript ORM의 주류로 자리잡았고, sqlc는 Go에서, Diesel·SeaORM은 Rust에서, SQLAlchemy 2.x는 Python에서, GORM은 여전히 Go의 1티어.

ACID와 격리 수준 다시 보기

표준 SQL 격리 수준은 네 단계지만 실제 엔진들은 더 많은 변종을 구현한다.

  • Read Uncommitted: 더티 리드 허용. 거의 안 쓴다.
  • Read Committed: PostgreSQL/Oracle 기본값. 커밋된 데이터만 본다.
  • Repeatable Read: MySQL InnoDB 기본값. 같은 트랜잭션 내 동일 쿼리 결과 동일.
  • Serializable: PostgreSQL은 SSI(Serializable Snapshot Isolation) 구현.
  • Snapshot Isolation: Oracle, SQL Server, CockroachDB의 사실상 표준.

CockroachDB와 Spanner는 외부 일관성(external consistency) 또는 strict serializability를 보장하기 위해 TrueTime 또는 hybrid logical clock(HLC)을 사용한다.

MVCC와 복제 토폴로지

PostgreSQL의 MVCC는 튜플 버전을 같은 페이지에 두고 xmin/xmax 트랜잭션 ID로 가시성을 결정한다. 결과적으로 VACUUM이 필수다.

MySQL InnoDB는 언두 로그에 이전 버전을 별도로 저장한다. Postgres와 달리 별도 정리 데몬(purge thread)이 백그라운드에서 돈다.

복제 토폴로지:

  • 단일 리더(Async): 기본 Postgres/MySQL. 리더에서 비동기로 팔로워 전파.
  • 단일 리더(Sync): synchronous_standby_names로 한 개 이상 팔로워가 ACK해야 커밋.
  • 멀티 리더: MySQL Group Replication, BDR, CockroachDB.
  • 리더리스(Quorum): Cassandra, Scylla, DynamoDB.
-- PostgreSQL 18 논리 복제 v2: 양방향 + 시퀀스 동기화
CREATE PUBLICATION sales_pub
  FOR TABLE orders, customers, products
  WITH (publish = 'insert, update, delete, truncate', publish_via_partition_root = true);

CREATE SUBSCRIPTION sales_sub
  CONNECTION 'host=primary.internal dbname=app user=replicator'
  PUBLICATION sales_pub
  WITH (copy_data = true, streaming = 'parallel', origin = 'any', two_phase = true);

-- 시퀀스도 18에서 자동 동기화
ALTER SUBSCRIPTION sales_sub REFRESH PUBLICATION SEQUENCES;

칼럼 vs 로우 스토리지

OLTP는 행 단위 접근이 많아 row storage(InnoDB, Postgres heap)가 유리하고, OLAP은 열 단위 압축이 결정적이어서 columnar(ClickHouse MergeTree, Parquet, Apache ORC, DuckDB native, Snowflake micro-partition)가 유리하다. ClickHouse는 LZ4/ZSTD에 더해 Gorilla, Delta, DoubleDelta 같은 시계열 특화 압축을 지원한다.

벡터화 실행(vectorized execution)은 한 번에 1024개(혹은 그 이상) 튜플을 SIMD로 처리한다. ClickHouse, DuckDB, Photon(Databricks), Velox, Snowflake가 모두 이 패턴이다.

쿼리 옵티마이저

PostgreSQL의 플래너는 CBO(Cost-Based Optimizer)에 RBO 휴리스틱을 일부 섞은 하이브리드다. pg_stat_statements, pg_hint_plan, auto_explain이 운영의 3종 세트.

EXPLAIN (ANALYZE, BUFFERS, FORMAT JSON, SETTINGS)
SELECT c.id, c.name, sum(o.total)
FROM customers c
JOIN orders o ON o.customer_id = c.id
WHERE o.created_at >= now() - interval '7 days'
GROUP BY c.id, c.name
ORDER BY 3 DESC
LIMIT 100;

MySQL은 8.0에서 hash join을 추가했고, MariaDB는 더 일찍부터 지원했다. ClickHouse 24.x의 새로운 옵티마이저(enable_analyzer = 1이 기본)는 distributed JOIN 재작성을 크게 개선했다.

파티셔닝과 샤딩

  • 선언적 파티셔닝: PostgreSQL PARTITION BY RANGE/LIST/HASH, MySQL PARTITION BY — 단일 노드 내.
  • 샤딩: Vitess(MySQL), Citus(PG), TiDB/TiKV, CockroachDB range, Yugabyte tablet.
  • 자동 분할: Cockroach·Yugabyte는 64MB(기본) 단위로 자동 분할/병합.
-- PostgreSQL pg_partman으로 시계열 자동 파티셔닝
CREATE TABLE events (
  id bigserial,
  occurred_at timestamptz NOT NULL,
  payload jsonb NOT NULL
) PARTITION BY RANGE (occurred_at);

SELECT partman.create_parent(
  p_parent_table => 'public.events',
  p_control => 'occurred_at',
  p_type => 'native',
  p_interval => 'daily',
  p_premake => 7
);

-- pg_cron으로 매일 새 파티션 + 60일 이전 분리
SELECT cron.schedule('events-maint', '0 2 * * *',
  $$CALL partman.run_maintenance_proc()$$);

분산 트랜잭션 — 2PC, Calvin, Raft, Spanner

  • 2PC(Two-Phase Commit): 고전. 코디네이터 장애시 블로킹.
  • Paxos / Multi-Paxos: 이론은 옳지만 구현이 끔찍하다.
  • Raft: etcd, CockroachDB, TiKV, YugabyteDB, FoundationDB(변종)의 표준. 리더 선출이 명시적이라 운영이 쉽다.
  • Calvin: 결정론적 트랜잭션 정렬. FaunaDB가 채택했지만 Fauna는 2025년 종료.
  • Spanner TrueTime: GPS+원자시계로 시계 불확실성 경계 ε를 보장. CockroachDB는 HLC + uncertainty interval로 근사.

Postgres가 API를 이긴 이유

  1. 확장성: extension 인터페이스가 거의 모든 워크로드를 흡수했다. pgvector(벡터), timescaledb(시계열), citus(분산), postgis(지리), pg_cron(스케줄러), pgmq(큐), pgaudit(감사), pglogical(논리 복제), pg_partman(파티셔닝), hypopg(가상 인덱스).
  2. JSONB: NoSQL을 사실상 흡수.
  3. MERGE/RETURNING 정련: 17에서 MERGE에 RETURNING이 들어왔고, 18에서는 WHEN NOT MATCHED BY SOURCE까지.
  4. 논리 복제 v2: 양방향, 병렬, 시퀀스 동기화.
  5. AIO(Asynchronous I/O): 18 RC에 io_uring/libaio 백엔드.
  6. 블록 점진 백업(incremental backup): 17의 pg_combinebackup.
-- Postgres 17/18 MERGE — UPSERT의 표준 표현
MERGE INTO inventory AS t
USING (
  SELECT sku, qty FROM staging.new_stock
) AS s
ON t.sku = s.sku
WHEN MATCHED AND s.qty = 0 THEN DELETE
WHEN MATCHED THEN UPDATE SET qty = t.qty + s.qty, updated_at = now()
WHEN NOT MATCHED THEN INSERT (sku, qty, created_at) VALUES (s.sku, s.qty, now())
WHEN NOT MATCHED BY SOURCE AND t.updated_at < now() - interval '90 days' THEN DELETE
RETURNING merge_action(), t.sku, t.qty;

MySQL 9 / MariaDB 12

Oracle MySQL 9는 vector 데이터 타입(2024년 GA), JS stored function(개발 미리보기), 그리고 HeatWave Lakehouse를 끌고 들어왔다. MariaDB 12는 Oracle MySQL과의 분기를 더 가속화 — Galera Cluster 4, ColumnStore 통합, JSON Path 강화.

신규 채택은 둔화되었으나, 토스(Toss)·우아한형제들·라쿠텐 같은 한국·일본 빅테크는 여전히 MySQL을 중심 OLTP로 운영한다. Vitess(쿠팡, LINE이 일부 사용)는 PlanetScale에서 분리되어 CNCF 졸업 프로젝트로 자리잡았다.

서버리스 Postgres 경제학

서버리스 Postgres의 본질은 두 가지다.

  1. 컴퓨트와 스토리지 분리: Neon의 Pageserver/Safekeeper/Compute 3계층, Aurora의 grain shared storage, AlloyDB의 columnar accelerator.
  2. scale-to-zero: 트래픽 0이면 컴퓨트 정지, 비용 0(스토리지만 청구). Neon, Supabase Branches, Xata, Cloudflare Hyperdrive가 모두 이 모델.

cold-start 비용: Neon ~300-700ms, Supabase pooler always-on, PlanetScale Postgres always-on. 사용 패턴이 burst-heavy/dev에 가까울수록 Neon, steady-state에 가까울수록 Supabase 또는 RDS가 유리.

# Neon Branch + Vercel Preview 패턴 (개념)
neon:
  project: my-app
  default_branch: main
  preview_strategy:
    on_pr_open: create_branch_from_main
    branch_name: pr-${PR_NUMBER}
    compute_endpoint:
      autoscaling: { min_cu: 0.25, max_cu: 4 }
      suspend_timeout: 300
  protections:
    main:
      allowed_writers: [migrations-bot, app-prod]
      enable_logical_replication: true

ClickHouse — 클라우드 OLAP의 사실상 표준

ClickHouse는 MergeTree 엔진 패밀리를 중심으로 한 column-store다. 핵심:

  • MergeTree: 정렬 키 기반 immutable parts. 백그라운드 머지로 정렬·압축 유지.
  • ReplicatedMergeTree: ZooKeeper/ClickHouse Keeper로 메타데이터 동기화.
  • Distributed: 샤딩 라우터.
  • Materialized View: 인서트 시점 사전 집계.
-- ClickHouse 시계열 + 분산 + MV 패턴
CREATE TABLE events_local ON CLUSTER prod (
  ts        DateTime CODEC(DoubleDelta, ZSTD(3)),
  user_id   UInt64,
  event     LowCardinality(String),
  props     Map(String, String),
  amount    Decimal(18, 4) CODEC(Gorilla, ZSTD(3))
) ENGINE = ReplicatedMergeTree('/clickhouse/tables/{shard}/events', '{replica}')
PARTITION BY toYYYYMM(ts)
ORDER BY (user_id, event, ts)
TTL ts + INTERVAL 90 DAY DELETE,
    ts + INTERVAL 7 DAY TO VOLUME 'cold'
SETTINGS index_granularity = 8192;

CREATE TABLE events ON CLUSTER prod
AS events_local
ENGINE = Distributed('prod', 'default', 'events_local', rand());

CREATE MATERIALIZED VIEW events_daily_mv ON CLUSTER prod
ENGINE = SummingMergeTree
ORDER BY (event, day)
AS SELECT
  event,
  toDate(ts) AS day,
  count() AS cnt,
  sum(amount) AS revenue
FROM events_local
GROUP BY event, day;

ClickHouse Cloud는 컴퓨트-스토리지 완전 분리, 멀티-리전 복제, autoscaling을 제공. Korea의 토스가 자체 분석 파이프라인에서, 일본의 LINE이 메시지 분석에서 ClickHouse를 채택한 것이 공개되어 있다.

DuckDB — 임베디드 Snowflake

DuckDB는 SQLite의 OLAP 버전이라고 부른다. 단일 바이너리, 임베디드, Parquet/CSV/JSON/Arrow를 외부 테이블로 즉시 스캔, vectorized 실행, 멀티스레드.

# DuckDB로 S3 Iceberg/Parquet 위 즉시 분석
duckdb << 'SQL'
INSTALL httpfs; LOAD httpfs;
INSTALL iceberg; LOAD iceberg;

SET s3_region='ap-northeast-2';
SET s3_access_key_id='AKIA...';
SET s3_secret_access_key='...';

CREATE VIEW events AS
  SELECT * FROM iceberg_scan('s3://lake/warehouse/events');

SELECT
  date_trunc('day', ts) AS day,
  event,
  count(*) AS cnt
FROM events
WHERE ts >= current_date - INTERVAL 30 DAY
GROUP BY 1, 2
ORDER BY 1 DESC, cnt DESC
LIMIT 50;
SQL

DuckDB 1.x로 안정성 보증을 확보했고, MotherDuck(매니지드 클라우드), DuckDB-Wasm(브라우저), DuckDB on Lambda/Workers 같은 변종이 늘었다.

StarRocks · Apache Doris · Druid · Pinot

  • StarRocks: 실시간 OLAP, MPP, MySQL 호환. 외부 카탈로그(Iceberg/Hudi/Delta)를 직접 쿼리. 한국 카카오·일본 Mercari가 일부 채택.
  • Apache Doris: StarRocks와 동일 뿌리에서 분기. 중국 발 빠른 채택.
  • Apache Druid: 시계열·실시간 인덱싱. Imply가 상용 디스트리뷰션.
  • Apache Pinot: LinkedIn 발. 초저지연 실시간 OLAP. UberEats, LinkedIn 피드.
  • Apache Kudu: 사실상 레거시. Impala와 함께 정체 상태.

Druid vs Pinot vs ClickHouse 선택 가이드

  • 밀리초 지연 + 실시간 인덱싱이 절대 우선: Druid 또는 Pinot.
  • PB급 OLAP, 풍부한 SQL, 머지뷰: ClickHouse.
  • Iceberg/Hudi 위 페더레이션, MySQL 호환: StarRocks/Doris.
  • 노트북·Lambda·엣지: DuckDB.

NewSQL — TiDB, CockroachDB, YugabyteDB, Spanner

분산 SQL은 "수평 확장 가능한 ACID OLTP"를 추구한다.

  • TiDB: MySQL 호환. TiKV(Raft) + PD(메타) + TiDB(SQL 레이어). HTAP을 위해 TiFlash(컬럼) 동봉.
  • CockroachDB 25: PostgreSQL wire 호환. range 기반 분산, follower reads, multi-region 토폴로지.
  • YugabyteDB: PG/Cassandra 호환 듀얼 인터페이스. xCluster 비동기 멀티-리전.
  • Spanner: TrueTime. GCP에서만 매니지드, on-prem GA(2025).
  • Aurora DSQL: AWS의 distributed Postgres. multi-active multi-region.
-- TiDB EXPLAIN ANALYZE — coprocessor pushdown 확인
EXPLAIN ANALYZE
SELECT user_id, sum(amount)
FROM orders
WHERE created_at >= '2026-05-01'
GROUP BY user_id
HAVING sum(amount) > 1000;

Cassandra 5 · ScyllaDB · Aerospike

리더리스 와이드-칼럼 스토어들이다.

  • Cassandra 5: Storage-attached indexes(SAI), trie-based memtable, vector search. 쿠팡이 상품 카탈로그/주문 메타에 운영.
  • ScyllaDB: C++ 재작성, seastar shard-per-core. Cassandra wire 호환. 더 적은 노드로 같은 처리량.
  • Aerospike: 인메모리 + SSD hybrid. 일본 라쿠텐의 광고/추천 시스템이 대표 사례.
-- Cassandra CQL: TTL + LWT
CREATE TABLE sessions (
  user_id uuid,
  session_id timeuuid,
  ip inet,
  payload text,
  PRIMARY KEY (user_id, session_id)
) WITH default_time_to_live = 86400
  AND compaction = { 'class' : 'TimeWindowCompactionStrategy', 'compaction_window_size' : 1, 'compaction_window_unit' : 'HOURS' };

INSERT INTO sessions (user_id, session_id, ip, payload)
VALUES (uuid(), now(), '203.0.113.1', '{"agent":"chrome"}')
IF NOT EXISTS;

SQLite · libSQL · Turso · rqlite · Cloudflare D1

임베디드 SQL은 "어디서든 도는 DB"가 핵심.

  • SQLite: 가장 많이 배포된 데이터베이스. WAL, FTS5, JSON1, rtree.
  • libSQL: Turso가 만든 SQLite fork. 멀티-라이터, 임베디드 replica.
  • Turso: libSQL 매니지드. 엣지 분산.
  • rqlite: SQLite + Raft 분산.
  • Cloudflare D1: SQLite 기반. Workers 통합.
  • LiteFS: Fly.io의 SQLite 복제 FS(다소 정체).

Embedded → Edge 경향

서버리스 v2의 키워드는 "엣지 데이터베이스"다. 사용자에게 가까운 PoP에 데이터를 두고, 일관성은 약하게 보장한다. Turso의 임베디드 replica, Cloudflare D1, PlanetScale Boost, Vercel Edge Config 모두 같은 흐름.

Mongo · DynamoDB · Cosmos DB

  • MongoDB 8: queryable encryption, time-series 컬렉션, vector search. ACID 멀티-도큐먼트 트랜잭션.
  • DynamoDB: AWS-only. PK/SK 디자인이 모든 것. global tables.
  • Cosmos DB: Mongo·Cassandra·Gremlin·SQL API. Azure-only.

Neon · Supabase · PlanetScale · Xata · Convex

  • Neon: 가장 순수한 Postgres 서버리스. branching, scale-to-zero, autoscaling.
  • Supabase: Postgres + Auth + Storage + Edge Functions + Realtime. 풀스택 BaaS.
  • PlanetScale: 2024년 Vitess → Postgres 피벗. Boost 자동 캐싱.
  • Xata: Postgres 위 검색·파일·BFF.
  • Convex: TS 네이티브 reactive DB. SQL-like + 함수형 mutation.

Fauna는 2025년 종료, 데이터는 Convex/Neon으로 마이그레이션 가이드 제공.

EdgeDB → Gel, SurrealDB

  • EdgeDBGel로 리브랜드(2025년 말). 자체 EdgeQL, Postgres 위에 올라가는 graph-relational. 마이그레이션 도구가 강점.
  • SurrealDB: multi-model(document + graph + KV + relational). 라이브 쿼리.

신규 채택은 더디지만, AI 에이전트가 스키마를 다루기 좋은 추상이라 재조명 받는 중.

Postgres 확장 — 운영 필수 7종

확장용도
pg_stat_statements쿼리 통계
pg_repack온라인 VACUUM FULL 대체
pgvector벡터 검색
timescaledb시계열 하이퍼테이블
citus분산 샤딩
pg_partman파티션 자동화
pg_cron인-DB 스케줄러

추가로 pgaudit(감사), hypopg(가상 인덱스), pg_stat_kcache, auto_explain, pgbouncer(외장).

연결 풀링 — PgBouncer, Pgpool-II, ProxySQL, Vitess

# pgbouncer.ini — 트랜잭션 풀링 + 인증 위임
[databases]
app = host=primary.internal port=5432 dbname=app

[pgbouncer]
listen_port = 6432
pool_mode = transaction
default_pool_size = 50
reserve_pool_size = 10
reserve_pool_timeout = 5
max_client_conn = 5000
server_idle_timeout = 600
auth_type = scram-sha-256
auth_user = pgb_auth
auth_query = SELECT u.usename, u.passwd FROM pg_shadow u WHERE u.usename = $1
ignore_startup_parameters = extra_float_digits
admin_users = pgb_admin

PostgreSQL 18은 native connection pooler 작업이 진행 중(아직 GA는 아님). Supavisor(Supabase), Hyperdrive(Cloudflare), AlloyDB poolers가 클라우드 풀러의 대표주자.

DB 관측가능성 — pganalyze, Datadog DBM, OtterTune, EverSQL

  • pganalyze: Postgres 전문. log+pg_stat_statements 융합 + 자동 인덱스 추천.
  • Datadog DBM: Postgres/MySQL/Mongo/SQL Server 다중. APM 결합.
  • OtterTune: ML 기반 자동 튜닝(현재 서비스 축소).
  • EverSQL: MySQL 쿼리 최적화 SaaS.
  • PMM(Percona), PoWA, mongostat/mongotop, ClickHouse system.query_log 등 오픈소스 옵션도 풍부.

ORM 지형도 2026

언어1티어부상중비고
TypeScriptDrizzle, PrismaKysely, MikroORMDrizzle이 RSC 친화로 우세
PythonSQLAlchemy 2.xSQLModel, TortoiseSQLAlchemy 2.0 async 안정
Gosqlc, GORMBun, entsqlc가 점점 표준
RustDiesel, SeaORMsqlxsqlx + macros가 가장 흔함
RubyActiveRecordSequel안정기
Java/KotlinjOOQ, Spring DataExposedjOOQ는 칭찬 일색

Prisma Postgres는 2024년 발표 — Prisma가 자체 Postgres 매니지드를 제공하기 시작. Drizzle Studio는 로컬 GUI로 zero-config 매력.

한국·일본 운영 사례

  • 토스(Toss): 다수의 Aurora MySQL 클러스터 + ClickHouse 분석. 자체 DB on-call 문화 유명.
  • 쿠팡: Cassandra 대규모 운영(상품/주문 메타데이터). DynamoDB도 일부.
  • 카카오: MySQL + 자체 Cubrid 레거시 일부 + ClickHouse.
  • 네이버: Cubrid(자체 RDBMS) 레거시 + Postgres/MySQL + HBase.
  • LINE: PostgreSQL 대규모, MongoDB, Vitess, 일부 ClickHouse.
  • 메르카리(Mercari): Cloud Spanner를 대규모 OLTP에 채택 — 대표 사례 다수 공유.
  • 라쿠텐(Rakuten): Aerospike(광고/추천), Cassandra, Postgres.

비교 표 — 한 장 요약

엔진모델일관성분산라이선스
PostgreSQLrowRC/RR/SI/SSI단일 노드(+논리 복제)PostgreSQL
MySQLrowRR/RC단일 노드(+Group Replication)GPLv2
ClickHousecolumneventual(replica)shard+replicaApache 2.0
DuckDBcolumnn/a(embedded)없음MIT
Cassandrawide-coltunable quorumleaderless ringApache 2.0
ScyllaDBwide-coltunable quorumleaderless ringAGPL/Enterprise
TiDBrow+colsnapshot(HLC)Raft shardedApache 2.0
CockroachDBrowsnapshot(HLC)Raft rangeCCL
YugabyteDBrow+colsnapshotRaft tabletApache 2.0
SpannerrowexternalPaxos상용
Mongodoctunablesharded replica setSSPL
DynamoDBKV/docstrong/eventualhash sharded상용
Neonrow(PG)RC(PG)분리 스토리지Apache 2.0 + 상용
SQLiterowserializablen/aPublic domain
DuckDBcolumnn/an/aMIT

데이터 레이크 위의 SQL — Iceberg + DuckDB + ClickHouse

2026년 가장 뜨거운 패턴: 데이터 웨어하우스는 컴퓨트일 뿐이고, 진실은 Iceberg 테이블에 있다.

# Terraform: AWS Glue Iceberg + S3 + Athena/ClickHouse/DuckDB가 같은 테이블 조회
resource "aws_s3_bucket" "lake" {
  bucket = "yj-blog-lake-prod"
}

resource "aws_glue_catalog_database" "warehouse" {
  name = "warehouse"
}

resource "aws_glue_catalog_table" "events" {
  database_name = aws_glue_catalog_database.warehouse.name
  name          = "events"
  table_type    = "EXTERNAL_TABLE"

  parameters = {
    "table_type"               = "ICEBERG"
    "format"                   = "iceberg/parquet"
    "metadata_location"        = "s3://yj-blog-lake-prod/warehouse/events/metadata/v1.metadata.json"
  }

  storage_descriptor {
    location = "s3://yj-blog-lake-prod/warehouse/events/"
    columns {
      name = "ts"
      type = "timestamp"
    }
    columns {
      name = "user_id"
      type = "bigint"
    }
    columns {
      name = "event"
      type = "string"
    }
  }
}

ClickHouse는 iceberg/deltalake 테이블 함수, DuckDB는 iceberg_scan, Snowflake는 external iceberg table, BigQuery는 BigLake로 모두 같은 데이터를 본다.

데이터 모델링 — 정규화는 끝났는가

답: OLTP에서는 여전히 3NF에 가깝게, OLAP에서는 스타 스키마 또는 wide table. JSONB/Map은 분명한 사용처(가변 속성, 사용자 정의 필드)에만 쓰고 PK·외래키·인덱스로 통제할 수 있는 영역은 컬럼으로 평면화하라.

마이그레이션과 스키마 진화

  • Atlas(Ent): 선언적 마이그레이션. GitOps 친화.
  • sqitch / Flyway / Liquibase: 클래식.
  • Drizzle Kit / Prisma Migrate: TS 네이티브.
  • gh-ost / pt-online-schema-change: MySQL 무중단 스키마.
  • pgroll: Xata가 만든 Postgres expand/contract 마이그레이션.

보안 — RLS, 행 수준 암호화, queryable encryption

PostgreSQL의 RLS는 SaaS 멀티테넌시의 무기다.

ALTER TABLE invoices ENABLE ROW LEVEL SECURITY;

CREATE POLICY tenant_isolation ON invoices
  USING (tenant_id = current_setting('app.tenant_id', true)::uuid)
  WITH CHECK (tenant_id = current_setting('app.tenant_id', true)::uuid);

-- 애플리케이션이 트랜잭션 시작에서 컨텍스트 설정
SET LOCAL app.tenant_id = '11111111-2222-3333-4444-555555555555';

MongoDB 8의 queryable encryption은 암호문에서 동등 비교를 가능하게 한다. CockroachDB와 YugabyteDB도 client-side encryption SDK를 제공.

백업과 PITR

  • pg_basebackup + WAL archiving + pg_combinebackup(PG17+): 표준.
  • pgBackRest, Barman, WAL-G: 운영 도구.
  • Velero + 스토리지 스냅샷: K8s 환경.
  • CockroachDB BACKUP/RESTORE, Cassandra nodetool snapshot, MySQL Percona XtraBackup.

비용 모델 비교

카테고리대표가격 모델강점
매니지드 OLTPRDS Postgres, Aurora시간당 + I/O안정
서버리스 PGNeon, Aurora Serverless v2CU시간 + 스토리지scale-to-zero
데이터 웨어하우스Snowflake, BigQuery컴퓨트(크레딧) + 스토리지격리, 거버넌스
자체 호스팅 OLAPClickHouse, DruidCPU/RAM/디스크비용 우위
임베디드SQLite, DuckDB$0운영 단순성

어떤 엔진을 언제 쓰나 — 결정 트리

  • OLTP 새 프로젝트: Postgres.
  • 분석/대시보드: ClickHouse or DuckDB + Parquet/Iceberg.
  • 멀티 리전 강한 일관성: Spanner or CockroachDB.
  • 초고QPS 키밸류: ScyllaDB, Aerospike, DynamoDB.
  • 검색: Elasticsearch/OpenSearch or Postgres tsvector + pgvector.
  • 시계열: TimescaleDB(PG ext), ClickHouse, InfluxDB 3, VictoriaMetrics.
  • 그래프: Neo4j, Postgres + AGE, TigerGraph, SurrealDB.
  • 임베디드/엣지: SQLite/libSQL, DuckDB.

결론 — 2026년의 단순한 권장

기본값을 Postgres(매니지드면 Neon/Supabase/RDS)로 두고, 분석이 필요하면 DuckDB로 시작해서 ClickHouse로 졸업한다. 멀티-리전 ACID가 비즈니스 요구이면 CockroachDB 또는 Spanner. 초고QPS는 Scylla. 임베디드는 SQLite/libSQL. ORM은 TS면 Drizzle, Go면 sqlc, Python이면 SQLAlchemy 2.x, Rust면 sqlx + Diesel/SeaORM.

데이터베이스 선택은 더 이상 종교 전쟁이 아니다. 워크로드 패턴, 팀이 운영할 수 있는 한계, 그리고 가장 결정적으로 — 이 데이터 안에서 어떤 질문에 1초 안에 답해야 하는가가 모든 것을 결정한다.

References