LLM WikiAccess-protected knowledge portal
← 스터디 홈
130편 · 약 10분

Databricks Lakebase: Lakehouse에 Postgres를 내장하고 브랜치로 운영하는 방법

왜 Lakehouse에 OLTP 레이어가 필요한가

현대 데이터 플랫폼은 오랫동안 분석(OLAP)과 운영(OLTP)을 분리해왔다. 분석 데이터는 Delta Lake나 Iceberg로 관리되고, 운영 트랜잭션은 PostgreSQL이나 MySQL로 처리됐다. 두 세계를 연결하는 방법은 CDC 파이프라인이었다. 분석 집계 결과를 OLTP DB에 복사하거나, Debezium이 OLTP 변경 사항을 Lakehouse로 보냈다.

이 구조는 세 가지 문제를 만든다. 첫째, 파이프라인 지연이 생긴다. 분석 집계 결과가 운영 DB에 도달하기까지 수십 분이 걸리는 것은 흔하다. 둘째, 거버넌스가 분리된다. Unity Catalog에서 관리되는 데이터 계보와 권한이 OLTP 레이어를 건너면 끊긴다. 셋째, AI 에이전트 시대에 더 큰 문제가 드러났다. 에이전트는 Lakehouse 분석 결과를 즉시 포인트 쿼리로 조회해야 하는 워크로드를 만들어냈다. Parquet 풀스캔은 에이전트 추론 루프에 맞지 않는다.

Databricks Lakebase는 이 문제를 Lakehouse 안에 서버리스 Postgres를 직접 내장해서 해결한다. Databricks가 2025년 5월 인수한 Neon의 스토리지-컴퓨트 분리 아키텍처를 기반으로 한다. 2026년 8월, Lakebase의 프로그래매틱 관리와 데이터베이스 브랜칭이 GA가 됐다.

Lakebase 아키텍처

Lakebase는 Neon의 세 가지 핵심 컴포넌트로 구성된다.

Pageserver: Postgres의 8KB 페이지를 오브젝트 스토리지(S3/GCS)에 계층화해 저장한다. 컴퓨트 노드와 물리적으로 분리되어 있어 컴퓨트가 꺼져 있어도 데이터가 유지된다. LSN(Log Sequence Number)을 기준으로 페이지 버전을 관리하므로 특정 시점의 DB 상태를 재구성할 수 있다.

Safekeeper: WAL(Write-Ahead Log) 내구성을 담당하는 복수 노드 합의 레이어다. WAL은 Safekeeper 쿼럼에 먼저 커밋되고, 이후 비동기적으로 Pageserver로 전달된다. 컴퓨트 장애가 발생해도 WAL이 Safekeeper에 보존된다.

컴퓨트 노드: 표준 Postgres 프로세스다. 요청이 있을 때 수백 밀리초 안에 콜드 스타트한다. 유휴 상태에서는 컴퓨트 비용이 발생하지 않는다. 트래픽에 따라 자동 스케일링된다.

Databricks Lakehouse Delta / Iceberg Unity Catalog 분석·ML·거버넌스 OLAP 쿼리 Synced Tables (지속 동기화) Lakebase (서버리스 Postgres) 컴퓨트 노드 표준 Postgres 프로세스 콜드스타트 < 500ms Safekeeper WAL 쿼럼 내구성 복수 노드 합의 Pageserver Postgres 8KB 페이지 S3/GCS 계층 저장 LSN 버전 관리 CoW 브랜치 트리 ≡ 브랜칭의 핵심 브랜치 (Copy-on-Write) • prod (부모) ├─ dev-alice (분기 LSN=N) └─ ci-pr-123 (분기 LSN=N) 앱/서비스 OLTP 쿼리 Postgres 클라이언트 AI 에이전트 포인트 쿼리 低 레이턴시 CI/CD PR당 브랜치 스키마 검증 프로그래매틱 관리 GA REST API · CLI · Python/Java/Go SDK
Databricks Lakebase 아키텍처 — Lakehouse와 서버리스 Postgres의 통합

데이터베이스 브랜칭: O(1) 복사의 의미

Lakebase 브랜칭의 핵심은 스토리지를 복사하지 않는다는 점이다. Pageserver는 Postgres의 8KB 페이지를 LSN과 함께 오브젝트 스토리지에 저장한다. 브랜치를 만들 때 일어나는 일은 부모의 LSN 포인터를 가리키는 새 분기 마커를 기록하는 것뿐이다.

prod (parent, LSN=1000, 5TB)
├─ dev-alice   (LSN 1000에서 분기, 추가 스토리지 ≈ 0)
└─ ci-pr-123  (LSN 1000에서 분기, 추가 스토리지 ≈ 0)

브랜치가 데이터를 쓰면 Pageserver는 수정된 페이지만 새 LSN에 기록한다. 부모는 변경되지 않는다. 5TB 프로덕션 DB에서 브랜치를 만드는 데 걸리는 시간은 수 초 이내이며, 분기 직후 추가 스토리지 비용은 0에 가깝다.

이 특성이 세 가지 운영 패턴을 바꾼다.

