LLM WikiAccess-protected knowledge portal
← 스터디 홈
75편 · 약 17분

Databricks Lakebase: Lakehouse에 PostgreSQL을 통합하여 OLTP와 분석을 하나의 플랫폼으로 운영하는 방법

왜 Lakehouse에 PostgreSQL이 필요한가

Lakehouse 아키텍처는 데이터 엔지니어링 팀의 분석 문제를 잘 해결한다. Delta Lake, Iceberg 같은 테이블 포맷과 Spark, Trino 같은 쿼리 엔진을 결합해 대규모 데이터를 저비용으로 분석한다.

그러나 운영 애플리케이션, AI 에이전트, 실시간 API는 다른 요구사항을 갖는다.

  • 밀리초 수준의 지연: Spark 쿼리는 초~분 단위다.
  • 행 수준의 업데이트: Lakehouse는 OLAP에 최적화되어 있고, 빈번한 단건 갱신에 비효율적이다.
  • PostgreSQL 호환 연결: 기존 애플리케이션은 psycopg2, JDBC 드라이버, ORMs으로 연결된다.

결국 많은 팀이 두 가지 시스템을 운영하게 된다. 분석용 Lakehouse와 운영용 RDB. 그리고 두 시스템 사이의 데이터 동기화 파이프라인을 따로 관리한다.

Databricks Lakebase는 이 구조를 하나의 플랫폼 안으로 끌어들이는 시도다.

Lakebase의 기반: Neon 인수

Databricks는 2025년 5월, 서버리스 PostgreSQL 회사인 Neon을 약 10억 달러에 인수했다. Lakebase는 Neon의 기술적 토대 위에 구축된다.

Neon의 핵심 설계 원칙:

  • 스토리지-컴퓨트 분리: 데이터는 오브젝트 스토리지(S3 호환)에 저장. 컴퓨트는 수요에 따라 독립적으로 확장
  • CoW(Copy-on-Write) 브랜치: Git 브랜치처럼 데이터베이스를 분기. 브랜치 생성은 데이터를 복사하지 않아 거의 즉각적
  • 스케일-투-제로(Scale-to-Zero): 쿼리가 없으면 컴퓨트 비용이 발생하지 않음

Databricks는 여기에 Lakehouse와의 통합 계층, Unity Catalog 거버넌스, Databricks 플랫폼 내 통합 관리 기능을 더했다.

Lakebase 아키텍처

Databricks Lakehouse Delta Lake Unity Catalog 테이블 Unity Catalog 거버넌스·계보·권한 Spark / DLT 배치·스트리밍 변환 Lakebase (Serverless PostgreSQL) PostgreSQL 17 psycopg2 / JDBC / ORMs Neon 스토리지 S3, CoW 브랜치 스케일-투-제로 오토스케일링 0.5–32 CU, HA 복제본 CoW 브랜치 개발·테스트·PITR Lakehouse ↔ Lakebase 동기화 Synced Tables Delta → PostgreSQL Lakeflow 파이프라인 Lakehouse Sync PostgreSQL → Delta (CDC) SCD Type 2 이력 보존 복제 운영 애플리케이션 / AI 에이전트 PostgreSQL wire protocol → Lakebase ← Lakehouse에서 PostgreSQL로 읽기 / PostgreSQL에서 Lakehouse로 CDC →
Databricks Lakebase 아키텍처 — OLTP와 Lakehouse의 통합

Synced Tables: Lakehouse 데이터를 PostgreSQL에서 서빙하기

에이전트 애플리케이션이나 운영 API가 Lakehouse의 최신 데이터를 밀리초 지연으로 읽어야 하는 경우, Synced Tables를 사용한다.

동작 방식:

  1. Unity Catalog의 Delta 테이블을 소스로 지정한다.
  2. Databricks가 관리하는 Lakeflow 파이프라인이 해당 테이블의 변경을 지속적으로 감지한다.
  3. 변경분이 Lakebase PostgreSQL 테이블로 복제된다.
  4. 애플리케이션은 PostgreSQL로 연결해 낮은 지연으로 읽는다.
