124편 · 약 18분

Databricks + Electric: PGlite WASM Postgres와 Shape 동기화로 AI 에이전트마다 자체 데이터베이스를 주는 방법

요약

2026년 8월 11일 Databricks가 Electric을 인수했다. 5월 2025년의 Neon 인수(약 10억 달러 규모)에 이어 나온 두 번째 데이터베이스 관련 인수인데, 이번에는 완전히 다른 축을 노렸다. Neon이 클라우드 상의 서버리스 Postgres였다면, Electric은 에이전트 프로세스 안에서 실행되는 WASM Postgres(PGlite)와 이를 중앙 데이터베이스와 동기화하는 엔진을 만든다.

전체 그림은 이렇다. 각 AI 에이전트는 자기만의 로컬 PGlite 인스턴스를 갖는다. 도구 호출, 스크래치패드, 중간 결과, 임베딩 인덱스가 그 안에 들어간다. Electric의 Shape 동기화 엔진이 로컬 PGlite와 중앙 Lakebase Postgres를 실시간으로 이어준다. 즉 에이전트는 원격 왕복 없이 로컬 SQL을 실행하고, Lakebase는 그 모든 에이전트의 진실의 원본(source of truth) 역할을 한다.

수치가 이 방향의 실용성을 뒷받침한다. PGlite 주간 다운로드가 2025년 8월 100만 건에서 2026년 8월 1300만 건으로 12개월 동안 13배 늘었다. 개발자들이 이미 에이전트 로컬 상태 저장소로 PGlite를 사용하고 있다는 뜻이다.

이 글은 세 가지를 다룬다. (1) PGlite가 정확히 무엇이고 WASM 위에서 Postgres를 어떻게 돌리는가, (2) Electric의 Shape 동기화 엔진이 논리 복제 스트림을 어떻게 파티셔닝하고 배포하는가, (3) 에이전트 워크로드에 이 조합이 왜 적합하며 어떤 운영 경계를 갖는가.

배경: 왜 에이전트마다 데이터베이스가 필요한가

에이전트는 일반적인 요청-응답 워크로드와 다르다. 하나의 에이전트가 여러 턴에 걸쳐 상태를 축적하고, 자기 스크래치패드에서 SQL 스타일 질의를 던지고, 중간 임베딩과 검색 인덱스를 유지한다. 여러 에이전트가 동시에 병렬로 실행되면 상태를 격리해야 하고, 그러면서도 서로의 결과를 참조할 수 있어야 한다.

이 요구를 기존 인프라로 만족시키는 세 가지 흔한 방법과 각각의 한계:

방법	한계
공유 Postgres 하나에 tenant 컬럼으로 격리	매 도구 호출마다 네트워크 왕복, 락 경합, tenant 유출 위험
에이전트마다 별도 컨테이너 + Postgres	콜드 스타트 초 단위, 리소스 오버헤드 크고 스케일 어려움
Redis/DynamoDB 같은 KV 스토어	SQL 표현력 없음, 벡터 검색·조인·트랜잭션 부재

Electric의 접근은 에이전트가 실행되는 바로 그 프로세스 안에 Postgres를 넣는 것이다. WASM 덕에 별도 데몬이 필요 없고, 콜드 스타트가 밀리초 단위이며, 에이전트가 소멸하면 데이터베이스도 함께 정리된다.

PGlite: WASM에 포장된 Postgres

PGlite는 완전한 PostgreSQL을 WebAssembly로 컴파일한 결과물이다. 흔한 오해를 피해 짚어두면 다음과 같다.

아키텍처가 아닌 것

Linux VM 위에서 Postgres를 돌리는 것이 아니다.
Postgres wire protocol만 흉내내는 재구현이 아니다.
SQLite에 Postgres 문법을 얹은 어댑터가 아니다.

아키텍처가 맞는 것