개발 환경: 프로덕션 DB를 그대로 복사한 환경을 각 개발자가 갖는다. 실제 프로덕션 데이터 구조와 볼륨에서 개발할 수 있다. 분기 DB를 AI 코딩 에이전트(Copilot agent mode 등)에 연결해 안전하게 디버깅하는 패턴이 실제 사용 사례로 보고되고 있다.

CI/CD: PR마다 브랜치를 생성하고, 파이프라인이 끝나면 삭제한다. 스키마 마이그레이션 검증을 프로덕션 볼륨에서 할 수 있다. 테스트에서 발생한 데이터 변경이 프로덕션에 영향을 주지 않는다.

장애 재현: 프로덕션의 특정 LSN(시점)에서 읽기 전용 브랜치를 만들어 장애를 재현한다. 기존의 PITR(Point-in-Time Recovery)가 DB를 복원하는 데 걸리는 시간(수 분~수십 분)이 수 초 브랜치 생성으로 단축된다.

Synced Tables: Lakehouse → Lakebase 경계

Synced Tables는 Unity Catalog의 Delta/Iceberg 테이블을 Lakebase Postgres로 지속 동기화하는 메커니즘이다.

동작 방식:

  1. Unity Catalog 테이블을 synced table로 등록한다.
  2. Databricks가 변경 데이터를 Lakebase로 복제한다.
  3. 애플리케이션은 Postgres 표준 클라이언트로 동기화된 데이터를 조회한다.

Synced Table은 Lakebase 브랜치에 읽기 전용 스키마로 도착한다. 애플리케이션 스키마와 분리되어 있어 분석 데이터와 운영 데이터가 같은 Postgres 인스턴스에 공존하면서도 혼재되지 않는다.

동기화 지연은 수 초에서 수십 초 수준이다. 별도 Kafka 클러스터나 Debezium 커넥터 운영이 필요하지 않다. Unity Catalog 권한 모델이 Lakebase까지 적용된다.

8월 2026 GA: 프로그래매틱 관리

GA 이전까지 Lakebase 인스턴스·브랜치·엔드포인트 관리는 Databricks 콘솔에서만 할 수 있었다. 8월 2026 GA로 REST API, Databricks CLI, Python·Java·Go SDK가 완전 지원된다.

자원지원 작업
프로젝트생성·목록·삭제·업데이트
브랜치생성·목록·삭제·LSN 조회
엔드포인트생성·삭제·연결 정보 조회
역할·자격증명생성·부여·취소
Synced Table등록·동기화 상태 조회
카탈로그 연동Unity Catalog 바인딩

Terraform 제공자와의 통합은 이 API 위에 구축될 예정이다. Infrastructure-as-Code로 Lakebase 환경을 선언적으로 관리하는 길이 열린다.

운영 경계와 주의점

Lakebase가 모든 OLTP 워크로드를 대체하는 것은 아니다.

읽기 집중 포인트 쿼리에 유리하다. 분석 집계 결과를 낮은 지연으로 서빙하는 시나리오에서 효과가 크다. AI 에이전트가 Lakehouse 데이터를 Postgres 표준 쿼리로 조회하는 것이 대표 사례다.

쓰기 집중 고처리량 OLTP에서는 제약이 있다. 컴퓨트-스토리지 분리 구조는 높은 쓰기 처리량에서 레이턴시가 증가한다. Safekeeper 쿼럼 왕복이 커밋 경로에 있기 때문이다. 초당 수천 건의 쓰기 워크로드라면 기존 관리형 Postgres(RDS, Cloud SQL)를 먼저 검토해야 한다.

브랜치 수명 관리: 브랜치가 많아지면 Pageserver의 가비지 컬렉션 대상 데이터가 누적된다. 사용 완료된 브랜치는 명시적으로 삭제해야 한다. CI/CD 파이프라인에서 브랜치 삭제를 자동화하는 것이 권장된다.

연결 수 제한: 서버리스 Postgres이므로 PgBouncer 등 외부 커넥션 풀러를 앞에 두는 것이 권장된다. 동시 연결이 많은 경우 컴퓨트 노드의 max_connections에 주의해야 한다. Lakebase 인스턴스 유형별 연결 수 한도는 공식 문서에서 확인해야 한다.

HIPAA·C5·TISAX 컴플라이언스: 2026년 8월부터 컴플라이언스 보안 프로파일이 활성화된 워크스페이스에서 Lakebase가 기본 활성화됐다. 규정 대상 워크로드라면 이 설정을 먼저 확인해야 한다.

References

  • https://www.databricks.com/blog/announcing-lakebase-public-preview
  • https://www.databricks.com/blog/database-branching-postgres-git-style-workflows-databricks-lakebase
  • https://www.databricks.com/blog/enabling-evolutionary-database-development-database-branching-lakebase
  • https://www.databricks.com/blog/enabling-evolutionary-database-development-database-branching-lakebase-part-2
  • https://www.databricks.com/blog/branching-databases-code-cicd-pattern-lakebase-production-glaspoort
  • https://docs.databricks.com/aws/en/release-notes/product/2026/august
  • https://learn.microsoft.com/en-us/azure/databricks/release-notes/product/2026/august
  • https://learn.microsoft.com/en-us/azure/databricks/oltp/instances/sync-data/sync-table