2026년 4월 16일 목요일
한국어ENGLISH
DBLOG
대표 시리즈
완결 · 5/5왜 PostgreSQL이죠?
글 목록
Lv.2 초급PostgreSQL
28분 읽기Lv.2 초급
시리즈왜 PostgreSQL이죠? · 파트 3/5시리즈 허브 보기

왜 PostgreSQL이죠? Part 3 — 스타트업의 선택: 속도와 비용의 최적점

왜 PostgreSQL이죠? Part 3 — 스타트업의 선택: 속도와 비용의 최적점

빅테크가 PostgreSQL을 '버리지 않는' 이유를 Part 2에서 다뤘다면, 이번에는 시선을 초기 제품 팀으로 옮깁니다. 창업 초기에는 인프라 검토보다 MVP 속도와 예측 가능한 비용이 먼저인 경우가 많고, 웹·AI 제품을 빠르게 만드는 팀에서는 PostgreSQL이 사실상 강한 기본값으로 자리 잡았습니다. 다만 그 설득의 상당수는 Supabase·Neon 같은 관리형 플랫폼이 제공한 실행 편의에서 비롯되므로, 엔진 자체의 특성과 플랫폼 번들을 구분해 읽는 편이 안전합니다. 이 글은 ARR 같은 사업 성장 지표와 YC 채택률 같은 생태·기술 지표를 섞어 오해하지 않도록 짚고, pgvector 도입 시 벤치마크가 전제한 워크로드 조건을 함께 언급합니다. 마지막으로 스키마 규율·백업 복구처럼 숨은 운영 습관까지 짧게 덧붙여, '왜 PostgreSQL인가'에 현실적인 맥락을 더합니다.

시리즈 구성

목차

  1. 들어가며: 스타트업에게 데이터베이스 선택이란
  2. Supabase — PostgreSQL을 스타트업의 기본값으로 만든 플랫폼
  3. Neon — 서버리스 PostgreSQL이 바꾼 개발 워크플로우
  4. pgvector — AI 스타트업이 Pinecone 대신 PostgreSQL을 고르는 이유
  5. YC와 Supabase 채택률
  6. 스타트업이 PostgreSQL을 선택하는 다섯 가지 실질적 이유
  7. 마치며

1. 들어가며: 스타트업에게 데이터베이스 선택이란

빅테크 기업들이 PostgreSQL을 "버리지 않는" 이유를 Part 2에서 살펴봤다면, 이번에는 시각을 다른 축으로 옮깁니다.

스타트업에게 데이터베이스 선택은 성숙한 인프라팀이 아키텍처를 검토하는 과정이 아닌 경우가 많습니다. 창업자 한두 명이 MVP를 빠르게 만들어야 하는 상황에서 결정되는 문제에 가깝습니다. 이 맥락에서 기준은 단순합니다. 빠르게 시작할 수 있는가, 예상치 못한 비용이 발생하지 않는가, 나중에 갈아엎지 않아도 되는가입니다.

2025년 기준으로, 웹·AI 제품을 빠르게 만드는 초기 팀에서는 이 세 조건을 동시에 만족시키는 답으로 PostgreSQL이 사실상 강한 기본값이 됐습니다. 다만 B2B 엔터프라이즈, 규제가 강한 온프렘 중심 산업, 기존 NoSQL 자산이 큰 팀에서는 여전히 다른 선택이 합리적일 수 있습니다. 아래 논의는 "모든 조직"이 아니라 초기 제품 속도와 비용 예측 가능성에 무게를 둔 팀을 염두에 둡니다.

그리고 그 중심에는 두 종류의 이야기가 겹칩니다. 하나는 PostgreSQL 엔진이 제공하는 관계형 모델·확장·생태계이고, 다른 하나는 Supabase·Neon 같은 관리형 플랫폼이 제공한 프로비저닝·과금·개발자 경험입니다. 이 글에서는 두 층을 가능한 한 분리해 서술합니다.

2. Supabase — PostgreSQL을 스타트업의 기본값으로 만든 플랫폼

포지셔닝이 만든 전환

Supabase의 가장 중요한 성과는 기술만으로 설명되지 않습니다. 포지셔닝이 큽니다.

