PostgreSQL에도 Vitess가 온다 — Supabase가 5억 달러와 함께 푼 Multigres

한 줄 요약

2026-06-04, Supabase(수파베이스)가 시리즈 F로 5억 달러를 유치해 105억 달러 밸류를 찍었고, 같은 날 PostgreSQL 수평 확장 오픈소스 레이어 Multigres를 프리뷰로 공개했다. 핵심은 한 줄로 줄어든다 — MySQL 진영에서 sharding 표준이 된 Vitess를, 그 공동 창시자가 PostgreSQL로 옮겨 온다.

Multigres는 PostgreSQL 앞단에 붙는 proxy 레이어다. 단일 인스턴스 한계에 부딪힌 팀이 다른 데이터베이스로 마이그레이션하지 않고도, 익숙한 PostgreSQL 생태계를 그대로 둔 채 sharding까지 늘려 가도록 하는 것이 목표다.

무엇을 발표했나

발표를 사실 단위로 끊어 정리한다. 1차 출처는 PR Newswire 보도자료와 Supabase 공식 블로그다.

회사가 밝힌 성장 수치도 같이 나왔다. CEO Paul Copplestone는 시리즈 E 이후 사용자 기반이 두 배 넘게 늘었고, 데이터베이스 수가 전년 대비 600% 증가했다고 했다. 고객 25만 곳 이상, 개발자 900만 명 규모다.

자금 발표와 한 묶음으로 나온 것이 Multigres다. Apache 2.0 라이선스로 공개됐고, 지금은 안정화에 집중하는 프리뷰 단계라 외부 기여는 아직 열지 않았다. 파트너 프로그램 신청만 받는다.

Multigres가 뭔가 — Vitess를 PostgreSQL로

Multigres를 한마디로 줄이면 “Vitess for Postgres”다. 이 문구가 비유에 그치지 않는 이유는, 프로젝트를 이끄는 사람이 Vitess 공동 창시자 Sugu Sougoumarane(수구 수구마라네)이기 때문이다.

Vitess는 YouTube가 MySQL을 페타바이트 규모로 굴리려고 만든 sharding 미들웨어다. 이후 CNCF 졸업 프로젝트가 됐고, PlanetScale 같은 서비스의 바탕이 됐다. MySQL 진영에서 “단일 인스턴스를 넘어선다"는 문제의 사실상 표준 답이다. Sugu는 “한동안 Vitess를 PostgreSQL로 적응시키는 걸 고민해 왔다”며, 그 적응판으로 Multigres를 내놨다.

아키텍처는 Vitess의 2단 proxy 구조를 그대로 가져온다. Vitess의 vtgate·vttablet에 대응하는 두 컴포넌트가 있다.

• MultiGateway: 분산 클러스터를 애플리케이션에서 단일 PostgreSQL 서버처럼 보이도록 묶는다. query routing, cross-shard 쿼리의 scatter-gather, 장애 차단을 담당한다.
• MultiPooler: 개별 PostgreSQL 인스턴스 옆에 붙어 connection pooling과 조율을 맡는다.

여기에 분산 조율을 위한 etcd, 컴포넌트 간 통신을 위한 gRPC가 붙어 Kubernetes 배포를 전제한 cloud-native 구성을 이룬다.

