PostgreSQL 생태계 투자와 서버리스 데이터베이스의 확장

학술 프로젝트에서 데이터 인프라의 중심으로

POSTGRES 프로젝트는 1986년 UC 버클리에서 구현되기 시작했다. 그 출발점은 1982년으로 거슬러 올라간다. Ingres 팀을 이끌던 Michael Stonebraker가 버클리를 떠나 Ingres의 상용화를 추진한 뒤, 1985년 다시 버클리로 돌아와 post-Ingres 프로젝트를 시작했다. 1988년 ACM SIGMOD 컨퍼런스에서 프로토타입이 공개됐고, 1989년 6월에는 버전 1이 소규모 사용자에게 배포됐다.

1994년 Andrew Yu와 Jolly Chen이 SQL 인터프리터를 더하면서 프로젝트는 Postgres95라는 이름으로 공개됐다. 1996년에는 SQL 지원을 명시한 PostgreSQL로 이름이 바뀌었다. 이후 오픈소스 커뮤니티가 발전을 이어오며 PostgreSQL은 2025년 현재 가장 신뢰받는 관계형 데이터베이스 시스템 중 하나가 됐다.

AI 시대의 데이터 인프라에서 PostgreSQL이 다시 주목받는 배경은 분명하다. ACID 준수와 확장성을 함께 제공하고, Extension API로 벡터 검색·시계열·JSON 처리를 단일 데이터베이스에 넣을 수 있다. 오픈소스 라이선스는 클라우드 사업자가 포크하거나 관리형 확장 서비스를 만들 수 있는 여지도 제공한다.

인수와 투자로 드러난 생태계 경쟁

Snowflake가 Crunchy Data를 택한 배경

Snowflake는 2025년 6월 Snowflake Summit에서 Crunchy Data 인수 의향을 공식 발표했다. 거래 금액은 약 2억 5천만 달러로 추산된다. Crunchy Data는 신뢰할 수 있는 오픈소스 Postgres 기술과 제품을 제공하는 기업이다.

이 인수를 토대로 선보이는 "Snowflake Postgres"는 엔터프라이즈 AI 및 트랜잭션 시스템을 겨냥한 완전 관리형 Postgres 데이터베이스다. 개발자가 익숙한 도구를 유지한 채 프로덕션 수준의 AI 에이전트와 애플리케이션을 구축하도록 설계됐으며, 보안·컴플라이언스·확장성 요구를 충족하는 것을 목표로 한다.

이는 분석 쿼리에 강점을 둔 데이터 웨어하우스에서 OLTP까지 포괄하는 데이터 라이프사이클 플랫폼으로 Snowflake의 범위를 넓히려는 움직임이다.

Databricks와 Neon의 서버리스 Postgres 전략

Databricks는 2025년 5월, Neon을 약 10억 달러에 인수하겠다고 발표했다. Snowflake의 Crunchy Data 인수 발표보다 약 3주 앞선 시점이다. 2021년 설립된 Neon은 서버리스 환경에서 Postgres 인스턴스를 500밀리초 이내에 스핀업하는 아키텍처로 알려졌다.

Neon 내부 텔레메트리 분석에서는 프로비저닝되는 데이터베이스의 80% 이상이 사람이 아니라 AI 에이전트에 의해 자동 생성되는 것으로 나타났다. 필요할 때 데이터베이스를 만들고 작업이 끝나면 스케일 다운하는 방식이 에이전트형 AI 시스템에서 일반화되고 있다는 뜻이다.

Neon의 서버리스 Postgres 아키텍처는 Databricks 데이터 인텔리전스 플랫폼과 통합돼, 개발자와 엔터프라이즈 팀이 AI 에이전트 시스템을 구축·배포하는 기반이 될 전망이다.

Supabase가 개발자 플랫폼으로 확보한 위치

Supabase는 2025년 10월 Accel과 Peak XV가 공동 주도한 Series E에서 1억 달러를 유치하며 50억 달러 밸류에이션을 달성했다. 4개월 전 Series D의 20억 달러 밸류에이션에서 2.5배 오른 결과이며, 누적 조달액은 5억 달러를 넘었다.

