본문으로 건너뛰기

"Neon" 태그로 연결된 2개 게시물개의 게시물이 있습니다.

모든 태그 보기

Neon 백엔드 플랫폼 확장

· 약 7분

짧게 먼저

2026-05-28, Neon(네온)이 "우리는 앱과 agent를 위한 boring backend를 만든다"는 글을 내고 같은 주 changelog로 세 가지 신규 서비스를 예고했어요. PostgreSQL 한 제품으로 출발한 회사가 자기 무기인 branch를 데이터베이스 밖으로 끌고 나가, 스토리지와 compute와 AI 라우팅까지 같은 모델로 묶기 시작했어요.

세 서비스는 오브젝트 스토리지(Object Storage), 서버리스 compute(Compute), AI Gateway입니다. 셋 다 아직 "coming soon"이지만 방향은 분명합니다. Neon은 더 이상 자기를 "서버리스 PostgreSQL"로만 규정하지 않습니다. PostgreSQL 30년 산업사 글에서 정리한 "클라우드 베어의 시대" 흐름이, 이번에는 PostgreSQL 회사 한 곳이 백엔드 플랫폼으로 몸집을 키우는 형태로 다시 나타났습니다.

예고된 세 가지 서비스

발표 내용을 사실 단위로 끊어 봅니다. 1차 출처는 Neon 공식 블로그(Bryan Clark, VP Product)와 changelog입니다.

서비스상태한 줄 정의핵심 성질
Database출시됨서버리스 PostgreSQLbranch/서버리스의 출발점
Auth출시됨내장 인증백엔드 기본 블록
Data API출시됨REST/HTTP 접근코드 없이 데이터 노출
Object Storagecoming soonDB와 함께 branch되는 S3 호환 스토리지DB/파일 상태를 branch마다 동기화
Computecoming soonDB 옆에 붙는 서버리스 compute인프라 관리 없이 함께 확장
AI Gatewaycoming soon모델 라우팅, 로깅, 비용 통제Databricks 인프라 위에 구동

세 신규 서비스를 묶는 한 문장은 Neon이 직접 말합니다. 모든 서비스가 "instant, branchable, serverless"라는 것입니다. branch가 DB만의 기능이 아니라 플랫폼 전체의 기본 동작이 된다는 선언입니다.

AI Gateway 쪽에는 숫자 하나가 붙습니다. Neon은 이 Gateway가 "Databricks에서 월 125조 토큰을 처리하는 같은 인프라 위에 올라간다"고 적었습니다. 2025년 5월 Databricks(데이터브릭스)가 Neon을 인수한 뒤, 모회사의 운영 규모를 그대로 끌어쓰는 자리입니다.

1초 만에 끝나는 branch의 원리

이 발표를 이해하려면 Neon의 branch가 어떻게 동작하는지부터 짚어야 합니다. 일반적인 PostgreSQL 호스팅에서 "테스트용 사본"을 만들려면 pg_dump로 받아 다른 인스턴스에 복원하거나, 스냅샷에서 새 볼륨을 띄웁니다. 데이터가 클수록 시간과 비용이 선형으로 늘어납니다.

Neon의 branch는 다릅니다. storage 계층에서 copy-on-write로 동작합니다. branch를 만드는 순간 데이터를 복사하지 않고, 부모 branch의 WAL 히스토리 특정 시점을 가리키는 메타데이터 포인터만 만듭니다. 페이지는 수정될 때 비로소 branch 쪽에 따로 기록됩니다. 그래서 branch 생성은 데이터 크기와 무관하게 O(1)이고, 1초 안에 끝납니다.

Neon은 이 branch가 하루에 수천만 개씩 생성된다고 밝혔습니다. 사람이 만드는 양이 아닙니다. CI에서 PR마다, agent가 작업마다 격리된 환경을 띄웠다 지우는 패턴이 깔려 있다는 뜻입니다. branch를 "만들고 쓰고 버리는" 일회성 자원으로 보는 시각이 이미 자리 잡았습니다.

branch가 DB 밖으로 나간다는 것

이번 발표가 겨냥한 지점이 여기입니다. branch가 데이터베이스 안에만 있으면 반쪽짜리입니다. 현실의 애플리케이션은 DB만으로 돌지 않습니다 — 업로드된 파일은 오브젝트 스토리지에 있고, 백그라운드 작업은 compute에서 돌며, AI 기능은 외부 모델을 호출합니다. DB만 branch되고 나머지가 production을 공유하면, 격리는 깨집니다.

예를 들어 보겠습니다. 결제 영수증 PDF를 S3에 올리는 기능을 고치는 중이라고 가정하겠습니다. DB는 branch로 격리했는데 스토리지는 production 버킷을 그대로 쓴다면, 테스트로 만든 가짜 영수증이 실제 버킷에 섞입니다. compute도 마찬가지입니다. branch DB를 바라봐야 할 워커가 production 큐를 집어 들면 격리가 무의미해집니다.