Postgres 소스를 Emscripten으로 WASM 타깃 컴파일한 것.
single-user 모드로 빌드해 postmaster 없이 단일 프로세스로 동작.
TypeScript 라이브러리로 패키징돼 import만 하면 브라우저/Node.js/Bun/Deno/에이전트 샌드박스에서 즉시 실행.
Gzip 압축 후 3MB 미만.

v0.4의 구조 변경

2026년 3월 릴리스된 PGlite v0.4에서 initdb를 별도 WASM 프로세스로 분리했다. 이전에는 initdb 코드가 메인 WASM 바이너리에 포함돼 있어 첫 실행 시 큰 오버헤드를 만들었다. v0.4에서는 initdb를 별도 프로세스로 실행하고 PGlite가 시스템 콜을 인터셉트한다.

stdin/stdout을 리다이렉트해 initdb의 결과를 캡처.
Emscripten의 PROXYFS로 파일시스템을 공유해 initdb가 만든 catalog 파일을 이후 PGlite 세션이 그대로 사용.
결과: 메인 바이너리 크기 감소, 콜드 스타트 개선, initdb 코드를 수정하지 않고도 통합 가능.

지원 확장

PGlite는 확장 진입점(entry point)을 통해 여러 표준 Postgres 확장을 실행한다.

확장	용도
pgvector	임베딩 저장·검색. 에이전트의 로컬 RAG에 필수
PostGIS (v0.4+)	지리 데이터
pg_ivm	Incremental View Maintenance
Live Queries	결과 변경을 실시간 이벤트로 스트림
Worker	여러 브라우저 탭이 하나의 DB 공유

지속성

메모리, 파일시스템(Node.js), IndexedDB(브라우저), OPFS(Origin Private File System) 중 선택 가능. 에이전트 샌드박스에서는 보통 컨테이너의 tmpfs 또는 로컬 볼륨을 쓴다.

성능 실측치

간단한 CRUD 쿼리 0.3ms 미만, 큰 다중 행 SELECT도 한 프레임(≈16ms) 안에 완료. 즉 UI 스레드 블로킹 없이 실시간 반응이 가능한 수준이다.

Electric Shape 동기화 엔진

로컬 PGlite만으로는 부족하다. 여러 에이전트가 같은 상태를 봐야 하고, 결과가 중앙에 영속화돼야 한다. Electric의 Shape 동기화 엔진이 이 역할을 한다.

개념: Shape

Shape는 테이블의 부분 복제본이다. 사용자가 정의한 WHERE 절로 정의된 부분집합의 행들이 Shape를 이룬다.

-- Shape 예시
Shape("orders", where="tenant_id = 42 AND status = 'active'")
Shape("agent_scratchpad", where="agent_id = 'agent-xyz'")
Shape("shared_context", where="workspace_id = 'ws-1'")

각 에이전트는 자기와 관련된 Shape만 구독한다. 자기 워크스페이스의 문서, 자기 작업 큐의 아이템, 자기가 관심 있는 공유 컨텍스트.

데이터 흐름

중앙 Lakebase Postgres

writes here

→

Logical Replication WAL

wal2json / test_decoding

→

Electric Sync Server

WAL → Shape log

→

HTTP long-poll

per-Shape feed

→

에이전트 PGlite

local reads

Electric Shape 동기화 파이프라인

단계별로 보면:

중앙 Lakebase Postgres에 데이터가 쓰인다. 오케스트레이터, 다른 에이전트, 애플리케이션 등.
Lakebase가 논리 복제(logical replication) 슬롯을 통해 WAL을 스트림.
Electric Sync Server가 WAL 스트림을 계속 tail하며 각 변경(INSERT/UPDATE/DELETE)을 등록된 Shape들과 매치.
매치된 변경은 해당 Shape의 로그 파일에 append. Shape마다 (shape log, offset index) 두 개 파일을 유지.
클라이언트(에이전트의 PGlite)는 HTTP long-poll로 자신이 구독한 Shape의 오프셋 이후 변경분을 가져와 로컬 DB에 적용.

왜 HTTP long-poll인가