성장의 동력으로는 AI 주도 개발(vibe coding)이 거론된다. 전 세계 400만 명 이상의 개발자가 Cursor, Claude Code 등 AI 코딩 도구와 함께 Supabase를 사용하며, AI의 명령으로 백엔드를 즉시 업데이트하는 경험을 선호한다. 연간 반복 매출(ARR)은 약 7000만 달러 규모다.

신규 자금은 엔터프라이즈 스케일 플랫폼인 "Multigres" 개발에 쓰일 예정이다. Supabase는 Vitess 공동 창시자인 Sugu Sougoumarane을 영입해 대규모 데이터 집약적 애플리케이션을 위한 Postgres 클러스터링 솔루션을 개발하고 있다.

확장을 전제로 설계된 PostgreSQL

PostgreSQL이 관계형 데이터베이스를 넘어 현대 데이터 스택의 플랫폼으로 쓰이는 이유는 확장 구조에 있다.

Extension API는 새 데이터 타입, 함수, 연산자, 인덱스 방식, 언어까지 추가할 수 있게 한다. PostgreSQL의 내장 기능 또한 거의 같은 방식으로 구현된다.

pgvector: 벡터 유사도 검색을 지원한다. 최대 2,000차원 벡터를 저장할 수 있고 HNSW 및 IVFFlat 인덱스를 지원한다. pgvector 0.8.0의 반복 인덱스 스캔은 복잡한 필터링 쿼리 레이턴시를 9.4배 단축시켰다.
TimescaleDB: 시계열 데이터에 맞춘 스토리지와 쿼리 엔진을 제공한다.
PostGIS: 공간 데이터 처리를 위한 GIS 확장이다.
pg_partman: 파티션 관리를 자동화한다.

긴 분석 쿼리에서의 JIT 활용

PostgreSQL은 LLVM 기반 JIT(Just-In-Time) 컴파일을 내장 지원한다. --with-llvm 옵션으로 빌드할 때 활성화되며, CPU 집약적인 장기 실행 쿼리를 주된 대상으로 한다.

범용 SQL 표현식 평가 코드 대신 특정 표현식에 맞춘 네이티브 함수를 런타임에 생성하는 방식이다. 작은 함수의 본문을 인라인화해 함수 호출 오버헤드를 줄이는 효과도 있다. 다만 JIT에는 오버헤드가 있으므로 짧은 쿼리보다 OLAP 성격의 복잡한 분석 쿼리에 맞는다.

복제, 파티션, 병렬 실행의 조합

논리적 복제(Logical Replication)는 WAL(Write-Ahead Log)의 변경 사항을 논리적 형태로 복제한다. 선택적 테이블 복제, 이기종 버전 간 복제, 변경 데이터 캡처(CDC)가 가능한 이유다.

선언적 파티셔닝(Declarative Partitioning)은 Range, List, Hash 방식으로 대용량 테이블을 나눠 관리한다. 병렬 쿼리 실행은 시퀀셜 스캔, 인덱스 스캔, 집계, 조인 같은 연산을 여러 CPU 코어에 분산한다. JIT와 병렬 쿼리를 함께 쓰면 각 워커의 JIT 연산이 독립적으로 추적되며, HTAP(Hybrid Transactional/Analytical Processing) 워크로드에서 성능 향상을 기대할 수 있다.

관리형 Postgres 서비스가 겨냥하는 워크로드

⤢✕

**Neon (Databricks)**은 서버리스 Postgres의 특성을 앞세운다. 500밀리초 이내 콜드 스타트, 스케일-제로, Git처럼 데이터베이스를 분기하는 브랜칭 기능이 차별점이다. Aurora Serverless v2의 15초 콜드 스타트와 비교하면 30배 빠른 응답성을 제공하며, 필요할 때 즉시 생성하는 AI 에이전트의 에피메럴 데이터베이스 패턴에 맞춰져 있다. 2025년 후반에는 스토리지 비용을 GB당 월 1.75달러에서 0.35달러로 80% 인하했다.