Neon의 답은 단순합니다. branch를 만들 때 DB뿐 아니라 스토리지/compute가 함께 갈라지게 합니다. 오브젝트 스토리지는 "DB와 함께 branch되어 모든 branch에서 데이터와 스토리지가 동기 상태를 유지"하고, compute는 "DB 옆에 배치되는 서버리스" 형태로 같이 따라옵니다.

같은 copy-on-write 사고를 백엔드 기본 블록 전체로 넓힌 것입니다. DB 한 줄만 격리하던 환경이, 이제 파일과 연산까지 통째로 격리되는 환경으로 넓어집니다.

직접 굴리는 조합과 갈리는 지점

운영자 시각에서 차이를 표로 정리합니다. 비교 대상은 "직접 굴리는 PostgreSQL + 별도 오브젝트 스토리지 + 별도 워커"의 전통 조합입니다.

항목전통 PG 호스팅 조합Neon 백엔드 플랫폼
DB 사본 생성pg_dump/스냅샷, 크기에 비례branch, 1초/O(1)
스토리지 격리버킷 수동 분리/복사DB와 함께 자동 branch
compute 격리별도 인스턴스 프로비저닝DB 옆 서버리스 자동
AI 모델 호출직접 연동/자체 비용 추적Gateway가 라우팅, 로깅, 비용 통제
환경 단위DB, 스토리지, compute 각각branch 하나로 묶음
통합 책임운영자가 봉합플랫폼이 봉합

전통 조합은 각 계층을 운영자가 직접 잇습니다. 그만큼 통제권은 크지만, 환경 하나를 새로 깔 때마다 손이 많이 갑니다. Neon은 그 봉합을 플랫폼이 가져가는 대신 계층 선택의 자유를 줄입니다. 어느 쪽이 맞는지는 워크로드가 정하고, 여기에는 분명한 lock-in 비용이 따릅니다.

편의를 얻는 만큼 묶이는 비용을 계산한다

플랫폼이 편의를 가져가면 그만큼 묶이는 비용이 생깁니다. 운영자 관점에서 짚을 지점을 추립니다.

  • lock-in의 폭이 넓어집니다. DB만 Neon에 둘 때와, 스토리지, compute, AI 라우팅까지 둘 때의 이탈 비용은 다릅니다. branch가 묶어 주는 편의가 클수록, 빠져나올 때 풀어야 할 매듭도 많아집니다. PostgreSQL 30년 글에서 인용한 Christophe Pettus(크리스토프 페투스)의 한 줄, "이미 쓰는 데이터 플랫폼이 선택을 대신했다"가 여기에 그대로 적용됩니다.
  • AI Gateway는 표준 PostgreSQL 영역 밖입니다. 모델 라우팅/비용 통제는 PostgreSQL 호환성과 무관한 독자 기능입니다. 이 자리는 pg_dump나 logical replication으로 옮겨지지 않습니다. 의존하기 전에 대체 경로를 먼저 확인해야 합니다.
  • 세 서비스 모두 아직 예고 단계라는 점도 무게를 둡니다. 운영 결정은 정식 출시, SLA, 요금이 공개된 다음에 내려도 늦지 않습니다. 발표 시점에 확정된 것은 방향이지 가용성이 아닙니다.
  • AI Gateway가 모회사 인프라 위에 올라간다는 점은 규모의 강점이자 결합의 신호입니다. Neon Serverless PostgreSQL과 Databricks Lakebase(레이크베이스)가 같은 엔진을 공유한다는 구조도 함께 봅니다.

산업사 흐름에서 본 위치

PostgreSQL 30년 글은 2025년을 "클라우드 베어의 시대"로 불렀습니다. Databricks가 Neon을, Snowflake(스노우플레이크)가 Crunchy Data(크런치 데이터)를 가져간 분기입니다. 그 글의 진단은 "AI agent를 위한 PostgreSQL"이었습니다. Neon의 branch 모델이 agent가 매 작업마다 격리된 DB를 띄우기에 맞는다는 이유였습니다.

이번 발표는 그 진단의 다음 장입니다. Neon은 "agent를 위한 PostgreSQL"에서 "agent를 위한 백엔드 전체"로 범위를 넓혔습니다. 발표 글의 표현을 빌리면 "agent-native cloud는 마법보다 boring한 기본기 — 신원, 권한, 로그, 롤백, 비용 통제 — 가 먼저 필요하다". DB 회사가 백엔드 플랫폼을 지향할 때 내거는 명분이 바로 이 자리입니다.