-- Synced Table 생성 예시 (Databricks SQL)
CREATE SYNCED TABLE lakebase_project.public.product_catalog
  FROM DELTA TABLE main.commerce.products
  SYNC INTERVAL = '5 minutes';

주의사항: Synced Tables는 읽기 전용이다. PostgreSQL 측에서 직접 데이터를 수정할 수 없다. 원본 Delta 테이블을 수정하면 다음 동기화 시 반영된다.

적합한 패턴:

  • ML 피처 스토어(Lakehouse) → 실시간 추론 API(Lakebase)
  • 상품 카탈로그(분석 파이프라인에서 갱신) → 웹 애플리케이션(Lakebase 읽기)
  • 사기 탐지 규칙(데이터 과학팀 관리) → 결제 API(Lakebase 읽기)

Lakehouse Sync: PostgreSQL 변경을 Lakehouse로 스트리밍하기

방향이 반대인 경우다. 운영 애플리케이션이 Lakebase에 데이터를 쓰고, 그 변경이 분석 파이프라인에서 처리돼야 할 때 Lakehouse Sync를 사용한다.

동작 방식:

  1. Lakebase PostgreSQL의 변경(INSERT/UPDATE/DELETE)을 CDC로 캡처한다.
  2. Unity Catalog의 Delta 테이블에 각 변경이 행으로 추가된다.
  3. SCD(Slowly Changing Dimension) Type 2 방식으로 변경 이력이 보존된다.
Lakebase PostgreSQL (운영)
        ↓ CDC
Unity Catalog Delta 테이블 (분석)
  - 각 변경: (id, 값, 변경_시각, 작업_유형=INSERT/UPDATE/DELETE)
  - 이력 전체 보존 → 기간별 분석 가능

활용 예:

  • 주문 처리 시스템(Lakebase) → 매출 분석 Lakehouse
  • 사용자 프로필(Lakebase) → 개인화 ML 피처 파이프라인
  • 재고 관리(Lakebase) → 수요 예측 모델

Lakehouse Sync는 2026년 7월 기준 Beta 상태다. GA 이전에는 스키마 변경 처리, 초기 스냅샷 동기화 방식을 미리 확인해야 한다.

오토스케일링과 고가용성

Lakebase는 2026년 3월 12일부터 오토스케일링(Autoscaling)이 기본 배포 방식이 됐다. 기존 Provisioned 인스턴스는 2026년 6월부터 자동 마이그레이션이 시작됐다.

컴퓨트 단위(CU):

  • 오토스케일링: 0.5~32 CU (워크로드에 따라 자동 조정)
  • 고정(Provisioned): 36~112 CU (예측 가능한 성능이 필요할 때)
  • 스케일-투-제로: 비활성 기간에 컴퓨트 비용 미발생

고가용성:

  • 기본: 1 프라이머리 + 1 리드 레플리카
  • 최대: 1 프라이머리 + 3 리드 레플리카
  • 프라이머리 장애 시 자동 페일오버

브랜치와 PITR:

  • CoW 브랜치: 프로덕션 데이터를 복사 없이 개발·테스트 환경 분기
  • PITR(Point-in-Time Recovery): 특정 시점으로 복구
-- 브랜치 생성 (Databricks SQL)
CREATE BRANCH lakebase_project.my_dev_branch
  FROM MAIN
  AT TIMESTAMP '2026-08-01 09:00:00';
-- 프로덕션 데이터를 복사하지 않고, CoW 방식으로 즉각 생성됨

운영 고려사항

연결 풀링: 오토스케일링 환경에서 컴퓨트가 스케일업/다운될 때 기존 연결이 끊길 수 있다. 연결 풀러(PgBouncer, Neon Proxy 내장)를 반드시 사용해야 한다. Databricks는 OAuth 토큰 기반 자동 갱신을 지원한다.