flowchart TD
    APP["애플리케이션"]
    GW["MultiGateway
(query routing)"]
    P1["MultiPooler"]
    P2["MultiPooler"]
    P3["MultiPooler"]
    S1["PostgreSQL
shard 1"]
    S2["PostgreSQL
shard 2"]
    S3["PostgreSQL
shard 3"]
    ETCD["etcd
(topology)"]

    APP -->|단일 서버처럼| GW
    GW --> P1 --> S1
    GW --> P2 --> S2
    GW --> P3 --> S3
    GW -.조율.-> ETCD

흥미로운 건 PostgreSQL이 MySQL보다 sharding 미들웨어를 얹기에 유리한 지점이 있다는 점이다. Sugu는 BigGo 인터뷰에서 PostgreSQL의 transactional DDL을 두고 “transactionless DDL을 다루는 게 MySQL에서 얼마나 악몽이었는지 모른다. transactional DDL은 Vitess에 꿈같은 일"이라고 했다. two-phase commit API도 PostgreSQL 쪽이 더 깔끔하다고 평가했다.

반대로 PostgreSQL이라서 까다로운 지점도 있다. pgvector, PostGIS 같은 extension이 커스텀 타입과 index를 들고 오는데, sharding 레이어 입장에서는 여기서 PostgreSQL만의 호환성 문제가 생긴다. proxy가 모든 쿼리를 가로채 분배해야 하는데, extension이 만든 비표준 동작까지 이해해야 하기 때문이다. Supabase가 호환성을 최우선 과제로 못 박은 배경이다.

기존 Citus와 무엇이 다른가

PostgreSQL 수평 확장이라면 이미 Citus가 있다. Microsoft가 인수해 Azure Cosmos DB for PostgreSQL의 바탕이 됐고, 오픈소스로도 쓸 수 있다. 그렇다면 Multigres는 왜 또 만드는가. 가장 큰 차이는 sharding을 어느 층에서 구현하느냐다.

Citus는 extension 방식이다. PostgreSQL 안에 들어가 planner와 executor에 후크를 걸어 분산 쿼리를 처리한다. Multigres는 proxy 방식이다. PostgreSQL 바깥에 별도 레이어로 서서 쿼리를 가로채 shard로 분배한다. 이 한 줄 차이가 운영 성격을 갈라놓는다.

extension 방식은 PostgreSQL과 한 몸이라 쿼리 최적화가 깊게 들어가는 대신, 엔진 버전·빌드에 종속된다. proxy 방식은 각 shard가 손대지 않은 표준 PostgreSQL이라 extension·도구 생태계를 그대로 쓰고 버전 정책도 비교적 자유로운 대신, cross-shard 쿼리는 바깥 레이어가 풀어야 하니 그 영리함에 성패가 갈린다. Vitess가 MySQL에서 이 방식으로 검증된 길을 닦았다는 게 Multigres가 기대를 받는 이유다.

DBA 관점 — 지금 당장 의미 있나

결론부터: 지금 당장 프로덕션에 올릴 물건은 아니다. 프리뷰이고 외부 기여조차 닫혀 있다. 하지만 방향만큼은 DBA가 지금 읽어 둘 가치가 있다.

첫째, sharding 레이어가 생긴다는 건 “PostgreSQL을 떠나지 않아도 된다"는 선택지가 늘어난다는 뜻이다. 지금까지 단일 인스턴스 한계에 부딪힌 팀은 선택이 거칠었다. read replica로 읽기를 분산하거나, 애플리케이션 단에서 직접 shard를 쪼개거나, 아예 다른 분산 데이터베이스로 마이그레이션하거나. Multigres가 노리는 건 그 사이의 빈칸이다. connection pooling부터 시작해 high availability를 거쳐 sharding까지, 같은 레이어 위에서 단계적으로 올라가는 on-ramp를 약속한다.

둘째, proxy 방식은 운영 토폴로지가 한 겹 늘어난다는 뜻이기도 하다. MultiGateway·MultiPooler·etcd가 새로 생기고, 각각이 장애 지점이자 모니터링 대상이 된다. Vitess를 운영해 본 팀이라면 익숙한 그림이지만, “PostgreSQL 한 대 + replica” 수준으로 운영해 온 팀에는 완전히 다른 운영 부담이다. sharding이 공짜가 아니라는 건 어느 진영에서나 똑같다. shard key 설계를 잘못하면 hot shard가 생기고, cross-shard 조인은 여전히 비싸다.

셋째, 자금력과 맥락을 짚어 둘 필요가 있다. Supabase는 이번 라운드를 “agentic 인프라"라는 키워드로 포장했다. agent가 데이터베이스를 대량으로 생성·소비하는 패턴이 늘면 단일 인스턴스로는 감당이 안 되고, 그래서 수평 확장이 필요하다는 서사다. 같은 흐름은 Neon이 백엔드 플랫폼으로 확장한 발표에서도 읽힌다. PostgreSQL 회사들이 5억~10억 달러 단위 자금을 들고 “AI 시대의 데이터베이스 기반"을 두고 경쟁하는 국면이고, Multigres는 그 경쟁에서 Supabase가 꺼낸 장기 베팅이다. 5억 달러는 8년 넘게 걸릴 수도 있는 sharding 레이어를 끝까지 밀어붙일 실탄이다.

언제 쓸 만해질까. 현실적으로는 Multigres가 안정화를 끝내고 외부 기여를 열어, 누군가의 프로덕션에서 cross-shard 쿼리와 zero-downtime 마이그레이션이 실제로 검증되는 시점이다. 그때까지는 Vitess가 MySQL에서 걸어온 길이 PostgreSQL에서도 재현될지 지켜보는 단계다. 분명한 건, “PostgreSQL은 수평 확장이 약하다"는 오래된 명제에 대형 자본과 검증된 설계자가 정면으로 답을 내기 시작했다는 점이다.

출처:

• Supabase Raises $500M at $10.5B (PR Newswire)
• Announcing Multigres: Vitess for Postgres (Supabase 블로그)
• Multigres 공식 사이트
• Vitess Co-Creator on Multigres Technical Challenges (BigGo)