이 흐름은 Neon만의 것이 아닙니다. Supabase(수파베이스)는 처음부터 PostgreSQL + 인증 + 스토리지 + 함수를 한 묶음으로 팔아 온 회사입니다. Neon이 늦게 같은 무대로 올라왔지만 무기는 다릅니다. Neon은 자기 고유의 branch 모델을 백엔드 전 계층에 바르는 방식으로 차별화를 시도합니다. PostgreSQL을 코어로 둔 회사들이 "DB 벤더"에서 "백엔드 플랫폼"으로 수렴하는 큰 그림은 같습니다.

정리

발표 전의 Neon은 자기를 서버리스 PostgreSQL로 규정했고 branch는 DB 안에만 있었습니다. 이번 발표 이후 그 회사는 백엔드 플랫폼을 지향하고, branch 범위는 스토리지와 compute까지 넓어지며, AI는 pgvector 같은 DB 내부 기능이 아니라 Gateway로 분리/외부화됩니다. 운영자 관점에서 보면 DB 한 계층에 대한 의존이 백엔드 여러 계층에 대한 의존으로 커집니다.

정리하면 Neon은 branch를 데이터베이스 밖으로 끌고 나갔습니다. 스토리지와 compute가 DB와 함께 갈라지면 환경 하나를 통째로 격리하는 일이 명령 한 줄로 끝나는데, 이건 운영자에게 편의이자 결합입니다. 봉합 비용을 플랫폼에 넘기는 대신 계층 선택의 자유를 일부 내줍니다.

다만 세 서비스가 아직 예고 단계라는 점은 잊지 말아야 해요. 방향은 분명하지만 가용성, 요금, SLA는 아직이에요.

참고

PostgreSQL 30년사

· 약 16분

들어가며

2025년 6월 2일, Snowflake(스노우플레이크)가 Crunchy Data(크런치 데이터)를 약 2억 5천만 달러에 인수했고, 2025년 5월에는 Databricks(데이터브릭스)가 Neon(네온)을 10억 달러 안팎으로 가져갔어요. Microsoft(마이크로소프트)는 자체 Postgres 변형 HorizonDB를 들고나왔어요. 2026년 5월 현재, "PostgreSQL을 쓴다"는 말은 점점 모호해졌어요. Snowflake Postgres인가, Lakebase인가, HorizonDB인가, 아니면 그냥 PostgreSQL인가요.

이 글은 30년에 걸친 PostgreSQL 회사들의 인수와 이별, 그리고 그 사이를 혼자 걸어온 컨설턴트/메인테이너들의 이야기입니다. 사실에 기반해 풀고, 마지막에는 다음 5년을 가늠해 보겠습니다.

한 장으로 보는 흐름

본문으로 들어가기 전, 큰 패턴을 표 하나로 깔아둡니다.

시기흐름대표 사건
1986~1999학교 프로젝트 → 오픈소스UC Berkeley POSTGRES, 1996 PostgreSQL
2002~2009PG 전용 회사 출현2ndQuadrant, EDB, PGX
2010~20151차 클라우드 인수Heroku→Salesforce, EMC→Greenplum
2016~20192차 인수 + 새 시장Microsoft→Citus, OpenSCG→AWS, Supabase/Aiven
2020~2023PG 회사들의 통합EDB→2ndQuadrant, Bain Capital→EDB
2024상실Simon Riggs 사망, xz backdoor, Greenplum closed-source
2025클라우드 베어 시대Databricks→Neon, Snowflake→Crunchy, HorizonDB
2026자금 단절의 그림자pgBackRest archive, 다중 스폰서 모델

표를 위에서 아래로 따라 읽으면 한 가지 패턴이 보입니다. PG 회사가 클라우드 회사에 흡수되는 주기가 점점 짧아집니다. Salesforce→Heroku에서 Microsoft→Citus까지 9년, Microsoft→Citus에서 Databricks→Neon까지 6년입니다.

이제 각 시기를 풀어씁니다.

Act 1. 1996~2010

학교 프로젝트가 살아남은 시기입니다.

PostgreSQL의 출발은 UC Berkeley(버클리)의 POSTGRES (1986)입니다. Michael Stonebraker(마이클 스톤브레이커)가 INGRES의 후속으로 시작한 프로젝트가 1995년 SQL 인터페이스를 도입하며 PostgreSQL이라는 이름을 얻었고, 1996년 첫 정식 릴리스가 나왔습니다. 이 시기 합류한 사람들이 이후 30년의 형태를 만들었습니다.

Tom Lane(톰 레인)은 1996년 무렵부터 활동했습니다 — PostgreSQL 역사에서 가장 많은 commit을 한 사람입니다. 17년간 Red Hat(레드햇)에서 일하다 Salesforce(세일즈포스)를 거쳐 2015년 Crunchy Data로 옮겼습니다. Crunchy는 그에게 PostgreSQL에 100% 시간을 쏟을 자리를 마련해 줬습니다.

