Databricks가 말하는 Lakebase는 한마디로, Lakehouse와 긴밀하게 통합된 운영용 Postgres 데이터베이스입니다. 기존 Databricks가 강했던 분석·AI·데이터 엔지니어링 영역에 더해, 이제는 애플리케이션이 직접 읽고 쓰는 OLTP(온라인 트랜잭션 처리) 워크로드까지 플랫폼 안으로 끌어오려는 전략으로 이해하면 쉽습니다. Databricks Databricks Blog
이미지: Lakebase 제품 화면 예시. Databricks
많은 팀이 분석은 Lakehouse에서 하고, 실제 서비스 앱은 별도 Postgres/MySQL에서 운영합니다. 문제는 이 둘 사이를 맞추기 위해 커스텀 ETL, CDC 파이프라인, 권한 체계, 스키마 관리가 계속 복잡해진다는 점입니다. Lakebase는 이 틈을 메우기 위해 등장했고, Databricks는 이를 “운영 데이터와 분석 데이터를 한 플랫폼에서 연결하는 운영형 Postgres”로 설명합니다. Databricks Databricks Blog
왜 Lakebase가 나왔을까?
Databricks의 설명에 따르면 전통적인 데이터베이스는 여전히 컴퓨트와 스토리지가 강하게 결합된 구조가 많고, 그 결과 확장성·비용·개발 민첩성·벤더 종속성 면에서 한계가 있습니다. Lakebase는 이를 개선하기 위해 스토리지는 저비용 오브젝트 스토리지 쪽으로, 데이터베이스 컴퓨트는 독립적으로 탄력 운영하는 방향을 제시합니다. Databricks Blog
Databricks는 Lakebase를 “트랜잭션 데이터베이스의 특성”과 “Lakehouse의 유연성·경제성”을 결합한 새로운 아키텍처로 정의합니다. 즉, 앱이 필요로 하는 빠른 읽기/쓰기와 ACID 특성은 유지하면서도, 분석·AI·거버넌스와의 연결은 Lakehouse 쪽 장점을 최대한 활용하겠다는 개념입니다. Databricks Blog Databricks
Databricks Lakebase와 Databricks Lakehouse는 무엇이 다를까?
Databricks의 Lakehouse는 데이터 레이크와 데이터 웨어하우스의 장점을 결합한 분석 플랫폼으로, Delta Lake + Unity Catalog를 중심으로 데이터 수집, 정제, 분석, BI, ML/AI를 수행하는 구조입니다. 반면 Lakebase는 앱이 직접 붙는 운영형 Postgres 데이터베이스에 가깝습니다. 둘은 경쟁 관계가 아니라 서로 다른 워크로드를 담당하는 보완 관계입니다. Databricks Docs Databricks
| 구분 | Lakehouse | Lakebase |
|---|---|---|
| 핵심 목적 | 분석, BI, ML/AI, 데이터 엔지니어링 | 애플리케이션용 OLTP, 저지연 조회/쓰기 |
| 대표 저장 형태 | Delta 테이블 중심 | Postgres 데이터베이스 |
| 주요 사용자 | 데이터 엔지니어, 분석가, 데이터 과학자 | 백엔드 개발자, 앱 개발자, 운영 시스템 |
| 강점 | 대규모 처리, 단일 진실 원천, 거버넌스 | 저지연, 고동시성, 트랜잭션 처리 |
| 연결 방식 | Spark/SQL/ML/BI | Postgres 드라이버, pgAdmin, JDBC, 앱 연결 |
| 함께 쓰는 방식 | 예측값·피처·골드 테이블 생성 | 그 결과를 앱에 서빙하거나 앱 상태 저장 |
위 표처럼 정리하면, Lakehouse는 “생성·정제·분석”, Lakebase는 “서빙·상태 저장·앱 상호작용”에 더 적합합니다. 따라서 “Lakebase가 Lakehouse를 대체한다”기보다, Lakehouse에서 만든 가치를 운영 애플리케이션으로 밀어 넣는 마지막 퍼즐로 보는 쪽이 정확합니다. Databricks Blog Databricks Docs
이미지: Databricks Lakehouse 개념도. Databricks Docs
Databricks Lakebase의 장점
1) 분석 데이터와 운영 데이터를 더 가깝게 붙일 수 있다
Lakebase의 가장 큰 장점은 Lakehouse의 데이터를 앱이 바로 쓰기 좋은 형태로 서빙할 수 있다는 점입니다. Databricks는 이를 위해 Synced Tables를 제공하며, Lakehouse의 Unity Catalog 테이블을 Lakebase Postgres로 동기화해 낮은 지연시간과 높은 동시성으로 앱, 대시보드, 워크플로에서 활용할 수 있게 합니다. Databricks Databricks Docs
2) 익숙한 Postgres 생태계를 그대로 활용할 수 있다
Lakebase는 완전관리형 Postgres를 표방합니다. 기존에 사용하던 SQL, JDBC/psql, pgAdmin, DBeaver 같은 도구를 이어서 쓸 수 있고, Databricks는 pgvector, PostGIS 같은 확장도 언급하고 있습니다. 즉, 완전히 새로운 전용 DB를 배우기보다 기존 Postgres 경험을 살리면서 Databricks와 통합하는 그림에 가깝습니다. Databricks Databricks Docs
3) 운영 편의성이 현대적이다
Databricks는 Lakebase의 운영 측면 강점으로 독립 확장 가능한 컴퓨트/스토리지 구조, 포인트 인 타임 복구(PITR), 브랜칭, 읽기 복제본, 자동 스냅샷 등을 강조합니다. 전통적인 DB 운영에서 골칫거리였던 복제, 복구, 테스트용 복사본 생성, 피크 대비 과잉 프로비저닝 문제를 줄이겠다는 방향입니다. Databricks Databricks Blog
4) Unity Catalog와 함께 거버넌스를 통합할 수 있다
Lakebase 데이터베이스를 Unity Catalog에 등록하면 읽기 전용 카탈로그 형태로 메타데이터를 노출할 수 있고, 이를 통해 권한, 감사, 계보(lineage), 중앙 탐색을 Lakehouse 자산과 비슷한 방식으로 다룰 수 있습니다. 운영 DB가 완전히 “섬”처럼 분리되지 않는다는 점은 데이터 거버넌스 측면에서 꽤 큰 장점입니다. Databricks Docs
5) 앱 개발과 Databricks 앱 배포 흐름이 자연스럽다
Databricks는 Lakebase를 AI 에이전트와 앱을 위한 운영 데이터베이스로 포지셔닝합니다. 공식 블로그에서는 지원 포털 예제로, Lakehouse에서 만든 예측 결과를 Lakebase로 동기화하고, 앱은 다시 Lakebase에 상태값을 기록하는 흐름을 제시합니다. 즉, 데이터·AI 결과물을 서비스 UX로 연결하는 “마지막 마일”을 줄이려는 제품입니다. Databricks Databricks Blog
Databricks Lakebase의 단점과 주의점
1) 모든 경우에 전통적 OLTP 대체재는 아니다
Lakebase는 분명 매력적이지만, 모든 운영 DB 시나리오를 당장 대체한다고 보긴 어렵습니다. 특히 조직이 이미 특정 Postgres 운영 표준, 멀티 리전 전략, 특수 확장, 성능 튜닝 체계에 깊게 투자했다면, 애플리케이션 호환성·운영 표준·비용 모델을 충분히 검증해야 합니다. 이는 제품 성격상 자연스러운 고려사항입니다. Databricks Docs Databricks Blog
2) 동기화 기능에는 분명한 제약이 있다
Lakehouse에서 Lakebase로 보내는 Synced Tables는 Databricks가 읽기 중심(read queries) 사용을 강하게 권장합니다. 또 Triggered/Continuous 모드는 Change Data Feed(CDF) 가 필요하고, 일부 데이터 타입은 지원되지 않으며, 스키마 변경도 추가적(additive) 변경 위주로 제한됩니다. Databricks Docs
3) Lakehouse Sync는 아직 제약이 많다
Lakebase에서 Lakehouse로 보내는 Lakehouse Sync는 공식 문서 기준 Beta 성격이며, Lakebase Autoscaling + Postgres 17, databricks_postgres 데이터베이스, REPLICA IDENTITY FULL 설정 등 전제조건이 있습니다. 또한 파티션 테이블 미지원, 일부 타입 미지원, 스키마 변경 자동 반영 미지원 같은 제한도 있어 대규모 운영 시스템에 넣기 전에는 반드시 PoC가 필요합니다. Databricks Docs
4) “Lakehouse와 하나”라고 해도 역할 분리는 여전히 필요하다
Lakebase는 OLTP에 강하고, Lakehouse는 대규모 분석과 데이터 처리에 강합니다. 그래서 실제 설계에서는 어떤 데이터는 Lakebase에, 어떤 데이터는 Delta에 두고, 어디를 시스템 오브 레코드로 삼을지 명확히 정해야 합니다. “한 플랫폼”이 된다고 해서 데이터 모델링과 시스템 경계를 안 정해도 되는 것은 아닙니다. Databricks Docs Databricks Blog
Lakehouse와의 데이터 연동 방법: 실무적으로는 3가지가 핵심
1. Lakehouse → Lakebase: 분석 결과를 앱에 서빙하는 방식
이 패턴은 흔히 Reverse ETL 관점에서 이해하면 쉽습니다. Lakehouse에서 정제한 골드 테이블, 피처, 예측 결과, 고객 세그먼트 등을 Lakebase Postgres 테이블로 동기화해서 애플리케이션이 저지연으로 읽도록 만드는 방식입니다. Databricks는 이를 위해 Synced Tables를 제공합니다. Databricks Docs Databricks Blog
이미지: Lakehouse 데이터를 Lakebase로 서빙하는 구조. Databricks Docs
적용 순서
-
Unity Catalog의 원본 테이블을 준비합니다. Triggered/Continuous 동기화를 쓰려면 원본 Delta 테이블에 Change Data Feed(CDF) 를 활성화해야 합니다. Databricks Docs
-
Catalog 화면에서 Synced Table 생성을 시작합니다. 이 과정에서 대상 Lakebase 프로젝트/브랜치/데이터베이스를 고릅니다. Databricks Docs
-
동기화 방식은 보통 세 가지 중 하나를 고릅니다.
- Snapshot: 1회 전체 복사
- Triggered: 스케줄 기반 갱신
- Continuous: 초 단위에 가까운 지속 동기화
운영 앱에 가까울수록 Continuous가 유리하지만, 비용·변경률·원본 구조를 함께 봐야 합니다. Databricks Docs
-
Primary Key를 확인합니다. 공식 문서상 Primary Key는 동기화 설정에서 중요한 요소이며, Postgres 쪽에서 성능 최적화를 위해 인덱스를 둘 수 있습니다. Databricks Docs
-
생성된 Lakebase 쪽 테이블은 앱이 읽는 용도 중심으로 사용하는 것이 좋습니다. Databricks는 데이터 무결성을 위해 직접 수정하지 않는 패턴을 권장합니다. Databricks Docs
언제 좋은가?
추천 시스템, 고객 세그먼트, 사기 탐지 결과, 상담 우선순위, 실시간 지원 포털처럼 “분석 결과를 운영 화면에 보여줘야 하는” 케이스에 특히 잘 맞습니다. Databricks 공식 예시도 ML 예측이 담긴 Delta 테이블을 Lakebase로 지속 동기화해 앱이 읽도록 구성합니다. Databricks Blog
2. Lakebase → Lakehouse: 앱에서 발생한 변경을 분석계로 보내는 방식
반대로 앱에서 발생한 쓰기 이벤트나 상태 변경을 Lakehouse로 넘겨서 분석·모델링·감사에 활용하고 싶다면 Lakehouse Sync를 사용합니다. 이 기능은 Lakebase Postgres의 변경 사항을 CDC 기반으로 Unity Catalog 관리 Delta 테이블에 기록하며, 문서상 SCD Type 2 이력 형태로 적재됩니다. Databricks Docs
이미지: Lakebase에서 Lakehouse로 변경 이력을 보내는 구조. Databricks Docs
적용 순서
-
먼저 대상 테이블이 Lakebase Autoscaling 프로젝트의 Postgres 17 환경과 관련 요구사항을 만족하는지 확인합니다. 공식 문서 기준 이 전제는 중요합니다. Databricks Docs
-
동기화할 테이블에 대해
REPLICA IDENTITY FULL을 설정해야 합니다. Databricks는 이 설정이 있어야 업데이트/삭제 이력을 충분히 캡처할 수 있다고 설명합니다. Databricks Docs -
Lakebase UI에서 Lakehouse Sync를 시작하고, 어느 Postgres 스키마를 어느 Unity Catalog 카탈로그/스키마로 보낼지 지정합니다. Databricks Docs
-
결과는 보통
lb_<table_name>_history형태의 Delta 테이블로 생성되며, 삽입/수정/삭제 이벤트가 히스토리로 남습니다. 따라서 이후에는 Spark, SQL, DLT/파이프라인, 메달리온 아키텍처로 후속 가공이 가능합니다. Databricks Docs
언제 좋은가?
앱의 운영 로그, 주문 상태 변경, 사용자 액션 이력, 상담 티켓 상태 변화처럼 트랜잭션계에서 벌어진 일을 분석계로 흘려 보내고 싶은 경우에 적합합니다. 특히 “운영 DB는 빠르게 쓰고, 분석은 Lakehouse에서 하자”는 분리 전략과 잘 맞습니다. Databricks Docs
3. Unity Catalog 등록: 거버넌스와 탐색을 일원화하는 방식
Lakebase와 Lakehouse를 “데이터 복제”만으로 연결할 필요는 없습니다. 경우에 따라서는 Lakebase 데이터베이스를 Unity Catalog에 등록해 읽기 전용 카탈로그로 노출하는 것만으로도 충분한 가치가 있습니다. 이렇게 하면 데이터 탐색, 권한, 감사, 계보 측면에서 운영 데이터와 분석 데이터를 더 일관되게 다룰 수 있습니다. Databricks Docs
이 등록 방식의 장점은 크로스 소스 쿼리와 중앙 탐색입니다. 즉, 사용자는 Catalog Explorer에서 Lakehouse 자산과 Lakebase 자산을 함께 보고, 단일 SQL 인터페이스에서 함께 다루는 흐름을 만들 수 있습니다. Databricks Docs
어떤 연동 방식을 선택해야 할까?
가장 쉬운 기준은 이렇습니다.
- 분석 결과를 앱으로 보내고 싶다면 → Synced Tables (Lakehouse → Lakebase) 가 먼저입니다. Databricks Docs
- 앱에서 발생한 트랜잭션 이력을 분석계로 보내고 싶다면 → Lakehouse Sync (Lakebase → Lakehouse) 를 봐야 합니다. Databricks Docs
- 복제보다 거버넌스/탐색/쿼리 일원화가 더 중요하다면 → Unity Catalog 등록이 우선입니다. Databricks Docs
추가로, Databricks의 Lakehouse Federation은 외부 DB에 대한 실시간 연합 쿼리 패턴입니다. 다만 Databricks 문서에서는, 어떤 소스가 Federation과 Lakeflow Connect를 모두 지원할 때 더 높은 성능과 낮은 지연이 중요하면 Lakeflow Connect를 권장한다고 밝히고 있습니다. 즉, Federation은 빠른 연결/조회, Connect나 Sync는 지속적 데이터 이동/운영 연동에 가깝다고 이해하면 됩니다. Databricks Docs
추천 아키텍처: 가장 현실적인 설계 패턴
실무에서는 아래처럼 역할을 분리하는 구성이 가장 깔끔합니다.
- Lakehouse에서 고객 세그먼트, 예측값, 추천 결과 같은 “지능형 데이터”를 만든다. Databricks Docs
- 그 결과를 Synced Tables로 Lakebase에 보낸다. Databricks Docs
- 앱은 Lakebase에서 그 결과를 읽고, 사용자의 상태값·메모·처리 결과 같은 운영 상태 데이터는 별도 쓰기용 테이블에 저장한다. Databricks 공식 블로그도 synced table과 state table을 나누는 패턴을 제시합니다. Databricks Blog
- 그 쓰기용 테이블의 변경 이력은 필요에 따라 Lakehouse Sync로 다시 Lakehouse에 적재해 분석과 감사에 활용한다. Databricks Docs
이 구조의 핵심은 읽기용 동기화 테이블과 쓰기용 운영 테이블을 분리하는 것입니다. 이렇게 해야 synced table을 실수로 수정하는 문제를 피하고, 운영 무결성과 분석 일관성을 동시에 지키기 좋습니다. Databricks Docs Databricks Blog
결론: Lakebase는 “운영 앱의 마지막 마일”을 노리는 Databricks의 확장이다
정리하면, Lakebase는 단순히 “Databricks 안의 Postgres”가 아닙니다. Databricks가 그리는 그림은 Lakehouse에서 만들어진 데이터·AI 결과를 운영 애플리케이션으로 자연스럽게 연결하고, 반대로 운영 데이터의 변경도 다시 Lakehouse로 가져와 분석·모델링·거버넌스까지 하나의 플랫폼에서 돌리는 것에 가깝습니다. Databricks Databricks Blog
다만 도입 시에는 기능 성숙도, 지원 범위, 데이터 타입 제약, 스키마 변화 대응, 읽기/쓰기 분리 설계 등을 반드시 검토해야 합니다. 특히 Lakehouse Sync는 아직 제한사항이 꽤 명확하므로, “예쁘게 보이는 제품 데모”보다 내 워크로드에서 PoC가 통과하는지가 더 중요합니다. Databricks Docs
그럼에도 불구하고, 분석과 운영의 경계가 흐려지고 AI가 앱 안으로 들어가는 시대에는 Lakebase가 꽤 설득력 있는 선택지가 될 수 있습니다. 이미 Databricks를 중심으로 데이터 플랫폼을 운영 중이라면, Lakebase는 특히 추천·개인화·실시간 운영 대시보드·지원 포털·내부 업무도구 같은 영역에서 빠르게 검토해볼 만합니다. Databricks Databricks Blog
참고 자료