WebSocket이 아닌 HTTP를 쓴 것은 의도적이다.

캐시 가능: Shape 로그의 특정 오프셋 이전 부분은 immutable하므로 CDN/HTTP 캐시가 그대로 서빙 가능. 수많은 에이전트가 같은 워크스페이스 Shape를 구독할 때 원본 서버가 폭발하지 않는다.
방화벽 친화: 기업 네트워크에서 WebSocket이 막혀도 HTTP는 통과.
stateless: sync server가 재시작해도 클라이언트는 오프셋만 알면 이어붙일 수 있다.

Shape는 partial-replication의 세 가지 문제를 푼다

CDC 프레임워크가 오랫동안 씨름한 세 가지가 있다.

문제	Shape의 해결
어떤 행을 어느 클라이언트에 보낼지	WHERE 절로 명시적 정의
큐 백로그가 쌓이면 어떻게 catch up	Shape별 offset index로 O(1) 재시작
스키마 변경이 클라이언트를 깨지 않게	Shape 정의에 컬럼 목록도 포함, 클라이언트는 등록된 컬럼만 받음

Databricks Lakebase와의 결합

Databricks가 그리는 큰 그림은 다음과 같다.

3단 스택

Lakehouse (기존): Delta Lake·Iceberg 위의 분석·ML 워크로드.
Lakebase (Neon 인수, 2025): OLTP를 위한 서버리스 Postgres. 스토리지-컴퓨트 분리, CoW 브랜칭, sub-초 콜드 스타트.
PGlite (Electric 인수, 2026-08-11): 에이전트 프로세스 안의 Postgres. Lakebase와 Shape 동기화.

왜 이 조합이 에이전트에 특히 좋은가

트랜잭션 격리: 각 에이전트는 자기 PGlite에서 로컬 트랜잭션을 마음껏 실행하고, 커밋된 결과만 Shape로 중앙에 반영.
벡터 검색 로컬화: RAG용 임베딩을 pgvector로 로컬에 두면 매 쿼리마다 원격 벡터 DB 왕복이 사라진다.
분기(branch) 친화: Lakebase의 CoW 브랜칭과 PGlite의 in-memory 인스턴스를 결합하면, 에이전트가 가상의 "만약 이 코드가 커밋되면?" 브랜치를 만들어 실험하고 폐기하는 것이 저렴하다.
자연스러운 GC: 에이전트 프로세스가 종료되면 로컬 PGlite도 함께 사라진다. 정리 스크립트 불필요.

Databricks 로드맵

인수 발표 게시물에서 언급된 방향:

Lakebase Postgres를 Neon 및 Databricks 양쪽에서 공용 프리미티브로 유지.
Neon은 Databricks와 병행해 자체 클라우드 서비스로도 계속 존속.
Electric의 sync 엔진을 Lakebase에 통합해 클라이언트 라이브러리로 배포.
에이전트 개발자용 SDK에 PGlite를 기본 로컬 상태 저장소로 편입.

운영 관점의 경계와 주의

에이전트마다 Postgres를 준다고 해서 모든 것이 자동으로 해결되지는 않는다.

데이터 볼륨 경계

PGlite는 단일 프로세스 Postgres다. 수 GB급까지는 무리 없이 다루지만, 수십 GB 이상의 데이터는 부적절하다. 규칙:

로컬 PGlite에는 에이전트가 현재 세션에서 실제로 조회할 확률이 있는 데이터만 Shape로 sync.
콜드 데이터는 원격 Lakebase 쿼리로 필요할 때만 pull.

쓰기 경합과 컨플릭트

여러 에이전트가 같은 행에 쓰는 상황은 여전히 존재한다. Electric은 읽기 경로 sync만 완성했고, 쓰기는 두 가지 패턴 중 하나로 다룬다.