Bruce Momjian(브루스 모미얀)은 PostgreSQL 거버넌스의 대변자입니다. 2006년 EDB(EnterpriseDB, 엔터프라이즈DB)에 합류해 지금까지 같은 자리에 있습니다. PostgreSQL 라이선스의 BSD-스타일 약속을 가장 자주 옹호하는 사람이기도 합니다.

1997년에는 Joshua Drake(조슈아 드레이크)가 미국 몬태나에 Command Prompt(커맨드 프롬프트)를 차렸습니다. 2026년 현재까지 살아남은 PostgreSQL 컨설팅 회사입니다.

회사 쪽 흐름은 두 갈래로 갈렸다:

EDB는 2004년 Andy Astor(앤디 애스터), Denis Lussier(데니스 루시에르), Paul T. Winn(폴 윈), Phillip Merrick(필립 메릭)가 설립했습니다. 처음부터 "엔터프라이즈용 PostgreSQL"을 표방했고 Oracle(오라클) 호환성에 무게를 뒀습니다.

2ndQuadrant(세컨드쿼드런트)는 2002년 Simon Riggs(사이먼 릭스)가 영국/이탈리아에 설립했습니다. 설립자가 PITR, Hot Standby, 동기화 replication을 만든 사람이라 회사 자체가 "코어 기능 공급자"였습니다.

2009년에는 Christophe Pettus(크리스토프 페투스)가 PGX(PostgreSQL Experts)를 차렸습니다. The Build(더 빌드) 블로그가 이 회사의 채널입니다.

이 시기 클라우드는 아직 변두리였습니다. 2010년 12월, Salesforce가 Heroku(헤로쿠)를 약 2억 1,200만 달러에 인수했습니다. Heroku는 그해 11월에 PostgreSQL을 도입했고, 다음 해 11월 "Heroku Postgres"를 분리 제품으로 내놨습니다. Ruby/Python 개발자가 PostgreSQL을 "기본"으로 받아들이기 시작한 순간이었습니다.

Act 2. 2011~2019

클라우드가 책을 다시 쓴 시기입니다.

이 시기 PostgreSQL 회사들은 두 가지 길을 갔습니다. 하나는 클라우드 벤더에 흡수되는 길이고, 다른 하나는 새로운 시장을 만드는 길이었습니다.

흡수된 쪽:

OpenSCG → AWS(2018년 4월경)는 Denis Lussier가 만든 마이그레이션 서비스 회사의 인수 사례입니다. 회사는 AWS의 Database Migration Service에 흡수됐습니다.

Citus Data(사이터스 데이터) → Microsoft(2019-01-24)는 Y Combinator(Y 컴비네이터) S11 출신 회사의 인수 사례입니다. 이 회사는 분산 PostgreSQL extension을 만들었습니다. Microsoft가 인수한 뒤 Azure Database for PostgreSQL Hyperscale (현 Cosmos DB for PostgreSQL)로 이름이 바뀌었으며, 금액은 공개되지 않았습니다.

EDB의 자본 회전도 이어졌습니다. 2014년 Peak Equity Partners(피크 에쿼티 파트너스), 2019년 Great Hill Partners(그레이트 힐 파트너스)가 차례로 EDB의 다수 지분을 가져갔습니다.

새로 만들어진 쪽:

Crunchy Data는 2012년 Bob Laurence/Paul Laurence(폴 로런스) 형제가 창업했으며, 규제 산업/연방 정부 시장에 무게를 뒀습니다. Timescale(타임스케일)은 2015년 PostgreSQL extension으로 시계열 워크로드를 잡았습니다. Aiven(아이븐)은 2016년 핀란드 출신 3인(Oskari Saarenmaa(오스카리 사렌마), Hannu Valtonen(한누 발토넨), Heikki Nousiainen(헤이키 노우시아이넨))이 만든 관리형 오픈소스 플랫폼입니다. 2022년 시리즈 D 2억 1,000만 달러까지 모았습니다. Supabase(수파베이스)는 2020년 Paul Copplestone(폴 코플스톤)/Ant Wilson(앤트 윌슨)이 설립했습니다. "Firebase(파이어베이스)의 오픈소스 대안"이라는 슬로건으로 시작했지만, 본질은 관리형 PostgreSQL + BaaS입니다.

이 시기 가장 묵직한 인물 이동은 Andres Freund(안드레스 프룬트)입니다. 그는 Microsoft Azure Postgres 팀으로 옮겨갔고, 2024년 3월 PostgreSQL을 Debian Sid에서 벤치마킹하다가 SSH 로그인이 500ms 늦은 것을 눈치챘습니다 — 그 흔적을 추적해 xz Utils backdoor를 발견했습니다. "역사상 가장 위험한 backdoor"라는 평가가 붙은 사건의 발견자가 PostgreSQL 커미터였다는 것은 우연이 아닙니다.