2020년 창업 당시 Supabase는 스스로를 "오픈소스 Firebase 대안"으로 정의했습니다. Firebase가 Google의 NoSQL 기반 BaaS(Backend-as-a-Service)라면, Supabase는 그 자리를 PostgreSQL로 대체한다는 선언이었습니다. Firebase에 익숙한 프론트엔드 개발자와 인디 해커에게 "익숙한 개발 경험은 유지하되, 이번에는 관계형 데이터베이스"라는 메시지로 전달됐습니다.

성장 지표와 채택 지표를 나누어 읽기

아래에 등장하는 수치는 서로 다른 축입니다. ARR·기업가치는 사업 성장에 가깝고, 관리 데이터베이스 수·개발자 수·GitHub 스타는 플랫폼 채택·커뮤니티 규모에 가깝습니다. "같은 그래프 위의 우위"로 한 번에 비교하면 오해가 생길 수 있으니, 용도를 구분해 읽는 편이 안전합니다.

ARR처럼 매출 규모는 공식 단일 공시가 아니라 제3자 리서치·언론 추정치로만 접할 때가 많습니다. 출처마다 정의(순·매출·인식 시점)가 달라 수치가 크게 엇갈리므로, 아래는 방향성 위주로만 짚습니다. 여러 추정에 따르면 2023년 말에는 수백만 달러 규모에서 출발해 2024년에는 일부 출처에서 연말 약 3,000만 달러 전후, 2025년 3분기(8~9월) 에는 약 7,000만 달러 전후로 보는 분석이 제시되기도 합니다. 2025년 4월 시리즈 D로 2억 달러를 조달해 기업가치 약 20억 달러를 인정받았고, 같은 해 10월 시리즈 E에서는 기업가치 약 50억 달러로 불었다는 보도가 이어졌습니다(TechCrunch 등 공개 보도 · PR Newswire 참고).

플랫폼 규모 측면에서는, 2024년 일반 공개(GA) 시점 기준으로 관리 PostgreSQL 데이터베이스 100만 개 돌파가 보도된 바 있고 이후에도 증가했다는 서술이 이어집니다. 등록 개발자는 2026년 4월 공식 발표 기준 800만 명을 넘었다는 자료가 있으며, 과거에는 수백만 명 규모로 소개된 적도 있습니다. GitHub 메인 저장소 스타는 2026년 4월 기준 10만 개 돌파가 공식적으로 알려졌습니다. 이들은 "엔진 한계"가 아니라 제품·운영·커뮤니티가 함께 만든 채택 곡선에 가깝습니다.

"바이브 코딩" 시대의 기본 백엔드

2024~2025년 AI 코딩 도구 붐은 Supabase에게 추가적인 성장 동력이 됐습니다. Bolt, Lovable, Figma Make, v0 같은 플랫폼이 기본 백엔드로 Supabase를 채택했다는 설명이 반복되며, 사용자가 프로젝트를 만들 때마다 데이터베이스가 함께 프로비저닝되는 경로가 늘었습니다. Cursor, Claude Code, Replit 같은 도구와의 연동 이야기도 같은 맥락에서 이해할 수 있습니다.

Supabase가 공개한 내부 요약(독립 제3자 검증은 어려움)에 따르면, 활성 데이터베이스 중 약 10% 이상이 AI 유스케이스를 지원하고, pgvector를 쓰는 신규 데이터베이스 비율이 15% 이상에 달한다는 수치도 소개됩니다.

플랫폼이 제공하는 것과 엔진이 제공하는 것

PostgreSQL 인스턴스 하나를 켜는 것으로 끝나지 않는다는 점이 Supabase의 설득 포인트입니다. 인증(Auth), 실시간 구독(Realtime), 오브젝트 스토리지(Storage), 엣지 함수(Edge Functions)를 PostgreSQL 위에서 하나의 제품 번들로 묶습니다. 백엔드 팀 없이 제품을 만들어야 하는 초기 팀에게는 이 번들이 구현 기간을 줄여 줍니다.

