Databricks Lakebase로 구성하는 PostgreSQL 기반 HTAP 레이크하우스

PostgreSQL과 Lakehouse 사이에 있던 데이터 복제 문제

Databricks가 2026년 2월 공개한 Lakebase는 Lakehouse 아키텍처 위에 PostgreSQL 호환 OLTP 레이어를 올린 완전 관리형 데이터베이스 서비스다. 트랜잭션 처리와 대규모 분석 쿼리가 하나의 스토리지 레이어를 공유하는 HTAP(Hybrid Transactional/Analytical Processing) 모델을 Lakehouse에 적용했다.

애플리케이션은 PostgreSQL 인터페이스로 데이터를 쓰고, Spark·Databricks SQL 같은 분석 엔진은 그 데이터를 별도 ETL 없이 조회한다. 기존 PostgreSQL 생태계와의 호환성을 유지하면서 클라우드 객체 스토리지를 네이티브 스토리지로 쓰는 것이 이 구조의 출발점이다.

Lakebase가 두는 데이터 계층

Lakebase는 Databricks Data Intelligence Platform 위에서 동작하는 서버리스 PostgreSQL 데이터베이스다. 컴퓨트와 스토리지를 분리해 각각 확장할 수 있으며, PostgreSQL 인터페이스로 기록한 데이터는 Lakehouse 스토리지의 Delta Lake 포맷에 직접 저장된다.

일반적인 OLTP 데이터베이스가 자체 블록 스토리지에 데이터를 기록하는 것과 달리, Lakebase는 S3, ADLS, GCS 같은 클라우드 객체 스토리지를 일급 스토리지로 사용한다. 따라서 Spark, Databricks SQL 및 다른 분석 엔진이 별도 변환이나 이동 없이 같은 스토리지의 OLTP 테이블을 읽을 수 있다.

pgvector와 PostGIS 같은 주요 PostgreSQL 확장도 지원하므로 AI 벡터 검색과 지리공간 분석 워크로드도 다룰 수 있다. 기존 드라이버, ORM, 라이브러리를 그대로 활용할 수 있다는 점도 전환 비용을 낮춘다.

분석용 복제본 없이 트랜잭션과 분석을 연결하는 구조

기존 Lakehouse는 배치 분석에는 적합하지만 OLTP를 직접 처리하지 못했다. 트랜잭션 처리를 위해 RDS나 Aurora 같은 관계형 데이터베이스를 별도로 두고, CDC(Change Data Capture), Fivetran·Airbyte 같은 ETL 도구, 또는 자체 데이터 이동 로직으로 Lakehouse에 데이터를 옮겨야 했다.

그 결과 분석 데이터에는 ETL 주기마다 수 분~수 시간의 지연이 생기고, CDC 설정·스키마 관리·오류 복구가 운영 부담으로 남는다. 스토리지와 컴퓨트가 이중으로 과금되며, 파이프라인 지연 중에는 두 시스템의 데이터가 일치하지 않을 수도 있다.

Lakebase는 OLTP 레이어를 Lakehouse 스토리지에 직접 구현한다. 트랜잭션 쓰기와 분석 읽기가 같은 Delta Lake 테이블을 공유하므로, 이중 스택을 단일 스택으로 바꾸고 ETL 파이프라인을 제거하는 방식이다.

⤢✕

PostgreSQL 호환성과 컴퓨트·스토리지 분리

Lakebase의 컴퓨트 계층은 PostgreSQL 프로토콜을 처리하며 SQL 파싱, 쿼리 실행, 트랜잭션 관리를 맡는다. 영구 데이터는 로컬 디스크가 아니라 클라우드 객체 스토리지에 Delta Lake 포맷으로 기록된다.

항목	전통적 PostgreSQL	Lakebase
스토리지	로컬 블록 스토리지	클라우드 객체 스토리지
쓰기 지연	수 ms	상대적으로 높음
분석 통합	ETL 필요	ETL 없음
스케일링	수직 확장 중심	컴퓨트·스토리지 독립
비용 모델	항상 프로비저닝	서버리스(사용량 기반)
확장성(Extensions)	자체 설치	관리형(pgvector 등 포함)

클라이언트 측에서는 일반 PostgreSQL 서버처럼 연결 문자열과 psycopg2, JDBC, node-postgres 같은 드라이버를 사용할 수 있다. SQLAlchemy와 Prisma 같은 ORM도 그대로 쓸 수 있어, 애플리케이션 코드 변경 없이 Lakebase로 옮기는 경로가 가능하다.

Delta Lake 로그가 보장하는 트랜잭션 처리

Lakebase의 ACID 트랜잭션은 Delta Lake 트랜잭션 로그(Transaction Log) 위에 구현된다. Delta Lake는 Parquet 데이터 파일과 JSON 트랜잭션 로그인 _delta_log/를 결합해 파일 시스템 수준의 ACID를 제공한다.

원자성은 커밋 처리에서 확보한다. 모든 쓰기는 우선 트랜잭션 로그의 커밋 엔트리로 기록되고, 성공한 경우에만 테이블 버전이 증가한다. 실패한 작업은 로그 엔트리를 남기지 않으므로 부분 쓰기가 없다.

격리성에는 낙관적 동시성 제어(Optimistic Concurrency Control)가 쓰인다. 쓰기 트랜잭션은 최신 버전을 읽은 뒤 커밋 시 충돌을 검사하며, 동시 수정이 겹치면 충돌 예외와 재시도 로직이 작동한다.

커밋 데이터는 클라우드 객체 스토리지에 복제·저장되고, 트랜잭션 로그도 주기적으로 Parquet 체크포인트로 압축돼 보관된다. 스키마 강제(Schema Enforcement)는 데이터 타입과 컬럼 제약을 유지하며, 다중 테이블 트랜잭션은 카탈로그 커밋을 통해 지원한다.