Google AlloyDB는 PostgreSQL 호환성을 유지하면서 HTAP 워크로드용 컬럼형 스토리지 엔진을 내장한다. 트랜잭션과 분석 쿼리를 같은 인스턴스에서 고성능으로 처리해야 하는 엔터프라이즈 환경을 겨냥한다.

AWS Aurora PostgreSQL은 안정성과 글로벌 클러스터링을 강점으로 둔다. AWS 생태계에 깊이 통합된 서비스와 연동해야 하는 환경에서는 자연스러운 선택지가 된다.

Supabase는 데이터베이스에 Auth, Storage, Edge Functions, Realtime을 묶은 개발자 백엔드 플랫폼이다. pgvector를 네이티브로 지원해 AI 애플리케이션 개발을 빠르게 시작할 수 있다.

단일 데이터베이스로 묶는 데이터 스택

⤢✕

PostgreSQL이 AI 시대의 통합 데이터 플랫폼으로 쓰이는 패턴은 하나의 데이터베이스에서 여러 워크로드를 처리하는 데 있다.

기존 마이크로서비스 아키텍처에서는 OLTP에 MySQL, 검색에 Elasticsearch, 벡터 검색에 Pinecone, 시계열에 InfluxDB처럼 용도별 데이터베이스를 나눠 썼다. 이른바 polyglot persistence 패턴이다.

하지만 AI 에이전트가 여러 데이터 소스를 넘나들면 컨텍스트 관리가 어려워지고, 데이터 일관성 보장과 운영 부담도 복잡해진다. PostgreSQL의 확장 구조는 그 복잡성에 대응하는 선택지다. pgvector에는 임베딩 벡터를 저장하고 JSONB에는 메타데이터를 보관하며 시계열 확장에는 이벤트 로그를 관리하는 작업을 단일 ACID 트랜잭션 컨텍스트에서 처리할 수 있다.

RAG(Retrieval-Augmented Generation) 파이프라인에서도 pgvector 활용이 늘고 있다. 전통적 검색 쿼리와 벡터 유사도 검색을 결합한 하이브리드 검색, 복잡한 조건을 적용하는 메타데이터 필터링 벡터 검색을 SQL 쿼리로 처리할 수 있다는 점이 핵심이다.

투자 경쟁이 가리키는 방향

투자의 바탕에는 AI 에이전트 인프라를 선점하려는 경쟁이 있다. AI 에이전트는 데이터베이스를 동적으로 프로비저닝하고 해제한다. Neon의 텔레메트리에서 드러난 데이터베이스 80% 이상이 AI 에이전트에 의해 생성되는 패턴은 서버리스 PostgreSQL이 맞물리는 지점을 보여준다. Databricks의 약 10억 달러 Neon 인수도 이 맥락에 있다.

오픈소스 기반의 벤더 락인도 중요한 축이다. PostgreSQL 자체는 오픈소스지만, 그 위의 관리형 서비스는 플랫폼 의존성을 형성한다. Snowflake Postgres, Supabase, Aurora PostgreSQL은 PostgreSQL 호환성을 내세우면서 각자의 플랫폼 생태계에 사용자를 연결하는 구조를 갖고 있다.

OLTP와 OLAP의 경계가 흐려지는 변화도 투자 배경이다. AlloyDB의 HTAP 아키텍처와 PostgreSQL의 병렬 쿼리 지원은 이 변화에 대한 선택이다. Snowflake가 Crunchy Data 인수로 분석 중심 플랫폼에서 OLTP까지 범위를 넓히려는 이유도 여기에 있다.

PostgreSQL의 확장성, 서버리스 운용 방식, 벡터 검색과 ACID 트랜잭션의 결합은 분산된 데이터 스택의 복잡성을 줄이는 대안으로 자리 잡고 있다. Snowflake, Databricks, Supabase의 움직임은 데이터 인프라 시장에서 이 생태계가 차지하는 위치가 계속 바뀌고 있음을 보여준다.