비용 구조도 스타트업 친화적으로 설계된 경우가 많습니다. 무료 플랜에서 시작하고, 트래픽이 생기면 유료 플랜으로 전환하는 식입니다. 여기서의 핵심은 "PostgreSQL이 마법처럼 저렴하다"가 아니라 예측 가능한 단계 과금과 프로비저닝 자동화가 초기 의사결정을 쉽게 만든다는 점입니다.

3. Neon — 서버리스 PostgreSQL이 바꾼 개발 워크플로우

Supabase가 "PostgreSQL을 쉽게"에 가깝다면, Neon은 "PostgreSQL을 서버리스로"에 가깝습니다.

컴퓨팅과 스토리지 분리

Neon의 핵심 설계는 PostgreSQL의 컴퓨팅 레이어와 스토리지 레이어를 분리한 것입니다. 기존에는 둘이 한 인스턴스에 묶여 있어 유휴 시간에도 비용이 발생하기 쉬웠습니다. Neon은 컴퓨팅이 유휴 상태에서 자동으로 0에 가깝게 스케일 다운되도록 만들었고, 쿼리가 들어오면 수백 밀리초 안에 깨어난다고 소개됩니다.

2025년 5월 Databricks가 Neon을 약 10억 달러에 인수했다는 공식 발표 이후, 2025년 8월 Neon 블로그 등에서 스토리지 비용이 GB당 1.75달러에서 0.35달러로 약 80% 하락했다는 업데이트가 공개되기도 했습니다. 이 역시 특정 과금 항목에 대한 변화이므로, 전체 TCO를 단정하기보다는 "스토리지 단가가 내려갔다"는 신호로 읽는 편이 안전합니다.

데이터베이스 브랜칭

Neon에서 주목받는 기능 중 하나는 데이터베이스 브랜칭입니다. Git에서 코드 브랜치를 만들듯 데이터베이스 브랜치를 만들 수 있고, 카피-온-라이트(copy-on-write)로 구현되어 변경되지 않은 데이터는 부모와 공유됩니다. 대용량 데이터베이스를 브랜칭해도 추가 스토리지 비용이 크게 늘지 않는 경로가 열립니다.

PR마다 독립 DB, 위험한 마이그레이션을 프로덕션 전에 검증하는 브랜치, E2E 테스트용 격리 환경을 별도 인프라 없이 구성할 수 있다는 점이 스타트업 워크플로우와 잘 맞습니다.

# GitHub Actions에서 PR당 독립 DB 환경 생성 예시
# pull_request 이벤트 기준
- name: Create Neon branch for PR tests
  uses: neondatabase/create-branch-action@v5
  with:
    project_id: ${{ secrets.NEON_PROJECT_ID }}
    branch_name: preview/pr-${{ github.event.pull_request.number }}
    api_key: ${{ secrets.NEON_API_KEY }}

소규모 팀에서는 스테이징 서버를 따로 두기 어려운 경우가 많습니다. 브랜칭은 그 공백을 메우는 도구로 자주 소개됩니다.

4. pgvector — AI 스타트업이 Pinecone 대신 PostgreSQL을 고르는 이유

분리된 벡터 스토어의 비용과 복잡성

2022~2024년 AI 붐 초기에는 다음과 같은 스택이 흔했습니다.

PostgreSQL(사용자 데이터) + Pinecone(벡터 검색) + 캐시 + 큐 + …

이 구조의 부담은 비용, 동기화, 복잡성으로 정리할 수 있습니다. 벡터 데이터가 별도 서비스에 있으면 애플리케이션 레이어에서 지속적으로 동기화해야 하고, 모니터링·장애 대응 지점도 늘어납니다.

pgvector와 벤치마크를 조건부로 읽기

PostgreSQL의 pgvector 확장과 Timescale이 만든 pgvectorscale은 위 구조를 바꾸는 선택지로 자주 언급됩니다. Timescale이 공개한 pgvector·Pinecone 비교 벤치마크 자료에서는 Pinecone의 고성능 인덱스와 비교해 지연·처리량·비용에서 유리한 구간이 보고되기도 합니다(자사 발표이므로 조건·워크로드를 함께 읽어야 합니다).