⤢✕

트랜잭션 데이터를 분석 엔진에 노출하는 방식

Lakebase 테이블은 Delta Lake에 직접 기록되므로, 분석 엔진은 별도 파이프라인 없이 트랜잭션 데이터를 읽을 수 있다.

Unity Catalog에 Lakebase 테이블을 등록하면 Spark 또는 Databricks SQL에서 표준 SQL로 직접 조회할 수 있다. 예를 들어 SELECT * FROM lakebase.orders WHERE created_at > NOW() - INTERVAL 1 HOUR 같은 쿼리를 ETL 없이 실행한다.

반대 방향의 흐름도 지원한다. Lakebase는 Delta Lake 테이블 변경을 Lakebase PostgreSQL 테이블로 역방향 동기화하는 Reverse ETL 기능을 제공하므로, 배치 분석 결과를 OLTP 애플리케이션에 다시 반영할 수 있다.

PySpark에서는 Lakebase 테이블을 마이크로 배치 스트리밍 소스로 연결할 수 있다. Delta Live Tables나 Structured Streaming 파이프라인이 외부 CDC 도구 없이 Lakebase 변경 데이터를 실시간으로 소비하는 구성이다.

PostgreSQL 워크로드를 옮기는 경로

표준 PostgreSQL 프로토콜을 지원하므로 이관 절차는 기존 도구를 중심으로 잡을 수 있다. Systech의 DBShift™ 같은 마이그레이션 가속기는 레거시 PostgreSQL 워크로드의 스키마와 데이터를 Lakebase로 직접 옮기는 리프트앤시프트(Lift-and-Shift) 경로를 제공한다.

평가 단계에서는 PostgreSQL 스키마, 확장, 쿼리 패턴을 분석하고 일부 시스템 카탈로그나 특수 확장처럼 Lakebase에서 지원하지 않는 기능을 확인한다.
스키마는 pg_dump로 DDL을 추출해 Lakebase에 적용한다. 대부분의 표준 DDL은 수정 없이 호환된다.
초기 데이터는 pg_dump + pg_restore 또는 COPY 명령으로 적재한다.
애플리케이션은 connection string의 호스트명만 변경한다. 드라이버와 ORM 코드는 수정하지 않는다.
기존 CDC/ETL 파이프라인은 단계적으로 비활성화하고 Lakebase 직접 쿼리로 대체한다.

Debezium과 Kafka Connect 기반 CDC 파이프라인을 운영하고 있다면, 전환 후 기존의 “OLTP → 메시지 큐 → Lakehouse” 흐름을 점진적으로 제거할 수 있다. Lakebase가 Delta Lake에 직접 쓰므로 Databricks Structured Streaming에서 Delta Lake 변경 로그를 직접 소비하는 패턴으로 옮길 수 있다.

Autoscaling을 포함한 운영 모델

Databricks는 2026년 3월 12일부터 Lakebase Autoscaling을 새로운 기본 버전으로 제공하기 시작했다. 사전 프로비저닝 방식인 Lakebase Provisioned와 달리 Autoscaling은 워크로드에 따라 컴퓨트 용량을 자동 조정한다.

트래픽이 낮은 시간에는 컴퓨트를 축소해 비용을 줄이고, 급격한 트래픽 증가에는 컴퓨트를 자동 증설한다. 용량 계획과 인스턴스 크기 조정 같은 DBA 운영 부담을 줄이며, 다중 가용 영역(AZ) 배포로 단일 장애점을 제거하는 HA도 내장한다.

2026년 4월 기준 Lakebase는 AWS에서 GA(일반 가용) 상태이며 Azure에서는 공개 프리뷰다. Google Cloud 지원은 추후 제공될 예정이다.

AI 애플리케이션과 레거시 분석 통합에서의 활용

Databricks Apps로 만든 AI 애플리케이션은 Lakebase를 트랜잭션 데이터 레이어로 둘 수 있다. 사용자 세션 데이터, 추천 이력, 피드백 로그는 PostgreSQL 인터페이스로 기록하고, 같은 Delta Lake 테이블에서 피처 엔지니어링 파이프라인이 실시간으로 모델 학습 데이터를 소비한다. pgvector를 활용하면 임베딩 벡터 검색도 같은 데이터베이스에서 처리할 수 있어 Pinecone이나 Weaviate 같은 별도 벡터 데이터베이스 없이 RAG 파이프라인을 구성할 수 있다.

RDS PostgreSQL 기반 SaaS 애플리케이션이 Databricks 분석 플랫폼과 통합하려고 Fivetran + dbt 파이프라인을 운영하는 경우도 대상이다. Lakebase로 전환하면 ETL 파이프라인을 제거하고 분석 지연을 시간 단위에서 초 단위로 단축할 수 있다. 애플리케이션 코드는 바꾸지 않고 connection string만 교체해 마이그레이션을 완료하는 방식이다.

HTAP 통합이 맞는 워크로드

Lakebase는 PostgreSQL 호환 인터페이스와 Delta Lake 기반 ACID 트랜잭션을 결합해, OLTP와 분석 쿼리를 단일 스토리지 레이어에서 처리한다. 분석과 트랜잭션 통합이 핵심인 AI 애플리케이션과 데이터 플랫폼에서는 데이터 파이프라인 복잡도와 운영 비용을 낮출 수 있다.

다만 Azure와 GCP 지원은 아직 완전하지 않으며, 초저지연 OLTP가 필요한 워크로드에서는 전통적 PostgreSQL보다 쓰기 지연이 높을 수 있다. 이 조건을 감안해도 데이터 복제와 ETL 제거의 효과가 큰 환경에서는 강력한 대안으로 자리잡을 것으로 전망된다.