From monolith to Lakebase to LTAP: rethinking the database from storage up
Author: Reynold Xin (Databricks) | Source: databricks.com/blog | Published: 2026-07-01
한 줄 요약
모놀리식 DB의 거의 모든 문제는 “WAL과 데이터 파일이 한 머신 안에 있다”에서 나오므로, WAL을 SafeKeeper·데이터 파일을 PageServer로 외부화하면 Postgres 컴퓨트가 stateless가 되고 그 위에서 LTAP(단일 복사본 트랜잭션+분석)이 자연스럽게 따라온다.
핵심 주장/내용
- 모놀리스의 근본 원인 하나: WAL(쓰기를 빠르고 안전하게) + 데이터 파일(읽기를 빠르게)이 같은 디스크에 있음 → misconfiguration/노드 손실로 인한 데이터 유실, read replica·HA가 물리적 클론 필요, 분석이 OLTP와 하드웨어 경합
- SafeKeeper: WAL을 Paxos 기반 쿼럼 복제로 외부화. 디스크 flush가 아닌 네트워크 쿼럼이 durability 기준. 진지한 Postgres는 어차피 synchronous replication 홉이 필요하므로 추가 오버헤드 없음
- PageServer: 데이터 파일을 오브젝트 스토리지로 외부화한 write-through 캐시. 요청 페이지가 최신이 아니면 SafeKeeper의 로그를 적용해 재구성. Postgres buffer pool → 로컬 디스크 캐시 → PageServer의 다층 캐싱으로 읽기 레이턴시는 모놀리스와 사실상 동일
- 해제되는 능력: 무제한 스토리지, scale-to-zero 서버리스 컴퓨트, zero data loss, 단순한 HA, 그리고 메타데이터 연산으로서의 즉시 브랜칭/클로닝/PITR(대형 프로덕션 DB를 초 단위로 브랜치)
- LTAP = 엔진이 아닌 스토리지 레이어에서의 통합: PageServer가 페이지를 오브젝트 스토리지에 materialize할 때 row→Parquet columnar로 transcode. Postgres 표현을 비트 단위로 보존
- 타입 시스템: 대부분 Parquet 네이티브 타입에 직접 매핑, NaN·±Inf·범위 밖 NUMERIC·exotic 타입은 같은 테이블의 structured overflow 필드에 canonical Postgres 텍스트로 병기(쿼리 가능 + 원본 바이트 복원 가능)
- 멀티버저닝: durability와 visibility를 분리. 모든 columnar row가 물리 heap 주소(block, offset)를 지녀 heap 페이지 재구성 가능. 중간 row 버전은 MVCC/PITR용으로 보존하되 Iceberg/Delta 리더에는 비노출
- freshness 해법: 분석 쿼리 시작 시 Postgres에 현재 LSN만 물어보고(값싼 메타데이터 조회), 그 LSN 기준으로 대부분을 오브젝트 스토리지에서 읽고 아직 materialize 안 된 최근 변경분만 PageServer에서 가져와 merge. Postgres는 숫자 하나만 반환하므로 분석 트래픽을 전혀 서빙하지 않음
- CDC/미러링 대비 차별점: 파이프라인 비용 때문에 CDC는 테이블을 선택해야 하지만 LTAP은 opt-in이 없음. 존재하는 테이블은 구조상 이미 lake에 있고 쿼리 가능. 두 뷰가 drift할 수 없음
- HTAP이 실패한 이유 3가지: 불완전한 기능 셋(FK, 성숙한 옵티마이저), 생태계 부재, 성능 격리 없음 — 모두 “두 워크로드를 한 엔진에” 결정에서 파생
주요 수치 / 사실
- SafeKeeper + PageServer 조합으로 쓰기 처리량 5배, 읽기 레이턴시 2배 개선
- Columnar는 row 대비 흔히 10배 이상 압축 → 캐싱 레이어↔오브젝트 스토어 네트워크 전송량 감소
- 전환 롤아웃 단계에서는 검증 목적으로 row·columnar 양쪽을 dual write
- 아주 작은 테이블은 Iceberg 메타데이터 생성 비용이 이득보다 커서 columnar 변환을 하지 않음
관련 위키
- Disaggregated OLTP Architecture
- Storage-Workload Architecture Taxonomy
- Catalog-Managed Tables
- Change Data Capture
- Object Storage Evolution
Source: 원문 보기