중앙 우선(write-through): 에이전트의 로컬 쓰기는 실제로는 Lakebase에 REST/gRPC로 프록시되고, 결과가 Shape로 다시 sync돼 반영된다. 컨플릭트는 서버에서 결정.
로컬 우선(offline-first, 실험적): 로컬 쓰기는 즉시 반영되고 백그라운드로 서버에 밀어넣는다. 컨플릭트 시 Last-Write-Wins 또는 사용자 정의 머지 로직.

에이전트 워크로드에서는 대체로 (1)이 안전하다. (2)는 오프라인 능력이 정말 필요한 특수 사례에 한정.

로컬 쿼리와 서버 쿼리의 의미 차이

로컬 PGlite에는 특정 Shape만 있으므로, 서버에서는 성공하는 조인이 로컬에서는 빈 결과를 낼 수 있다. Shape 정의를 잘못 잡으면 조용히 잘못된 결과가 나올 수 있다는 뜻이다. 에이전트가 사용하는 SQL을 코드 리뷰할 때 어느 Shape에 의존하는지 명시하는 관례가 필요하다.

논리 복제 슬롯 관리

Electric은 중앙 Postgres에 논리 복제 슬롯을 만들어 사용한다. 슬롯이 오래 유지되지 못하면(예: 클라이언트 연결이 끊긴 채 로그가 쌓임) Postgres의 WAL이 무한정 커진다. 운영 관점에서:

pg_replication_slots 뷰의 restart_lsn과 현재 WAL 위치 간 격차를 알림 지표로.
max_slot_wal_keep_size를 설정해 슬롯이 무한정 WAL을 붙잡지 못하게.
Electric sync server의 재시작 정책이 슬롯을 재사용하도록 검증.

보안 경계

에이전트 코드가 로컬 PGlite에 임의 SQL을 실행할 수 있다는 것은 곧 에이전트가 자기 로컬 데이터에 전권을 가진다는 뜻이다. Shape 필터가 서버 쪽에서 강제되므로 다른 tenant의 데이터가 로컬로 흘러오지는 않는다. 다만 로컬 PGlite 안에서의 오용은 에이전트 샌드박스 자체의 격리에 의존한다.

PGlite 도입 결정 트리

데이터 볼륨이 수 GB 미만인가?
  ├─ 예: 진행
  └─ 아니오: 중앙 Lakebase 직접 쿼리 사용

에이전트가 여러 턴에 걸쳐 SQL 상태를 축적하는가?
  ├─ 예: PGlite 유용
  └─ 아니오: Redis/DynamoDB 같은 KV로 충분할 수 있음

벡터 검색·조인·트랜잭션 같은 SQL 표현력이 필요한가?
  ├─ 예: PGlite가 명확한 승리
  └─ 아니오: 재검토 필요

에이전트 프로세스 수명이 초~분 단위인가?
  ├─ 예: PGlite 콜드 스타트가 잘 맞음
  └─ 아니오(밀리초 단위 요청-응답): 오버헤드 대비 이득 재검토

다른 에이전트/서비스와 상태 공유가 필요한가?
  ├─ 예: Shape 동기화 필요
  └─ 아니오: PGlite만 임베드해서 사용

도입 체크리스트

[ ] PGlite에 담을 데이터의 예상 볼륨을 세션 종료 시점 기준으로 추정했는가 (수 GB 미만인가)
[ ] 각 에이전트가 구독해야 할 Shape 목록을 명시적으로 문서화했는가
[ ] Shape의 WHERE 절이 tenant/워크스페이스 격리를 강제하는지 검증했는가 (Shape 정의는 곧 데이터 접근 경계)
[ ] 쓰기 경로를 서버 프록시(write-through)로 갈지, 로컬 우선(offline-first)으로 갈지 정책 결정했는가
[ ] Lakebase 쪽 논리 복제 슬롯 지연·WAL 축적을 관측하는 대시보드가 있는가
[ ] Electric sync server의 재시작·페일오버 시 슬롯이 재사용되고 클라이언트가 오프셋 이어붙이기 성공하는지 실측 테스트했는가
[ ] 에이전트 샌드박스 종료 시 로컬 PGlite 정리가 자동으로 되는지 확인했는가 (또는 볼륨 사용량 모니터링)
[ ] 로컬 쿼리와 중앙 쿼리 결과가 어긋날 수 있는 케이스를 코드 리뷰 체크리스트에 넣었는가