Synced Tables 동기화 지연: 소스 Delta 테이블의 변경이 Lakebase에 반영되기까지 시간이 걸린다. 동기화 간격과 비즈니스 요구 지연 허용치를 확인해야 한다. 완전한 실시간 동기화가 필요하다면 Lakehouse Sync(역방향)를 쓰거나 직접 PostgreSQL에 쓰는 경로를 설계해야 한다.

비용 구조: 스케일-투-제로가 있어도 I/O 비용, 스토리지 비용, 복제본 비용이 있다. 유휴 데이터베이스의 경우 총 비용이 자관형 PostgreSQL보다 저렴할 수 있지만, 트래픽이 높은 경우 오토스케일링 컴퓨트 비용이 빠르게 증가할 수 있다.

Unity Catalog 필수: Lakebase를 Lakehouse와 통합하려면 Unity Catalog가 활성화되어 있어야 한다. 단순 서버리스 PostgreSQL만 필요하다면, Unity Catalog 없이도 기본 Lakebase 기능(PostgreSQL 연결, 브랜치, 오토스케일링)은 사용 가능하다.

Lakehouse Sync 스키마 변경: Beta 단계에서 소스 PostgreSQL 테이블의 컬럼이 추가·삭제되면 Lakehouse Sync 파이프라인이 중단될 수 있다. 스키마 변경 전에 항상 Sync 설정을 확인해야 한다.

어느 경우에 Lakebase를 선택하는가

Lakebase가 적합한 경우:

상황이유
Databricks 플랫폼 중심 조직단일 플랫폼 내 OLTP + 분석 통합
ML 피처를 실시간 API로 서빙Synced Tables로 Lakehouse 피처 → PostgreSQL 서빙
운영 데이터를 Lakehouse에 반영Lakehouse Sync로 CDC
개발/스테이징 환경이 자주 필요CoW 브랜치로 즉각 환경 생성
PostgreSQL 호환 필요 + 서버리스 원함완전 관리형, 스케일-투-제로

Lakebase가 적합하지 않은 경우:

상황이유
Databricks 미사용 조직통합 이점 없음, 독립 Neon/Aurora가 대안
초당 수만 건 쓰기 부하Provisioned 인스턴스 한계 확인 필요
OLAP 전용Lakehouse 직접 사용이 적합
완전한 실시간 양방향 동기화Lakehouse Sync는 아직 Beta, 지연 있음

Neon 챕터(n=31)와의 차이

이 시리즈의 Neon 챕터(database-frontier/31)는 스토리지-컴퓨트 분리와 CoW 브랜칭이라는 Neon의 핵심 기술을 다뤘다. Lakebase는 그 기술적 토대 위에 Databricks 플랫폼 통합이라는 다른 차원을 추가한다.

핵심 차이:

  • Neon: 독립적인 서버리스 PostgreSQL SaaS
  • Lakebase: Databricks Data Intelligence Platform 내에서 Lakehouse와 통합된 서버리스 PostgreSQL

Synced Tables와 Lakehouse Sync가 Lakebase를 단순 서버리스 PostgreSQL과 구분하는 핵심 기능이다.

정리

데이터 플랫폼 엔지니어 입장에서 Lakebase가 의미하는 것은 명확하다. Lakehouse와 OLTP 사이의 파이프라인을 직접 구축하고 운영하는 대신, 플랫폼이 그 동기화를 관리해 주는 구조다.

Synced Tables는 Lakehouse 데이터를 PostgreSQL 수준의 지연으로 제공하고, Lakehouse Sync는 PostgreSQL의 변경을 Delta 이력으로 자동으로 보존한다. CoW 브랜치는 프로덕션 데이터를 복사하지 않고 개발 환경을 즉시 만든다.

현재 시점에서 Lakehouse Sync는 Beta이고 Synced Tables의 동기화 지연은 워크로드에 따라 다르다. Databricks 플랫폼 안에서 운영 데이터와 분석 데이터를 함께 다루는 팀이라면, 이 두 기능의 정식 출시 일정을 주목할 필요가 있다.

References