2014년에는 한국에서도 작은 움직임이 있었습니다. PostgreSQL Korea User Group이 EDB, 다우기술, 펜타시스템 협업으로 출범한 기록이 남아 있습니다.

Act 3. 2020~2024

통합과 상실의 시대입니다.

2020년 9월 30일, EDB가 2ndQuadrant 인수를 완료했습니다. 이로써 EDB는 "가장 큰 PostgreSQL 전용 회사"가 됐고, Simon Riggs는 EDB Fellow가 됐습니다. 한 시대가 다른 시대를 흡수한 순간이었습니다.

2021년에는 Neon이 설립됐습니다. 설립자는 Nikita Shamgunov(니키타 샴구노프)/Heikki Linnakangas(헤이키 린나캉가스)/Stas Kelvich(스타스 켈비치) 3인입니다. 서버리스 + 브랜칭 모델로 시작했고, 이 회사는 4년 뒤 Databricks의 손에 들어갔습니다.

2022년 6월, Bain Capital(베인 캐피털) Private Equity가 EDB의 다수 지분을 가져갔습니다. PostgreSQL 최대 후원사가 사모펀드의 자산이 된 셈입니다.

Simon Riggs는 2024년 3월 26일, 영국 Duxford 비행장에서 본인이 조종하던 Cirrus SR22-T 사고로 별세했습니다. PITR, Hot Standby, 동기화 replication을 만든 사람의 죽음을 PostgreSQL 커뮤니티는 길게 애도했습니다. 공식 부고는 postgresql.org에 남아 있습니다.

사흘 뒤인 3월 29일, Andres Freund가 xz Utils backdoor를 발견했습니다. 같은 주에 PostgreSQL은 한 사람을 잃었고, 또 한 사람의 발견은 리눅스 생태계 전체를 구했습니다.

Greenplum(그린플럼)의 운명도 이 시기에 결정됐습니다. 2010년 EMC가 인수했던 이 PostgreSQL 기반 MPP 데이터베이스는 Pivotal(피보탈)/VMware(VM웨어)/Broadcom(브로드컴)을 거쳤습니다. 2024년 5월, Broadcom이 Greenplum을 closed-source로 전환했습니다. 오픈소스 PostgreSQL 변형이 사유 제품이 된 첫 큰 사례입니다.

같은 시기 K8s 쪽에서는 CloudNativePG가 자라났습니다. EDB의 Gabriele Bartolini(가브리엘레 바르톨리니)가 이끄는 프로젝트로, 2025년 1월 CNCF Sandbox에 정식 진입했습니다. PostgreSQL이 CNCF 산하 데이터베이스가 된 첫 사례입니다.

Act 4. 2025~2026

클라우드 베어의 시대입니다.

2025년이 무겁습니다. 클라우드 베어 셋이 같은 분기에 PostgreSQL 회사를 다 가져갔습니다.

시점사건금액
2025-05-14Databricks → Neon약 10억 달러
2025-06-02Snowflake → Crunchy Data약 2억 5천만 달러
2025년 중반Microsoft → HorizonDB 발표 (자체 개발)

세 인수는 같은 방향을 가리킵니다. AI agent를 위한 PostgreSQL입니다. Neon은 서버리스 + 브랜칭 모델이라 agent가 매 작업마다 격리된 DB 인스턴스를 만들기에 적합합니다. Crunchy는 규제 산업 고객 기반과 안정적 코어 엔진을 가져왔습니다. HorizonDB는 wire 호환만 유지하고 스토리지는 Rust로 새로 짰습니다.

The Build 블로그의 Christophe Pettus는 이 셋을 한 줄로 정리했습니다.

"Pick the one whose adjacent data platform you already use, and do not pretend you have a choice you don't have."

선택은 이미 쓰고 있는 데이터 플랫폼이 정해 줬다는 뜻입니다. Snowflake 고객은 Snowflake Postgres를 쓰고, Databricks 고객은 Lakebase(레이크베이스)를 씁니다. 셋은 SQL과 기본 PostgreSQL 동작까지는 호환되지만, extension, logical replication, pg_basebackup, pgBackRest, Patroni는 통하지 않습니다.

Crunchy 인수는 빈말로 끝나지 않았습니다. Snowflake는 2026년 2월 24일 Snowflake Postgres를 정식 출시(GA)했습니다. Snowflake 콘솔에서 곧바로 Postgres 인스턴스를 만들고 관리할 수 있으며, AWS/Azure 일부 리전에서 먼저 풀렸습니다. Snowflake는 이를 "fork가 아니라" 기존 PostgreSQL 도구를 그대로 쓰는 lift-and-shift 호환 제품이라고 강조합니다. Crunchy의 엔진과 인력이 실제 상용 제품으로 녹아든 결과입니다.