열린 질문

컨플릭트 해결의 표준화

에이전트 여럿이 같은 행을 쓰는 문제는 Electric이 완전히 풀지 않는다. LWW·CRDT·서버 결정 중 어느 것이 에이전트 워크로드에 적합한지는 아직 실증적 답이 부족하다.

파티션된 Shape의 스케일 상한

한 Shape에 수백만 행이 붙으면 로그 파일이 커지고 HTTP long-poll의 초기 catch-up 비용이 증가한다. Sharding된 Shape나 계층 Shape 같은 확장이 필요할 수 있다.

PGlite 병렬 처리

WASM 단일 프로세스라는 특성상 병렬 쿼리 실행이 제한적이다. 큰 분석 쿼리를 로컬에서 돌리려는 시도는 결국 중앙 Lakebase로 위임돼야 한다. 경계선을 어디에 그을지가 실무적 논점.

Neon과 Electric의 로드맵 정렬

두 팀이 Databricks 안에서 어떻게 조율될지, 특히 PGlite와 Lakebase 클라이언트 라이브러리가 분리·통합될지는 아직 공식 발표 부족.

정리

Databricks의 Electric 인수(2026-08-11)는 OLTP 데이터베이스의 물리적 경계를 에이전트 프로세스 안까지 확장하겠다는 의도다. PGlite는 완전한 Postgres를 3MB 미만의 WASM 바이너리로 컴파일해 어디서든 임베드할 수 있게 하고, Electric Shape 동기화 엔진은 논리 복제 스트림을 부분 복제본 단위로 나눠 HTTP long-poll로 배포한다.

에이전트 워크로드에는 이 조합이 자연스럽다. 각 에이전트가 자기 로컬 상태를 트랜잭션과 벡터 검색을 포함한 완전한 SQL로 다루고, 필요한 부분만 중앙 Lakebase와 실시간 동기화된다. 12개월 동안 주간 다운로드 100만에서 1300만으로 늘어난 PGlite의 성장 곡선은, 이 방향이 이미 개발자 커뮤니티에서 자생적으로 확산되고 있었다는 방증이다.

운영 관점에서는 데이터 볼륨 경계, 쓰기 경합, 논리 복제 슬롯 관리, Shape 정의의 정확성이 실무 관심사다. 이 항목들을 정리한 체크리스트를 사용해, "에이전트마다 데이터베이스"라는 새 패러다임을 안전하게 도입할 수 있다.

References

Databricks Blog — Electric joins Databricks to bring WASM Postgres to AI agent sandboxes: https://www.databricks.com/blog/electric-joins-databricks-bring-wasm-postgres-ai-agent-sandboxes
Electric — Electric is joining Databricks (2026-08-11): https://electric.ax/blog/2026/08/11/electric-joining-databricks
Neon Blog — Electric is joining team Neon at Databricks: https://neon.com/blog/electric-joins-neon
PGlite documentation — About: https://pglite.dev/docs/about
PGlite Extensions — pgvector, PostGIS, pg_ivm, Live Queries, Worker: https://pglite.dev/extensions/
Electric — Announcing PGlite v0.4: PostGIS, connection multiplexing, and a new architecture: https://electric.ax/blog/2026/03/25/announcing-pglite-v04
Electric — Postgres Sync architecture: https://electric.ax/sync/postgres-sync
Neon Docs — The lakebase architecture: https://neon.com/docs/introduction/architecture-overview
The New Stack — Databricks acquires Electric to give every AI agent its own Postgres database: https://thenewstack.io/databricks-electric-wasm-agentic-postgres/
QueryPlane Blog — ElectricSQL: How Postgres Real-Time Sync Works: https://queryplane.com/blog/electricsql-postgres-sync-engine/