Supabase Multigres
2026-06-04, Supabase(수파베이스)가 시리즈 F로 5억 달러를 유치해 105억 달러 밸류를 찍었어요. 같은 날 PostgreSQL 수평 확장 오픈소스 레이어 Multigres를 프리뷰로 공개했어요. 한 줄로 줄이면, MySQL 진영에서 sharding 표준이 된 Vitess를 그 공동 창시자가 PostgreSQL로 옮겨 오는 일이에요.
Multigres는 PostgreSQL 앞단에 붙는 proxy 레이어입니다. 단일 인스턴스 한계에 부딪힌 팀이 다른 데이터베이스로 마이그레이션하지 않고도, 익숙한 PostgreSQL 생태계를 그대로 둔 채 sharding까지 늘려 가도록 하는 것이 목표입니다.
5억 달러와 Multigres, 한 묶음의 발표
사실관계부터 항목별로 짚어 봅니다. 1차 출처는 PR Newswire 보도자료와 Supabase 공식 블로그입니다.
| 항목 | 내용 |
|---|---|
| 라운드 | 시리즈 F |
| 유치액 | 5억 달러 |
| 밸류 | 105억 달러(post-money) |
| 리드 투자자 | GIC |
| 기존 투자자 | Accel, Y Combinator, Craft, Felicis, Peak XV, Coatue |
| 신규/추가 | Stripe(추가 투자), Salesforce Ventures(신규) |
| 누적 유치 | 10억 달러 이상 |
| 시점 | 시리즈 E 7개월 만 |
회사가 밝힌 성장 수치도 같이 나왔습니다. CEO Paul Copplestone는 시리즈 E 이후 사용자 기반이 두 배 넘게 늘었고, 데이터베이스 수가 전년 대비 600% 증가했다고 했습니다. 고객 25만 곳 이상, 개발자 900만 명 규모입니다.
자금 발표와 한 묶음으로 나온 것이 Multigres입니다. Apache 2.0 라이선스로 공개됐고, 지금은 안정화에 집중하는 프리뷰 단계라 외부 기여는 아직 열지 않았습니다. 파트너 프로그램 신청만 받습니다.
Vitess를 PostgreSQL로 옮긴 Multigres
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 구성을 이룹니다.
흥미로운 건 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와 갈리는 지점, extension이냐 proxy냐
PostgreSQL 수평 확장이라면 이미 Citus가 있습니다. Microsoft가 인수해 Azure Cosmos DB for PostgreSQL의 바탕이 됐고, 오픈소스로도 쓸 수 있습니다. 그렇다면 Multigres는 왜 또 만드는지 살펴볼 필요가 있습니다. 가장 큰 차이는 sharding을 어느 층에서 구현하느냐입니다.
Citus는 extension 방식입니다. PostgreSQL 안에 들어가 planner와 executor에 후크를 걸어 분산 쿼리를 처리합니다. Multigres는 proxy 방식입니다. PostgreSQL 바깥에 별도 레이어로 서서 쿼리를 가로채 shard로 분배합니다. 이 한 줄 차이가 운영 성격을 갈라놓습니다.
| 항목 | Citus | Multigres |
|---|---|---|
| 방식 | extension(엔진 내부) | proxy(엔진 외부) |
| PostgreSQL 본체 | 패치된 빌드/extension 필요 | 표준 PostgreSQL 그대로 |
| 모태 | 자체 설계 | Vitess 아키텍처 적응 |
| 버전 추종 | extension이 엔진 버전에 종속 | 표준 인스턴스라 비교적 독립 |
| 성숙도 | 프로덕션 다년 검증 | 프리뷰(2026-06 공개) |
| 라이선스 | AGPL 계열 | Apache 2.0 |
| 운영 단위 | coordinator + worker 노드 | MultiGateway + MultiPooler + shard |
extension 방식은 PostgreSQL과 한 몸이라 쿼리 최적화가 깊게 들어가는 대신, 엔진 버전/빌드에 종속됩니다. proxy 방식은 각 shard가 손대지 않은 표준 PostgreSQL이라 extension/도구 생태계를 그대로 쓰고 버전 정책도 비교적 자유로운 대신, cross-shard 쿼리는 바깥 레이어가 풀어야 하니 그 영리함에 성패가 갈립니다. Vitess가 MySQL에서 이 방식으로 검증된 길을 닦았다는 게 Multigres가 기대를 받는 이유입니다.
지금은 방향만 읽어 두면 된다
결론부터 말하면 지금 당장 프로덕션에 올릴 물건은 아닙니다. 프리뷰이고 외부 기여조차 닫혀 있습니다. 하지만 방향만큼은 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은 수평 확장이 약하다"는 오래된 명제에 대형 자본과 검증된 설계자가 정면으로 답을 내기 시작한 것은 분명해요.