같은 시기 Timescale은 2025년 6월 TigerData(타이거데이터)로 리브랜드했습니다. 시계열에서 벗어나 agent 데이터베이스를 표방합니다.

막간. 혼자 걸어온 사람들

회사 인수 흐름과 별개로, PostgreSQL 생태계에는 큰 회사 안에 들어가지 않고 30년 가까이 자기 일을 한 사람들이 있습니다.

Christophe Pettus는 2009년 PGX를 차렸습니다. The Build 블로그는 이 회사의 채널입니다. 2026년 5월 현재도 본인이 직접 CEO, 컨설턴트, 블로거 노릇을 합니다.

Markus Winand(마르쿠스 비난트)는 책 한 권(《SQL Performance Explained》), 웹사이트 둘(use-the-index-luke.com, modern-sql.com), 비엔나에서 진행하는 5일 기업 교육으로 일합니다. 이 셋이 그의 회사 전체입니다. "구루"라는 표현이 가장 어울리는 형태입니다.

Hironobu Suzuki(스즈키 히로노부)는 일본 출신으로, 현재 유럽에 거주합니다. 《The Internals of PostgreSQL》을 비롯해 PostgreSQL 책 4권 + MySQL(마이에스큐엘) 책 3권을 썼습니다. interdb.jp는 그의 평생 작업입니다.

Hubert Lubaczewski(후베르트 루바체프스키, 닉네임 depesz)는 explain.depesz.com을 13년째 혼자 돌립니다. PostgreSQL 버전별 "Waiting for…" 시리즈는 1차 자료입니다. 회사는 본인 이름을 그대로 쓴 DEPESZ SOFTWARE HUBERT LUBACZEWSKI (폴란드)입니다.

Joshua Drake는 1997년 Command Prompt를 차렸습니다. 26년 차 PostgreSQL 컨설팅 회사이며, United States PostgreSQL의 회장이기도 합니다.

그러나 2026년 4월, 이 흐름의 어두운 그림자가 드러났습니다. David Steele(데이비드 스틸)이 13년간 단독으로 유지한 pgBackRest의 archive를 선언했습니다. 이미 pgBackRest의 종료 글에서 한 편 정리한 사건입니다. Crunchy가 후원하다가 Snowflake 인수 이후 자금이 끊어졌고, 그는 13개월간 새 직장을 찾지 못했습니다.

며칠 뒤 Steele은 입장을 일부 바꿨습니다. 다중 스폰서 연합 펀딩으로 전환해 프로젝트를 이어 갈 가능성을 발표했습니다. 구체적 후원 기업명은 아직 공개되지 않았습니다. Christophe Pettus와 Gabriele Bartolini는 이 사건을 같은 문장으로 요약했습니다.

"Open source doesn't die. It gets unfunded."

이 문장은 오픈소스는 죽는 것이 아니라 자금이 끊길 뿐이라는 뜻입니다.

커미터들은 어디에 있는가

빅테크 흡수의 지도를 살펴봅니다.

2025년 기준 PostgreSQL 커미터 31명의 소속을 단순화해 정리하면 다음과 같습니다.

소속인원 (개략)대표 인물
EDB8~10Tom Lane(과거), Bruce Momjian, Robert Haas(로버트 하스)/Álvaro Herrera(알바로 에레라)/Andrew Dunstan(앤드루 던스턴)/Jacob Champion(제이콥 챔피언)/Masahiko Sawada(사와다 마사히코)
Microsoft5Andres Freund/David Rowley(데이비드 라울리)/Thomas Munro(토마스 먼로)/Melanie Plageman(멜라니 플레이지먼)/Daniel Gustafsson(다니엘 구스타프손)/Amit Langote(아미트 랑고테)
AWS2~3Peter Geoghegan(피터 게오게간)/Nathan Bossart(네이선 보사트)/Michael Paquier(미카엘 파키에)
Crunchy Data (→ Snowflake)2~3Tom Lane/Stephen Frost(스티븐 프로스트)/Joe Conway(조 콘웨이)
NTT/Fujitsu(후지쯔)/SRA OSS4Tatsuo Ishii(이시이 타츠오)/Fujii Masao(후지이 마사오)/Etsuro Fujita(후지타 에츠로)/Amit Kapila(아미트 카필라)
Supabase1Alexander Korotkov(알렉산더 코로트코프) (전 Postgres Professional(포스트그레스 프로페셔널))
독립/기타2~3Dean Rasheed(딘 라시드)/Jeff Davis(제프 데이비스)/Richard Guo(리처드 궈)

