Databricks LTAP and the Unfinished Problem of Unified Data

Author: Boaz Palgi (RegattaDB) | Source: regatta.dev | Published: 2026-06-24

한 줄 요약

LTAP은 스토리지 레이어만 통합했을 뿐 concurrency 모델·엔진·벡터 워크로드는 여전히 분리되어 있어, 에이전트 워크로드가 요구하는 진짜 통합은 미완이라는 벤더 관점의 비판.

LTAP은 HTAP이 아니다: 하나의 엔진으로 합치는 대신 Postgres(트랜잭션) + Spark/Lakehouse(분석)를 그대로 두고 스토리지만 통합. 엔진 경계는 그대로 남는다
두 개의 consistency domain: Postgres ACID ↔ Delta snapshot isolation 사이에 캐싱·변환 레이어가 끼어 있고, 그 flush window가 공개되지 않음. Postgres에서 커밋된 트랜잭션이 아직 flush 전이면 분석 쿼리가 stale을 넘어 incorrect할 수 있다는 문제 제기
벤치마크의 한계: Lakehouse//RT 수치는 TPC-H Q6(단일 테이블 스캔 + 필터 + 단순 집계) 기준. 조인을 테스트하지 않음. 고빈도 쓰기와 동시에 도는 복잡한 다중 테이블 분석 프로파일은 미공개
세 번째 워크로드(벡터)를 다루지 않음: 에이전트는 ① 라이브 운영 데이터 트랜잭션 ② 히스토리 분석 추론 ③ 시맨틱 검색을 동시에 요구. LTAP은 ①②만 스토리지 레이어에서 다루고 벡터는 Postgres 확장에 bolt-on 상태(단일 노드 천장)
통합의 진짜 난제는 단일 concurrency 모델: 기존 시스템을 확장하는 방식은 원래 시스템의 아키텍처 가정을 상속. RegattaDB는 log-structured storage, Row ID 기반 인덱스, row-level logical caching, optimistic+pessimistic 혼합 프로토콜로 처음부터 재설계했다고 주장

Lakebase(object storage 기반 서버리스 Postgres)는 GA, LTAP 자체는 coming soon, Lakehouse//RT는 beta (기사 시점)
Postgres 8KB 페이지 캐싱 vs Regatta의 row-level 캐싱 대비: 자주 접근하는 100B row가 8KB가 아닌 100B만 차지
아키텍트가 물어야 할 질문 3가지: 수백만 동시 에이전트 read/write에서 serializable 유지? 샤딩 없이 선형 확장? 엔진 라우팅 없이 단일 concurrency 모델로 3종 워크로드 처리?