다만 벤치마크 수치는 데이터셋 크기, 리콜 목표, 인덱스 설정, 운영 인건비에 민감합니다. "우리 환경에서도 동일한 결과"로 바로 일반화하기 어렵습니다. 특히 "수백만 개 이하 벡터" 같은 결론은 워크로드 조건부라는 전제를 함께 두는 편이 안전합니다.

단일 엔진으로의 수렴

pgvector를 쓰면 임베딩을 기존 테이블 컬럼에 저장할 수 있어, 사용자 레코드와 임베딩이 같은 트랜잭션 경계 안에 머무르기 쉽습니다. SQL 한 번으로 벡터 유사도 검색과 관계형 필터를 함께 적용할 수 있다는 점도 자주 강조됩니다.

-- 벡터 유사도 + 관계형 조건을 하나의 쿼리로
-- (가정) pgvector 확장 설치, cosine 기준(<=>)
SELECT p.product_id, p.name, p.price, p.rating
FROM products p
WHERE p.in_stock = true
  AND p.price < 50000
  AND p.rating >= 4.0
ORDER BY p.embedding <=> $1
LIMIT 10;

전용 벡터 데이터베이스만 쓰는 구조에서는 두 시스템에 각각 쿼리한 뒤 애플리케이션에서 결과를 합쳐야 하는 경우가 많습니다.

업계 전환 사례를 "조건이 비슷할 때"로 읽기

업계에서는 전용 벡터 DB에서 PostgreSQL + pgvector로 옮긴 사례가 공개되기도 합니다. 예를 들어 Instacart 엔지니어링 블로그는 검색 인프라를 PostgreSQL 기반으로 통합한 경험을 공개했고, 비용·쓰기 부하·검색 품질 측면의 개선을 보고했습니다. 이는 "Pinecone에서 곧바로 이전했다"기보다 검색 스택을 Postgres 중심으로 재구성한 사례에 가깝습니다. Firecrawl, Berri AI 등은 커뮤니티에서 자주 인용되는 예로, 공식 엔지니어링 글의 깊이는 사례마다 다릅니다.

이 사례들은 **"모든 RAG 파이프라인에 항상 우월"**을 증명하는 것이 아니라, 특정 규모·팀·운영 제약에서 스택 단순화가 이득을 냈다는 신호로 읽는 편이 맞습니다.

5. YC와 Supabase 채택률

Y Combinator 배치에서 Supabase를 쓰는 비율은 배치·집계 정의에 따라 달라집니다. 2024년 전후 보도에서는 약 40% 전후가 자주 인용되었고, 2025년 최신 배치 기준으로는 일부 출처에서 **약 55%**까지 언급된 바 있습니다(Tech in Asia 등). 단순한 마케팅 수치가 아니라, 빠르게 움직여야 하는 팀들이 PostgreSQL 중심 스택을 고르는 경향을 보여 주는 생태 지표로 읽을 수 있습니다. 정확한 수치는 발표 시점의 원문을 확인하는 편이 안전합니다.

Supabase 플랫폼이 공개한 스타트업 관련 조사에서는, 오늘날 스타트업이 AI 모델을 제품에 통합하고 그 백엔드를 PostgreSQL + pgvector로 구현하는 패턴이 반복된다는 서술도 등장합니다. "AI 앱을 만드는데 데이터베이스가 몇 개 필요한가?"라는 질문의 답이 하나로 수렴하는 쪽으로 읽히는 시장 분위기가 함께 언급됩니다.

6. 스타트업이 PostgreSQL을 선택하는 다섯 가지 실질적 이유

빅테크와 달리 스타트업에게 PostgreSQL의 장점은 다른 층위에서 작동합니다.

1. 시작 비용이 낮다
Supabase·Neon의 무료 플랜처럼 신용카드 없이 시작할 수 있는 경로가 있습니다. 아이디어 검증 단계에서 데이터베이스 비용을 최소화하려는 요구와 맞닿아 있습니다.

2. 나중에 갈아엎을 필요가 적다
다른 저장소로 시작했다가 "이제 진짜 관계형이 필요하다"는 순간이 오면 마이그레이션 비용이 크게 치솟는 경우가 많습니다. PostgreSQL로 시작하면 그 전환의 시점을 늦추거나 없앨 수 있습니다.