빅테크 흡수는 진행 중입니다 — Microsoft + AWS만 합쳐도 약 25%입니다. EDB가 약 30%이고, Crunchy는 이제 Snowflake 자회사입니다. 일본 NTT/Fujitsu 라인은 의외로 두텁습니다.

한국은 공식 커미터/코어 멤버 명단에서 확인되는 사람이 없습니다.

거버넌스

라이선스는 안전한지 살펴봅니다.

먼저 던질 질문이 있습니다. Redis(레디스)/MongoDB(몽고DB)는 라이선스를 일방적으로 바꿨습니다. PostgreSQL도 그렇게 할 수 있을까요.

답은 사실상 불가능합니다. 이유는 단순합니다. PostgreSQL의 코드 소유권이 30년 동안 수천 명의 기여자에게 분산돼 있습니다. 라이선스 변경에는 만장일치에 가까운 동의가 필요합니다. Redis/MongoDB는 단일 회사 소유여서 가능했습니다.

PostgreSQL의 BSD-style 라이선스는 명시적으로 "perpetually free and open source"를 약속합니다. 30년의 분산이 이 약속의 진짜 보증입니다.

위험은 다른 곳에 있습니다. 단일 메인테이너 도구의 자금 단절입니다. pgBackRest가 처음 보여줬고, 다음 사례가 어디서 나올지는 모릅니다.

향후 5년

2031년의 풍경을 그려 봅니다.

사실에서 추측으로 넘어갑니다. 추측이지만 근거를 함께 적습니다.

가능성 높음:

  1. PostgreSQL이 사실상 표준 RDBMS 지위를 굳힙니다. Stack Overflow(스택 오버플로우) 2025 조사에서 개발자 55.6%가 PostgreSQL을 쓴다고 답했습니다. AI workload (pgvector) + OLTP + Analytics를 한 엔진이 다 받는 모델은 경쟁자가 없습니다.

  2. "PostgreSQL"이라는 단어가 흐려집니다. 사용자는 "Postgres를 쓴다"고 말하지만 실제로는 Aurora, Lakebase, HorizonDB, Snowflake Postgres 중 하나를 쓰는 식이 됩니다. extension 호환성이 가장 먼저 깨집니다.

  3. AI agent가 PostgreSQL을 "skill"로 등록하는 패턴이 표준이 됩니다. Supabase의 ChatGPT 공식 앱, Microsoft의 MCP for PostgreSQL이 출발선입니다.

갈등 지점:

  1. 단일 메인테이너 도구의 줄도산. Barman은 EDB가 받아 안정적이지만, pgBackRest 사건은 다른 도구에도 일어날 수 있습니다. Cybertec(사이버텍)의 pg_timetable, depesz.com 같은 1인 운영 자원의 지속성을 묻는 시기가 옵니다.

  2. K8s 운영자(operator)의 표준 경쟁. CloudNativePG가 CNCF 산하 단일 표준으로 가려면 시간이 더 필요합니다. Crunchy PGO는 Snowflake 인수 이후 장기 전략이 불투명하고, Zalando(잘란도)/StackGres(스택그레스)는 각자 자리를 지키고 있습니다.

  3. PostgreSQL 코어팀의 빅테크 의존도. EDB, Microsoft, AWS, Snowflake가 커미터 절대다수를 고용하고 있습니다. 라이선스는 안전해도, 로드맵의 무게중심은 조용히 이동합니다.

작게 가능한 시나리오:

  1. OrioleDB 같은 새 storage engine이 코어에 들어갑니다. 현재 public beta입니다. Alexander Korotkov가 Supabase로 옮긴 뒤 Supabase가 후원합니다. 2028년 전후로 production 후보가 될 가능성이 있습니다.

  2. 벤더 중립 우산 조직이 생깁니다. Gabriele Bartolini와 ProOpenSource(프로오픈소스)가 제안한 모델입니다. Apache Software Foundation(아파치 소프트웨어 재단)/Codeberg e.V.(코드버그)처럼 PostgreSQL 도구의 거버넌스를 단일 회사에서 분리하는 흐름이며, 아직 제안 단계입니다.

닫으며

이 이야기에서 무엇이 남는지 생각해 봅니다.

PostgreSQL의 30년에는 두 줄이 동시에 흘러왔습니다. 한쪽에는 Heroku, Citus, OpenSCG, Crunchy, Neon, Timescale로 이어진 회사들의 인수와 흡수가 있고, 다른 쪽에는 Tom Lane, Bruce Momjian, Christophe Pettus, Markus Winand, David Steele처럼 코드와 책과 도구를 30년 가까이 자기 손으로 들고 있는 개인들이 있습니다.

