Lv.2 초급PostgreSQL

2026.04.1236분 읽기Lv.2 초급

시리즈왜 PostgreSQL이죠? · 파트 5/5시리즈 허브 보기

왜 PostgreSQL이죠? Part 5 — 생태계 확장: pgvector, PostGIS, TimescaleDB

PostgreSQL에 확장 하나를 더하면 벡터 검색·지도·시계열·전문 검색까지 한 엔진 안에서 논의됩니다. 이 마지막 편에서는 pgvector·PostGIS·TimescaleDB·ParadeDB(pg_search)의 강점과 공개 벤치마크·사례를 함께 짚고, ‘모든 것을 PostgreSQL로’라는 말이 통하는 조건과 한계를 나눕니다. 비교 수치는 관리형·자가 호스팅, 튜닝 전제가 다르면 해석이 달라질 수 있어 방향성으로 읽고 원문 조건을 확인하는 편이 안전합니다. 시리즈 전반의 질문인 ‘왜 PostgreSQL인가’에 대해 생태계·신뢰·운영 관점에서 최종 정리를 덧붙이며, 스택을 단순화할지·별도 제품을 둘지 판단할 때 참고할 만한 기준도 함께 제시합니다.

시리즈 구성

• Part 1 — 숫자로 보는 PostgreSQL의 현재 위치
• Part 2 — 빅테크는 왜 PostgreSQL을 선택했나
• Part 3 — 스타트업의 선택: 속도와 비용의 최적점
• Part 4 — MongoDB·Oracle 탈출기: 실제 마이그레이션 사례
• Part 5 — 생태계 확장: pgvector, PostGIS, TimescaleDB (현재 편 · 시리즈 완결)

목차

1. 들어가며: "하나의 데이터베이스로 모든 것을"이라는 아이디어
2. pgvector — AI 시대, PostgreSQL이 벡터 DB 시장을 흔든 방식
3. PostGIS — 25년 된 확장이 여전히 지리정보의 표준인 이유
4. TimescaleDB — Cloudflare가 ClickHouse 대신 선택한 이유
5. ParadeDB — Elasticsearch 없이 전문 검색을 PostgreSQL 안에서
6. 확장 생태계의 현재: 2025년 가장 많이 쓰이는 확장들
7. PostgreSQL 극대주의(Maximalism)의 명암
8. 시리즈를 마치며: "왜 PostgreSQL인가"에 대한 최종 답변

1. 들어가며: "하나의 데이터베이스로 모든 것을"이라는 아이디어

PostgreSQL 확장 생태계를 처음 접한 사람들이 종종 하는 말이 있습니다.

"이거 다 되면 다른 DB가 왜 필요하죠?"

틀린 말은 아닙니다. 그리고 완전히 맞는 말도 아닙니다.

pgvector를 추가하면 별도 벡터 전용 스토어가 꼭 필요하지 않을 수 있습니다. PostGIS를 추가하면 별도 지리정보 엔진 없이도 많은 공간 쿼리를 처리할 수 있습니다. TimescaleDB를 추가하면 시계열 전용 제품을 쓸 이유가 줄어듭니다. ParadeDB의 pg_search를 쓰면 Elasticsearch를 유지할 부담이 줄 수 있습니다. 동시에 워크로드·규모·운영 조건에 따라 여전히 전용 제품이 유리한 경우도 분명합니다.

이 글은 2025년 전후의 공개 자료·벤치마크·사례를 바탕으로 네 가지 축을 짚되, 조건부 결론을 숨기지 않습니다. "완전 대체"가 아니라 어느 구간까지는 PostgreSQL 확장으로 충분한지를 구분해 말합니다.

사례·벤치마크를 읽는 방법

아래에 등장하는 비용·지연 시간·처리량은 설득력 있는 신호이지만, 출처가 벤더·공개 벤치마크·블로그인 경우가 많습니다. 관리형과 자가 호스팅, 측정에 포함된 비용 항목, 튜닝·하드웨어 전제가 다르면 같은 숫자라도 의미가 달라집니다. 방향성으로 읽고 세부는 원문 전제를 확인하는 편이 안전합니다.

또한 Cloudflare·Redfin·IGN처럼 이름이 큰 사례는 그 조직의 스택·팀·SLA가 여러분의 환경과 다를 수 있습니다. "저기서 됐다"와 "우리에게 바로 맞다" 사이에는 간극이 있으므로, 본문 후반의 기준표와 함께 데이터 증가율, 운영 인력, 장애 허용치, 규제 요구 같은 입력값을 스스로 적어 보는 것을 권합니다.

2. pgvector — AI 시대, PostgreSQL이 벡터 DB 시장을 흔든 방식

Part 3에서 pgvector의 비용·제품 측면을 다뤘다면, 여기서는 공개 벤치마크를 중심으로 성능 논의를 정리합니다.

2025년 전후로 자주 인용되는 비교

pgvector와 Timescale이 공개한 pgvectorscale 조합을 Pinecone, Qdrant 등과 비교한 자료에서는, 대략 5천만 개 규모의 Cohere 임베딩(768차원) 데이터셋을 전제로 한 요약이 자주 인용됩니다.

Qdrant와의 비교에서는 두 시스템 모두 50M 벡터 기준 100ms 이하 수준의 쿼리 지연을 달성했다는 식의 보고가 나옵니다. 다만 Qdrant는 tail latency(p99) 분산이 작아 지연 일관성이 중요한 환경에서 강점을 가진다는 평가도 함께 제기됩니다. 이런 비교는 공개 벤치마크·커뮤니티 논의에 기반한 경우가 많으므로, Qdrant 측 공식 벤치마크나 팀 내 재현 결과와 함께 읽는 편이 좋습니다.

2025년 5월 전후 AWS가 공개한 pgvector 0.8.0 + Aurora PostgreSQL 벤치마크에서는 특정 쿼리 패턴에서 이전 버전 대비 최대 5.7배 수준의 성능 향상이 보고되었고, 필터링된 벡터 검색에서의 결과 누락 문제를 줄이기 위한 iterative_scan 등이 언급되었습니다.

비교 수치를 읽는 방법: 위 표는 공개 벤치마크·블로그의 요약이며, Pinecone은 관리형 서비스이고 pgvector 조합은 자가 호스팅(또는 RDS/Aurora) 전제인 경우가 많습니다. 운영 인력·업타임·네트워크 비용까지 동일 선상에 놓지 않으면 비용 비교가 과대·과소 해석될 수 있습니다. 튜닝·인덱스·워크로드에 따라 순위는 바뀔 수 있으므로, 방향성으로 읽고 원문의 조건을 확인하는 편이 안전합니다.

pgvector의 실제 활용 패턴

pgvector의 큰 강점은 벡터 검색과 관계형 조건을 단일 SQL로 묶을 수 있다는 점입니다.

-- 의미적 유사도 검색 + 관계형 필터를 하나의 쿼리로
-- (<-> 는 distance: 값이 작을수록 더 유사함)
SELECT
  doc_id,
  title,
  created_at,
  embedding <-> $1 AS distance_score
FROM documents
WHERE
  user_id = $2
  AND language = 'ko'
  AND created_at > NOW() - INTERVAL '30 days'
ORDER BY distance_score ASC
LIMIT 10;

전용 벡터 스토어에서는 이 패턴을 구현하려면 여러 시스템에 나누어 요청한 뒤 애플리케이션에서 조합해야 하는 경우가 많습니다. PostgreSQL에서는 플래너·인덱스와 함께 한 경로에서 다룰 수 있습니다.

솔직한 한계

수백만~수천만 개 규모의 벡터, RAG 파이프라인, 멀티테넌트 SaaS에서는 pgvector가 매우 실용적인 선택인 경우가 많습니다. 반면 수억 개 이상 규모, GPU 가속이 필수인 워크로드, 수 ms 이하 지연이 SLA로 박혀 있는 환경에서는 Pinecone, Milvus 같은 전용 솔루션이 여전히 유리할 수 있습니다.

"PostgreSQL로 시작하고, 한계에 부딪히면 이전한다"는 조언은 여전히 유효합니다. 그리고 많은 팀은 그 한계에 도달하기 전에 제품·조직의 다른 병목을 먼저 만납니다.

3. PostGIS — 25년 된 확장이 여전히 지리정보의 표준인 이유

PostGIS는 2001년에 처음 등장했습니다. 2020년대 들어 PostgreSQL 확장 사용 빈도 조사에서도 상위권에 반복적으로 이름을 올립니다.

PostGIS가 해결하는 문제

위도·경도를 단순 숫자로만 저장하면 "반경 2km 안의 매장" 같은 질의가 전체 스캔으로 이어지기 쉽습니다. PostGIS는 공간 인덱스(GiST, R-tree 등) 로 이 문제를 완화합니다.

점·선·다각형 등 공간 타입, ST_Distance, ST_Intersects, ST_Buffer 같은 공간 함수, OGC에 가까운 좌표계 처리까지, 애플리케이션에서 지도 좌표를 다루는 데 필요한 도구가 확장 형태로 제공됩니다.

실제 적용 사례들

Redfin — 미국 부동산 플랫폼 Redfin은 MySQL에서 PostgreSQL + PostGIS 로 전환한 뒤 성능·안정성 측면에서 개선을 보고했습니다. 대규모 매물 데이터를 공간 쿼리로 처리하는 패턴이 대표적입니다.

IGN(프랑스 국립지리원) — 고해상도 지형 데이터를 PostGIS로 관리하는 사례로 자주 인용됩니다. 대규모 지형지물과 동시 편집·일관성 요구가 함께 있는 환경에서 단일 데이터베이스 트랜잭션의 이점이 강조됩니다.

배달·모빌리티 — "현재 위치 기준 반경 N km 이내 라이더" 같은 질의는 공간 인덱스가 있을 때와 없을 때 운영 난이도가 크게 달라집니다.

통신·인프라 — 기지국·케이블 경로·커버리지 폴리곤을 같은 DB에 두고 비즈니스 데이터와 조인해 분석하려는 수요도 흔합니다.

이처럼 PostGIS가 쓰이는 영역은 도시계획, 환경, 물류 등 공간 데이터가 등장하는 대부분의 도메인에 이릅니다. 전용 GIS 스택과 비교했을 때 비즈니스 데이터와 공간 데이터를 한 트랜잭션·한 운영 경로에 둘 수 있다는 점이 반복해서 강조됩니다.

사례를 읽는 방법: 위 조직들의 트래픽·데이터 모델·규제 요구는 서로 다릅니다. "규모가 비슷하다"고 해서 곧바로 같은 구성을 따라가기보다, 공간 질의 빈도, 인덱스 전략, 좌표계 일관성을 먼저 점검하는 편이 안전합니다.

4. TimescaleDB — Cloudflare가 ClickHouse 대신 선택한 이유

시계열 전용 제품으로는 InfluxDB, ClickHouse, Apache Druid 등이 널리 쓰입니다. PostgreSQL 쪽에서는 TimescaleDB 가 시계열·분석 워크로드에서 자주 거론됩니다.

Cloudflare의 선택

Cloudflare는 트랜잭션 워크로드에 PostgreSQL을 쓰는 조직으로 알려져 있고, 분석 워크로드에는 ClickHouse를 활용해 왔습니다. 2025년 7월 전후 공개된 엔지니어링 블로그에서는 새 분석 기능에 ClickHouse가 아닌 TimescaleDB 를 선택했다고 설명합니다.

이유로는 (1) TimescaleDB가 PostgreSQL 확장이라 기존 인프라 위에서 하이퍼테이블과 일반 테이블을 함께 다루기 쉽다는 점, (2) 연속 집계(continuous aggregates) 로 커스텀 cron·배치 없이 실시간에 가까운 집계를 자동화할 수 있다는 점이 제시되었습니다. 공개 수치로는 쿼리 지연 5~35배 개선, 스토리지 사용량 33배 감소 같은 표현이 등장합니다(측정 구간·워크로드 전제는 원문을 확인해야 합니다).

TimescaleDB가 하는 일

하이퍼테이블은 시간 기준 청크로 파티셔닝을 자동화하는 추상화입니다. 겉보기에는 일반 테이블과 비슷하지만, 대규모 시계열에서 최근 구간만 자주 읽는 패턴에 유리합니다.

연속 집계는 PostgreSQL의 일반적인 Materialized View와 갱신 방식이 다릅니다. 전체 재계산이 아니라 변경분 위주로 갱신하는 쪽에 가깝다고 이해할 수 있어, 대시보드용 "최근 7일 시간당 평균" 같은 지표를 운영하기 쉽습니다.

컬럼 스토어 등 압축 옵션은 시계열 데이터에 맞춰 스토리지 비용을 줄이는 데 기여한다고 알려져 있습니다. "통상 90% 이상 압축" 같은 표현은 데이터 패턴·중복도에 따라 달라질 수 있습니다.

실제 활용 도메인

IoT 센서, 금융 틱, 애플리케이션 메트릭, 서버 모니터링 등 타임스탬프가 중심인 데이터가 지속 유입되는 곳이 전형적인 사용 사례입니다. 주요 클라우드에서도 관리형 PostgreSQL과 함께 또는 별도 서비스 형태로 Timescale을 쓰는 경로가 있습니다.

5. ParadeDB — Elasticsearch 없이 전문 검색을 PostgreSQL 안에서

Elasticsearch는 강력하지만, 별도 클러스터 운영·동기화·모니터링 이중화 부담이 큽니다.

ParadeDB의 pg_search 는 BM25 랭킹을 PostgreSQL 확장으로 가져와, 별도 검색 엔진 없이 관련성 있는 전문 검색을 시도하게 합니다.

pg_search가 제공하는 것

@@@ 연산자로 BM25 기반 검색을 실행하는 예시는 다음과 같습니다.

SELECT title, rating, description
FROM products
WHERE description @@@ 'comfortable running shoes'
  AND rating >= 4.0
ORDER BY paradedb.score(id) DESC
LIMIT 10;

기존 PostgreSQL의 tsvector / tsquery 중심 전문 검색은 키워드 매칭에 가깝습니다. BM25는 문서 길이·용어 빈도를 함께 고려하는 쪽에 가깝고, 퍼지 매칭·구문 검색·필드 부스트·JSON 필드 인덱싱 등을 확장 쪽에서 다루려는 시도로 읽을 수 있습니다. pgvector와 결합한 하이브리드 검색(키워드 + 벡터) 시나리오도 문서화되어 있습니다.

성숙도·운영 관점

커뮤니티에서는 Elasticsearch를 줄이거나 교체한 사례가 보고되지만, 대규모 프로덕션에서의 운영 이력·버전 호환·장애 대응 체계는 제품마다 편차가 큽니다. ParadeDB/pg_search를 도입할 때는 문서 버전, PostgreSQL 메이저 버전, 지원 정책을 먼저 확인하고, 스테이징에서 부하·장애 복구 시나리오를 밟아 보는 편이 안전합니다. "스택이 단순해진다"는 이점과 "검색 전용 클러스터를 대체할 만큼 숙련이 쌓였는가"는 별도 질문입니다.

6. 확장 생태계의 현재: 2025년 가장 많이 쓰이는 확장들

2024년 State of PostgreSQL 설문(Tiger Data / Timescale 주관)에서는 사용 빈도 기준 상위 확장으로 대략 다음이 거론됩니다.

빠르게 쓰이는 확장으로는 pg_cron(스케줄 작업), pg_partman(파티션 관리), pgaudit(감사 로그) 등도 자주 언급됩니다.

7. PostgreSQL 극대주의(Maximalism)의 명암

"하나의 PostgreSQL로 모든 것을"이라는 아이디어를 커뮤니티에서는 PostgreSQL Maximalism 이라고 부르기도 합니다. 매력과 한계를 나란히 둡니다.

명(明): 스택 단순화의 실질적 가치

관리 지점이 줄어들면 소규모 팀에 직접적인 이득이 됩니다. 별도 검색 클러스터·별도 동기화 코드·별도 시계열 클러스터를 줄일 수 있다면, 장애 대응 시 확인해야 할 경로도 줄어듭니다.

암(暗): 모든 문제에 최선은 아님

수억 개 벡터를 ms 단위 SLA로 다뤄야 한다면 pgvector만으로는 부족할 수 있습니다. 초당 수백만 건의 메트릭 인제스트와 초대형 분석을 동시에 밀어 넣어야 한다면 ClickHouse·Druid 같은 선택이 더 맞을 수 있습니다. 확장이 훌륭하다는 것과 모든 상황에서 1위라는 것은 다릅니다.

언제 확장으로 충분하고, 언제 별도 시스템을 볼 것인가

의사결정에 넣으면 좋은 입력값

표의 "어느 칸에 가깝나"만으로는 부족할 때가 많습니다. 아래를 같이 적어 보면 선택이 선명해집니다.

• 데이터 증가율과 12개월 뒤의 규모 추정
• 운영 인력(풀타임 DBA 유무, 온콜 구조)
• 장애 허용치(허용 다운타임, 복구 시간 목표)
• 규제·감사(로그 보존, 접근 통제, 특정 인증 요구)
• TCO 추정 방식(라이선스·스토리지·인건비·교육 비용 포함 여부)

8. 시리즈를 마치며: "왜 PostgreSQL인가"에 대한 최종 답변

다섯 편에 걸쳐 다룬 내용을 한 문단으로 압축하면 다음과 같습니다.

PostgreSQL이 선택받는 까닭은 "항상 가장 빠르고, 항상 가장 쉽기" 때문만은 아닙니다. 검증 가능한 운영 경험, 확장으로 덮을 수 있는 폭넓은 워크로드, 깊은 생태계, 그리고 선택을 후회할 확률을 낮추는 보수적인 기본값이 함께 작동하기 때문입니다.

Instagram·Coinbase·Zalando, YC 스타트업의 상당수가 선택하는 스택, Infisical·Oracle 탈출 사례, Cloudflare의 TimescaleDB 선택, AI 스타트업의 pgvector 채택까지 — 공통점은 하나로 수렴합니다. "필요한 것을 충분히 잘 해 주면서, 오래 함께 가기 쉬운 선택인가" 에 대한 판단입니다.

35년 전 연구 프로젝트에서 출발한 데이터베이스가, 설문·시장 지표에서 반복해서 상위에 이름을 올리는 것은 우연이 아닙니다. 활발한 릴리스, 커뮤니티, 오픈소스 거버넌스가 쌓인 결과입니다.

"왜 PostgreSQL이죠?"에 대한 가장 짧은 답은 이것입니다.

다른 선택을 해야 할 명확한 이유가 없다면, PostgreSQL이 기본 후보에 오른다.

시리즈 전체 요약

이 블로그에서 이어질 주제

이 시리즈는 여기서 마무리합니다. 파이프라인·ELT·관측처럼 데이터가 DB 안에만 머물지 않는 흐름은 데이터 엔지니어링 주제와 예정 시리즈에서 이어갈 예정입니다. RSS 안내에서 피드를 받아 두면 새 글을 놓치기 어렵습니다.

참고·출처

• Timescale — pgvector vs Pinecone · State of PostgreSQL 2024 (Tiger Data / Timescale 주관 설문)
• Qdrant — Benchmarks
• AWS — Database Blog (Aurora·pgvector 관련 게시) · pgvector 릴리스 노트
• PostGIS — 공식 문서
• Cloudflare — Engineering Blog (TimescaleDB 도입 관련 게시, 2025년 전후 공개 자료)
• ParadeDB / pg_search — GitHub

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