3. 채용이 상대적으로 쉽다
Stack Overflow Developer Survey 2024에서는 PostgreSQL이 가장 널리 사용되는 데이터베이스로 보고되는 등, 개발자 풀에서의 친숙도가 높게 나타납니다. 소규모 팀이 익숙한 인재를 찾는 데도 유리한 편입니다.

4. 확장 생태계가 스택을 단순하게 만든다
pgvector, PostGIS, TimescaleDB, 전문 검색까지 확장을 더하면 별도의 전문 저장소를 줄이는 설계가 가능해집니다. 관리해야 할 시스템 수가 줄수록 운영 부담이 내려갑니다.

5. AI 코딩 도구와의 궁합
스키마 설계·쿼리·마이그레이션 스크립트는 공개 학습 데이터와 문서가 풍부한 축에서 도움을 받기 쉽습니다. 팀이 AI 어시스턴트를 적극 쓰는 환경에서는 이 점이 체감 비용으로 돌아옵니다.

빠른 시작만으로는 부족한 운영 습관

"빠른 시작"과 "예측 가능한 비용"은 강하게 드러나지만, 초기 팀이 마주치는 리스크도 있습니다. 스키마 변경 규율, 마이그레이션 실패 시 복구, 백업·복원 리허설, 멀티테넌시 격리 전략처럼 운영 습관이 없으면 같은 스택에서도 사고 비용이 커질 수 있습니다. PostgreSQL을 고르는 이유에 이 축을 함께 얹어 두면, 선택이 현실과 더 잘 맞물립니다.

7. 마치며

"일단 PostgreSQL로 시작하라"는 조언은 예전에는 막연한 격언처럼 들릴 수 있었습니다. 지금은 Supabase·Neon·pgvector 같은 실행 경로가 구체화되면서, 쉬운 선택이 곧 합리적인 선택으로 수렴하는 구간이 넓어졌습니다.

다시 한 번 강조하면, 여기서의 "쉬움"은 엔진만의 이야기가 아닙니다. 관리형 플랫폼이 제공한 프로비저닝·과금·개발자 경험이 큰 비중을 차지합니다. 그 점을 분리해 이해할 때 반박 여지도 줄고, 팀의 다음 단계 결정도 명확해집니다.

Part 4에서는 이미 다른 데이터베이스를 쓰고 있는 팀의 이야기로 넘어갑니다. MongoDB에서 PostgreSQL로, MySQL에서 PostgreSQL로 실제 마이그레이션을 단행한 사례를 통해, 무엇이 계기가 됐고 어떤 과정을 거쳤으며 결과는 어땠는지를 살펴봅니다.

다음 편 예고 — Part 4: MongoDB·MySQL 탈출기: 실제 마이그레이션 사례

Infisical의 MongoDB → PostgreSQL 전환 후 DB 비용 절감, Uber의 MongoDB → PostgreSQL + JSONB 대규모 이전, Oracle에서 PostgreSQL로 넘어간 기업들의 TCO 분석까지. "이미 다른 DB를 쓰고 있다"는 것이 이유가 되지 않는 이유를 다룹니다.

참고·출처

작성: 2026년 4월 · 사례별 수치·구성은 공개 시점의 블로그·발표·보도를 기준으로 하며, 이후 인프라·과금은 변경될 수 있습니다. 인용 시 원문을 확인하세요.

이 글 공유하기

시리즈 내비게이션

왜 PostgreSQL이죠?

3 / 5 · 5

이전 글왜 PostgreSQL이죠? Part 2 — 빅테크는 왜 PostgreSQL을 선택했나시리즈 전체 보기다음 글왜 PostgreSQL이죠? Part 4 — MongoDB·Oracle 탈출기: 실제 마이그레이션 사례

같은 주제 더 보기·대표 시리즈로 시작

English

최신 글을 RSS로 받아보세요

뉴스레터 오픈 전에는 RSS로 먼저 업데이트를 받아보실 수 있습니다.

RSS 구독 안내 보기