2026년의 풍경은 회사 쪽이 훨씬 시끄럽지만, 무게는 결국 개인 쪽으로 다시 돌아오리라 봅니다. 클라우드 베어 셋이 같은 분기에 PostgreSQL 회사를 다 가져갔어도, Andres Freund가 SSH 로그인의 500ms 차이로 xz backdoor를 잡아낸 순간이 어느 회사의 분기 실적보다 더 오래 기억될 것입니다.

오픈소스는 죽지 않고 자금이 끊길 뿐이라는 말처럼, 다음 30년의 PostgreSQL은 결국 어떤 사람이 어디서 누구의 자금으로 일하느냐에 달려 있어요.

부록. 1986~2026 전체 연표

1980년대

  • 1986/UC Berkeley에서 POSTGRES 프로젝트 시작 (Michael Stonebraker)

1990년대

  • 1995/POSTGRES → PostgreSQL로 이름 변경. SQL 인터페이스 도입
  • 1996/PostgreSQL 6.0 첫 정식 릴리스. Tom Lane/Bruce Momjian 등 코어 합류
  • 1997/Joshua Drake, Command Prompt 설립 (미국 몬태나)

2000년대

  • 2002/Simon Riggs, 2ndQuadrant 설립 (영국/이탈리아)
  • 2004/EnterpriseDB (EDB) 설립
  • 2006/Bruce Momjian, EDB 합류
  • 2009/Christophe Pettus, PGX 설립

2010~2015

  • 2010/Citus Data 설립
  • 2010-07/EMC, Greenplum 인수
  • 2010-11/Heroku에 PostgreSQL 도입
  • 2010-12-08/Salesforce → Heroku 인수, 약 2억 1,200만 달러
  • 2011-11/Heroku Postgres 분리 제품 출시
  • 2012/Crunchy Data 설립 (Laurence 형제)
  • 2012/Greenplum, Pivotal로 재조직
  • 2014/Peak Equity Partners → EDB 다수 지분 인수
  • 2014/PostgreSQL Korea User Group 출범 (EDB, 다우기술, 펜타시스템)
  • 2015/Tom Lane, Crunchy Data 합류
  • 2015/Timescale 설립
  • 2015/Alexander Korotkov, Postgres Professional 공동 설립

2016~2019

  • 2016/Aiven 설립 (Saarenmaa, Valtonen, Nousiainen)
  • 2018-04경/AWS → OpenSCG 인수
  • 2019-01-24/Microsoft → Citus Data 인수
  • 2019/Great Hill Partners → EDB 다수 지분 인수

2020~2023

  • 2020/Supabase 설립 (Copplestone/Wilson)
  • 2020/VMware → Pivotal/Greenplum 인수
  • 2020-09-30/EDB → 2ndQuadrant 인수 완료
  • 2021/Neon 설립 (Shamgunov, Linnakangas, Kelvich)
  • 2022-05/Aiven 시리즈 D, 2억 1,000만 달러
  • 2022-06/Bain Capital → EDB 다수 지분 인수
  • 2023/Alexander Korotkov, Postgres Professional → Supabase
  • 2023-11/Broadcom → VMware 인수 (Greenplum 포함)

2024: 상실의 해

  • 2024-03-26/Simon Riggs 별세 (영국 Duxford, Cirrus SR22-T 사고)
  • 2024-03-29/Andres Freund, xz Utils backdoor 발견 (SSH 500ms 추적)
  • 2024-05/Broadcom, Greenplum closed-source 전환
  • 2024/Barman 유지보수, 2ndQuadrant → EDB 공식 이관 완료

2025: 클라우드 베어의 분기

  • 2025-01-21/CloudNativePG, CNCF Sandbox 진입
  • 2025-05-14/Databricks → Neon 인수, 약 10억 달러
  • 2025-06-02/Snowflake → Crunchy Data 인수, 약 2억 5천만 달러
  • 2025-06/Timescale → TigerData 리브랜드
  • 2025년 중반/Microsoft, HorizonDB 발표 (자체 개발)
  • 2025-10/Supabase 시리즈 E, 1억 달러, 프리머니 50억 달러 밸류에이션

2026: 균열의 신호

  • 2026-02-24/Snowflake Postgres 정식 출시(GA), Crunchy 엔진 기반, AWS/Azure 일부 리전
  • 2026-04-27/David Steele, pgBackRest archive 선언
  • 2026-04-30/Percona Community: "Open source doesn't die. It gets unfunded."
  • 2026-05 초/Steele, 다중 스폰서 연합 펀딩 모델 가능성 발표
  • 2026-05-12/The Build, "Picking the Lock-In You Want" 발표
  • 2026-05-13/PostgreSQL 2026년 5월 보안 업데이트 (CVE 5건, CVSS 8.8 × 3)

1차 출처

회사/인수:

커미터/인물:

컨설턴트/메인테이너:

클라우드 전략/미래: