모던 PostgreSQL 2026 — Postgres 17 / 18 / pgvector / pgvectorscale / pgai / TimescaleDB / PostGIS / Citus 심층 가이드

"PostgreSQL is the world's most advanced open source relational database — and in 2026, it is quietly becoming the world's most advanced open source vector database, time-series database, geospatial database, and search engine, too." — Andrew Kane (pgvector author), PGConf NYC 2024

PostgreSQL은 1986년 UC Berkeley의 POSTGRES 프로젝트에서 시작된 거의 40년 된 데이터베이스입니다. 그런데 2026년 5월 현재, "지난 5년이 그 이전 30년보다 더 큰 변화의 시기였다"는 말이 나옵니다. pgvector가 OpenAI와 Anthropic의 RAG 표준이 되고, TimescaleDB가 시계열 시장을 흡수하고, PostGIS가 사실상 모든 지리정보 시스템의 기본이 되고, Supabase·Neon이 "Postgres as a service"를 다시 정의하면서, PostgreSQL은 더 이상 "관계형 DB 중 하나"가 아니라 하나의 플랫폼이 되었습니다.

이 글에서는 Postgres 17(2024.9)과 Postgres 18(2025.9)의 핵심 기능부터, pgvector·pgvectorscale·pgvector.rs·pgai로 이어지는 벡터 익스텐션 진화, TimescaleDB·PostGIS·pgRouting, PgBouncer·Pgpool-II 커넥션 풀링, Citus·Hydra·Tembo·Crunchy Data 같은 분산/클라우드 옵션, 그리고 pgmustard·Postgres.ai의 AI 기반 운영 도구까지 한 번에 정리합니다.

1. 2026년 Postgres — 모든 DB의 대안

2026년 5월 현재, PostgreSQL은 거의 모든 데이터베이스 카테고리에서 "그냥 충분히 좋은" 옵션이 되었습니다. DB-Engines Ranking에서 Postgres는 2023년 처음으로 MySQL을 제쳤고, 2024년 Stack Overflow Developer Survey에서는 49.0% 채택률로 1위에 올랐으며, 이 흐름은 2025년·2026년에도 유지되고 있습니다.

이 표가 의미하는 것은 "Postgres가 모든 카테고리의 1위"가 아니라, "한 팀이 5개 DB를 운영하는 대신 Postgres 하나로 80% 요구사항을 해결할 수 있다"는 것입니다. Stripe·Notion·Linear·Vercel·Cloudflare가 공개적으로 자사 메인 DB를 Postgres로 유지하는 이유이기도 합니다.

PostgreSQL Global Development Group(PGDG)은 매년 9월에 한 번씩 메이저 릴리스를 내며, 5년간 보안 패치를 지원합니다. 2026년 5월 기준으로 활발하게 지원되는 버전은 14·15·16·17·18(5개)이며, 13은 2025년 11월에 EOL되었습니다.

2. Postgres 17 (2024.9) — Incremental Backup / MERGE 개선 / JSON_TABLE

PostgreSQL 17은 2024년 9월 26일에 릴리스되었습니다. 17의 가장 큰 사용자 가시 기능 세 가지는 incremental backup, MERGE 개선, JSON_TABLE입니다.

Incremental Backup: pg_basebackup --incremental=manifest_path 형태로, 마지막 풀 백업 이후 변경된 페이지만 백업할 수 있게 되었습니다. 기존에는 pgBackRest·WAL-G 같은 외부 도구로만 가능했던 기능이 코어로 들어왔습니다. TB 단위 DB의 일일 백업 시간이 8시간에서 30분으로 줄었다는 보고가 다수 나옵니다.

# 풀 백업
pg_basebackup -D /backup/full --manifest-checksums=SHA256

# 인크리멘털 백업 (전날 백업 manifest 참조)
pg_basebackup -D /backup/incr-2026-05-16 \
  --incremental=/backup/full/backup_manifest

# 복구 시: pg_combinebackup으로 풀+인크리멘털을 합침
pg_combinebackup /backup/full /backup/incr-2026-05-16 -o /restore

MERGE 개선: SQL 2003부터 표준이었던 MERGE는 Postgres 15에서 처음 들어왔지만, 17에서 RETURNING 절과 WHEN NOT MATCHED BY SOURCE 지원이 추가되었습니다. UPSERT 패턴이 더 깔끔해졌고, 특히 데이터 동기화·CDC 적용 시 유용합니다.

MERGE INTO orders_summary t
USING new_orders s ON t.order_id = s.order_id
WHEN MATCHED THEN UPDATE SET total = s.total
WHEN NOT MATCHED BY TARGET THEN INSERT VALUES (s.order_id, s.total)
WHEN NOT MATCHED BY SOURCE THEN DELETE
RETURNING merge_action(), t.order_id;

JSON_TABLE: SQL/JSON 표준의 JSON_TABLE 함수가 들어와, JSONB 컬럼을 관계형 테이블처럼 쿼리할 수 있게 되었습니다.

SELECT jt.*
FROM events e,
  JSON_TABLE(e.payload, '$.items[*]' COLUMNS (
    sku TEXT PATH '$.sku',
    qty INT  PATH '$.qty',
    price NUMERIC(10,2) PATH '$.price'
  )) jt;

그 외에도 VACUUM 메모리 사용량 20분의 1로 감소, streaming I/O 인터페이스, identity column에 OVERRIDING 추가, pg_stat_statements에 query_id 정규화 개선 등이 들어갔습니다. PostgreSQL 17은 "성능과 운영성 강화"가 핵심 테마입니다.

3. Postgres 18 (2025.9) — Virtual Generated Columns / OAuth2

PostgreSQL 18은 2025년 9월 25일에 릴리스되었습니다. 18의 두 가지 큰 변화는 virtual generated columns와 OAuth2 인증입니다.

Virtual Generated Columns: 기존에는 generated column이 STORED(저장됨)만 지원했지만, 18부터 VIRTUAL(쿼리 시 계산) 옵션이 추가되었습니다. 저장 공간을 쓰지 않으면서도 계산된 컬럼을 인덱스·뷰·쿼리에서 사용할 수 있습니다.

CREATE TABLE products (
  id BIGSERIAL PRIMARY KEY,
  price_cents INT NOT NULL,
  vat_rate NUMERIC(5,2) NOT NULL DEFAULT 10.0,
  price_with_vat NUMERIC(12,2)
    GENERATED ALWAYS AS (price_cents * (1 + vat_rate/100) / 100) VIRTUAL
);

CREATE INDEX idx_products_price_with_vat ON products(price_with_vat);

OAuth2 / OIDC 인증: 18부터 pg_hba.conf에서 oauth 인증 방식을 지원합니다. Auth0, Okta, Azure AD, Google Workspace 같은 IdP가 발급한 JWT 토큰으로 Postgres에 직접 로그인할 수 있게 되었습니다. 기존에는 PgBouncer·CloudNativePG·Crunchy 같은 외부 레이어가 필요했습니다.

# pg_hba.conf (Postgres 18)
host all all 0.0.0.0/0 oauth issuer="https://auth.example.com" \
  scope="postgres" validator="example_validator"

그 외에 asynchronous I/O(io_uring 기반, 시퀀셜 스캔·VACUUM 가속), skip scan for B-tree(다중 컬럼 인덱스의 첫 컬럼 스킵), UUID v7 지원, logical replication에서 sequence 복제, temporal table syntax 일부 지원, pg_stat_io의 컬럼 추가 등이 들어갔습니다. 18은 17보다 더 "성능"에 치우친 릴리스이고, 특히 SSD/NVMe 환경에서 io_uring 기반 비동기 I/O가 큰 영향을 미칩니다.

4. pgvector — 가장 핫한 익스텐션

pgvector는 Andrew Kane이 2021년에 만든 익스텐션으로, Postgres에 vector 데이터 타입과 거리 함수(L2, inner product, cosine)와 HNSW / IVFFlat 인덱스를 추가합니다. 2023년 OpenAI 임베딩 API의 폭발적 성장 + RAG 패턴의 표준화와 함께 pgvector는 사실상 "Postgres에서 벡터를 다루는 표준"이 되었습니다.

2026년 5월 현재 최신 버전은 0.8.x이며, AWS RDS·GCP Cloud SQL·Azure Database for PostgreSQL·Supabase·Neon·Crunchy Bridge에서 모두 기본 제공됩니다.

CREATE EXTENSION vector;

CREATE TABLE documents (
  id BIGSERIAL PRIMARY KEY,
  content TEXT NOT NULL,
  embedding vector(1536)  -- OpenAI text-embedding-3-small
);

-- HNSW 인덱스 (PG 16+, pgvector 0.5+)
CREATE INDEX ON documents
  USING hnsw (embedding vector_cosine_ops)
  WITH (m = 16, ef_construction = 64);

-- top-K 유사도 검색
SELECT id, content, embedding <=> '[0.1, 0.2, ...]'::vector AS distance
FROM documents
ORDER BY embedding <=> '[0.1, 0.2, ...]'::vector
LIMIT 10;

pgvector의 두 가지 인덱스 옵션:

• IVFFlat (Inverted File with Flat compression): 데이터를 K개의 클러스터로 나누고, 쿼리 시 가까운 클러스터만 스캔. 빌드는 빠르지만 데이터가 변경되면 재빌드 필요.
• HNSW (Hierarchical Navigable Small World): 그래프 기반 인덱스, 빌드는 느리지만 동적 업데이트 지원 + 일반적으로 더 높은 recall. 2026년 기준 "기본 선택지"는 HNSW.

pgvector의 한계는 인덱스가 메모리에 들어가야 빠르다는 점입니다. 1억 벡터(1536차원, float32)는 약 600GB로, 단일 노드 RAM을 쉽게 초과합니다. 이 문제를 해결하기 위해 등장한 것이 다음 장의 pgvectorscale입니다.

5. pgvectorscale (Timescale, 2024.4) — Disk-Based 벡터 인덱스

Timescale은 2024년 4월에 pgvectorscale을 오픈소스(PostgreSQL License)로 공개했습니다. pgvectorscale의 핵심은 StreamingDiskANN 인덱스 — 마이크로소프트 리서치의 DiskANN 알고리즘을 Postgres에 포팅한 것 — 와 **Statistical Binary Quantization (SBQ)**입니다.

DiskANN은 인덱스의 대부분을 디스크에 두고도 SSD 한 번의 read로 KNN 검색을 끝내는 알고리즘입니다. pgvectorscale은 이를 통해 1억 벡터에서 95% recall + p95 latency 50ms를 단일 m6i.2xlarge 인스턴스(8 vCPU, 32GB RAM)로 달성한다고 발표했습니다. 같은 워크로드를 Pinecone은 8x s1.x4 pod(~$1200/월)로 처리하는데, pgvectorscale은 같은 머신($230/월)으로 처리할 수 있다는 비교가 인기를 끌었습니다.

CREATE EXTENSION vectorscale CASCADE;

CREATE TABLE documents (
  id BIGSERIAL PRIMARY KEY,
  embedding vector(1536)
);

-- StreamingDiskANN 인덱스 (디스크 기반)
CREATE INDEX ON documents
  USING diskann (embedding vector_cosine_ops)
  WITH (storage_layout = 'memory_optimized', num_neighbors = 50);

-- 검색은 pgvector와 동일한 연산자
SELECT id, embedding <=> $1::vector AS dist
FROM documents
ORDER BY embedding <=> $1::vector
LIMIT 10;

pgvectorscale의 장점은 단순히 디스크 사용량이 적다는 것이 아니라, "벡터 인덱스를 분산 시스템 없이 단일 Postgres에서 운영할 수 있다"는 데 있습니다. 1억 ~ 10억 벡터 규모를 단일 노드로 다루는 것이 가능해지면서, "벡터 DB로 Pinecone·Weaviate를 별도 운영"하는 패턴이 빠르게 줄고 있습니다.

비슷한 카테고리에는 lantern(Lantern Cloud), VectorChord(former pgvecto.rs CNPG fork)가 있고, 셋 다 "디스크 기반 벡터 인덱스 + Postgres"라는 동일한 비전을 공유합니다.

6. pgvector.rs / pgai — Rust 구현 + DB 안 임베딩

pgvector.rs (VectorChord): TensorChord 팀이 만든 Rust 기반 pgvector 호환 익스텐션입니다. 기존 pgvector는 C로 작성되어 있고 단일 백엔드 프로세스 내에서 동작하는데, pgvector.rs는 Rust + pgrx 프레임워크로 작성되어 더 안전하고 더 빠른 인덱스 빌드를 목표로 합니다. 2025년 말 VectorChord로 리브랜딩되었으며, MIT 라이선스로 제공됩니다.

VectorChord의 강점은 rabbit hole 알고리즘 — 자체 개발한 IVF 변형으로, 빌드 속도가 pgvector HNSW 대비 5~10배 빠르다고 발표했습니다. RAG 파이프라인에서 매일 수억 벡터를 재인덱싱하는 워크로드에 적합합니다.

CREATE EXTENSION vchord CASCADE;

CREATE INDEX ON documents
  USING vchordrq (embedding vector_l2_ops)
  WITH (options = $$
    residual_quantization = true
    [build.internal]
    lists = []
    spherical_centroids = false
  $$);

pgai (Timescale): pgai는 "Postgres 안에서 임베딩 생성부터 LLM 호출까지" 한 번에 처리하는 익스텐션입니다. 2024년에 출시되었고, 2025년에는 pgai Vectorizer라는 더 큰 워크플로 도구로 확장되었습니다.

-- OpenAI 임베딩을 SQL 함수로 호출
SELECT ai.openai_embed(
  'text-embedding-3-small',
  'PostgreSQL is the world''s most advanced open source database'
);

-- 자동 벡터화 (Vectorizer)
SELECT ai.create_vectorizer(
  'public.blog_posts'::regclass,
  destination => 'blog_embeddings',
  embedding => ai.embedding_openai('text-embedding-3-small', 1536),
  chunking => ai.chunking_recursive_character_text_splitter('content'),
  scheduling => ai.scheduling_timescaledb()
);

pgai의 발상은 "임베딩을 만들기 위해 데이터를 DB에서 꺼냈다가 다시 넣는 ETL 파이프라인 자체를 없애자"는 것입니다. Anthropic Claude, OpenAI, Cohere, Ollama, Voyage AI, HuggingFace를 모두 지원하며, 임베딩이 자동으로 동기화됩니다.

이 두 익스텐션(pgvectorscale + pgai)이 결합되면, "RAG 인프라 전체를 Postgres 안에 넣는다"는 비전이 실제로 동작합니다. Timescale은 2024~2025년 동안 이 메시지를 가장 강하게 밀고 있는 회사입니다.

7. TimescaleDB — 시계열 + AI ops

TimescaleDB는 2017년 Timescale Inc.가 만든 시계열 익스텐션으로, **하이퍼테이블(hypertable)**이라는 자동 파티셔닝 추상화가 핵심입니다. 일반 테이블처럼 보이지만 시간/공간 기준으로 자동 청크 분할되고, 청크 단위로 압축·삭제·롤업이 일어납니다.

CREATE EXTENSION timescaledb;

CREATE TABLE metrics (
  time TIMESTAMPTZ NOT NULL,
  device_id TEXT NOT NULL,
  cpu DOUBLE PRECISION,
  mem DOUBLE PRECISION
);

SELECT create_hypertable('metrics', 'time', chunk_time_interval => INTERVAL '1 day');

-- 컬럼나 압축
ALTER TABLE metrics SET (
  timescaledb.compress,
  timescaledb.compress_segmentby = 'device_id'
);

SELECT add_compression_policy('metrics', INTERVAL '7 days');

-- 연속 집계 (continuous aggregate)
CREATE MATERIALIZED VIEW metrics_hourly
WITH (timescaledb.continuous) AS
SELECT time_bucket('1 hour', time) AS hour,
       device_id,
       avg(cpu) AS avg_cpu
FROM metrics
GROUP BY hour, device_id;

TimescaleDB의 매력은 시계열 특화 기능을 Postgres SQL로 그대로 쓸 수 있다는 것입니다. time_bucket, first, last, lag, gap fill 같은 함수와, hypercore(2024년 도입된 압축+로우 혼합 스토리지) 덕분에 InfluxDB·Prometheus와 직접 경쟁할 수 있습니다.

2024~2025년에 Timescale은 회사 전체를 "Postgres + AI ops"로 리포지셔닝했고, TimescaleDB·pgvector·pgvectorscale·pgai 네 익스텐션을 묶어 Timescale Cloud로 판매합니다. 한국에서는 SK텔레콤, 카카오모빌리티, 일본에서는 라쿠텐, ANA가 사용 사례를 공개했습니다.

라이선스는 Apache 2.0(코어)와 Timescale License(고급 기능, 비-AWS-SaaS 사용 제한)로 이원화되어 있으며, AWS RDS에서 사용하려면 Timescale Cloud로 가야 합니다.

8. PostGIS / pgRouting — 지리정보

PostGIS는 2001년 Refractions Research가 만든 지리정보 익스텐션으로, Postgres에 GEOMETRY·GEOGRAPHY 타입과 3000개 넘는 공간 함수를 추가합니다. 2026년 5월 현재 최신 버전은 3.5.x이며, OpenStreetMap, Esri, MapBox, Google Maps의 백엔드 일부도 PostGIS 기반입니다.

CREATE EXTENSION postgis;

CREATE TABLE places (
  id BIGSERIAL PRIMARY KEY,
  name TEXT,
  location GEOGRAPHY(POINT, 4326)
);

CREATE INDEX places_location_idx ON places USING GIST(location);

-- 반경 500m 안 검색
SELECT name, ST_Distance(location, my_point) AS dist
FROM places, (SELECT ST_MakePoint(127.0, 37.5)::geography AS my_point) p
WHERE ST_DWithin(location, my_point, 500)
ORDER BY dist
LIMIT 20;

PostGIS는 단순한 좌표 저장이 아니라, 공간 조인, Voronoi, Convex Hull, isochrone, 공간 클러스터링(DBSCAN, K-Means), raster 처리, 3D 메쉬 같은 고급 기능을 모두 SQL로 제공합니다. 부동산·물류·여행·자율주행·기상 산업의 사실상 모든 데이터 백엔드입니다.

pgRouting은 PostGIS 위에 동작하는 익스텐션으로, Dijkstra, A*, TSP(Traveling Salesman), bidirectional A*, Yen's K-shortest path 같은 그래프 알고리즘을 SQL로 제공합니다. OpenStreetMap 데이터를 그대로 import해서 라우팅 서비스를 만들 수 있습니다.

-- OSRM 없이도 SQL로 최단경로
SELECT * FROM pgr_dijkstra(
  'SELECT id, source, target, cost FROM ways',
  start_node_id, end_node_id, directed => true
);

2024년부터 MobilityDB(시공간 객체), H3-pg(Uber의 H3 hex grid 인덱싱)가 PostGIS 생태계에 합류하면서, "공간+시간+벡터" 통합 분석이 한 DB에서 가능해졌습니다. 한국에서는 카카오모빌리티·티맵·쿠팡 풀필먼트, 일본에서는 JR 동일본의 운행 분석에서 활용됩니다.

9. PgBouncer / Pgpool-II — 커넥션 풀링

Postgres는 프로세스 모델이라 커넥션 하나당 수십 MB의 메모리를 씁니다. Web/API 서버에서 수천 개의 짧은 커넥션이 몰리면 Postgres가 무릎을 꿇기 때문에, 사실상 모든 프로덕션 Postgres 앞에는 PgBouncer 또는 Pgpool-II가 놓입니다.

PgBouncer는 2007년 Skype가 만든 경량 커넥션 풀러로, 단일 프로세스 이벤트 루프로 수만 개의 클라이언트 커넥션을 적은 수의 Postgres 서버 커넥션으로 매핑합니다. 풀링 모드는 세 가지:

• session pooling: 클라이언트 세션 동안 같은 백엔드 사용 (기본)
• transaction pooling: 트랜잭션 동안만 백엔드 사용, 트랜잭션 종료 시 반환 (가장 인기)
• statement pooling: 문장 단위로 반환 (제한 많음)

# pgbouncer.ini
[databases]
mydb = host=postgres.local port=5432 dbname=mydb

[pgbouncer]
listen_port = 6432
pool_mode = transaction
max_client_conn = 10000
default_pool_size = 100
reserve_pool_size = 5

Pgpool-II는 PgBouncer보다 더 무겁고 더 많은 기능을 가집니다. 커넥션 풀링 + 로드밸런싱 + 자동 페일오버 + 쿼리 캐시 + parallel query를 모두 제공합니다. 다만 transaction pooling에서 일부 prepared statement 호환성 이슈가 있어, 단순 풀링에는 PgBouncer가, HA + 라우팅까지 묶고 싶을 때는 Pgpool-II가 선택됩니다.

2024~2025년에 pgcat(Rust 기반 Pgbouncer 호환)와 Supavisor(Supabase의 Elixir 기반 풀러, 디스크 IO 격리)가 등장했습니다. pgcat은 sharding과 load balancing을 한 프로세스에 묶었고, Supavisor는 Postgres 18의 OAuth2를 활용한 멀티테넌트 풀링을 지원합니다.

커넥션 풀링은 "단순한 인프라 디테일"로 보이지만, Postgres 운영 사고의 60% 이상이 커넥션 풀링 설정 미스에서 시작된다는 통계가 있을 정도로 중요합니다.

10. Citus / Hydra — 샤딩 / 컬럼나

Citus는 2016년 Citus Data가 만든 분산 Postgres 익스텐션으로, 2019년 Microsoft가 인수했습니다. 한 테이블을 여러 워커 노드에 자동으로 샤딩하고, coordinator 노드가 쿼리를 라우팅합니다. Azure Cosmos DB for PostgreSQL의 백엔드도 Citus입니다.

CREATE EXTENSION citus;

-- 워커 노드 등록
SELECT * FROM master_add_node('worker-1', 5432);
SELECT * FROM master_add_node('worker-2', 5432);

-- 테이블 샤딩 (distribution column 지정)
SELECT create_distributed_table('orders', 'customer_id');

-- 참조 테이블 (모든 워커에 복제)
SELECT create_reference_table('countries');

Citus는 단순 read scale-out이 아니라 distributed transactions, distributed JOIN, distributed PostgreSQL 기능까지 제공합니다. 다만 cross-shard JOIN의 성능은 distribution column 설계에 크게 의존하므로, "Citus는 멀티테넌트 SaaS에서만 정말 잘 동작한다"는 평이 일반적입니다.

2024년 Citus는 11.x → 12.x → 13.x로 빠르게 업그레이드되며, 13에서는 logical replication 기반 zero-downtime 샤드 리밸런싱이 들어왔습니다. 다만 2024년 말부터 Microsoft가 Citus 개발팀 인력을 축소했다는 보도가 있어, 커뮤니티는 Hydra Postgres·pgEdge·Spock(pgEdge가 만든 multi-master replication) 같은 대안에 관심을 보이고 있습니다.

Hydra는 Postgres에 컬럼나 스토리지를 추가하는 익스텐션입니다. DuckDB의 storage 엔진을 Postgres에 통합한 형태로, 분석 워크로드에서 행 기반 스토리지보다 10~100배 빠른 쿼리를 보여줍니다.

CREATE EXTENSION columnar;

CREATE TABLE events_columnar (
  time TIMESTAMPTZ, user_id BIGINT, event_type TEXT, payload JSONB
) USING columnar;

비슷한 카테고리에 pg_mooncake(Iceberg 기반 lakehouse Postgres), pg_lakehouse(ParadeDB), pg_analytics(Hydra의 후속 프로젝트)가 있고, 2025~2026년의 큰 흐름은 "OLTP는 행 기반, OLAP는 같은 Postgres 안의 컬럼나 테이블"입니다.

11. Tembo / Crunchy Data — Postgres 클라우드

Tembo는 2023년 출시한 Postgres 전용 클라우드 플랫폼으로, "Postgres + 익스텐션 마켓"이 핵심 메시지입니다. pgvector·pgvectorscale·pgmq·PostGIS·Hydra Columnar·pg_partman·pg_cron 같은 200개 넘는 익스텐션을 한 클릭으로 enable할 수 있고, 워크로드별 사전 구성된 "Stack"(VectorDB Stack, Time-series Stack, OLTP Stack, OLAP Stack)을 제공합니다.

Tembo의 차별점은 익스텐션 신뢰성입니다. 모든 익스텐션을 자동 빌드 + 테스트하는 Trunk 레지스트리를 운영하며(pgt.dev/trunk), 익스텐션 ABI 호환성·라이선스·CVE를 추적합니다. AWS RDS·GCP Cloud SQL이 익스텐션 추가에 6개월~2년이 걸리는 것과 대비됩니다.

Crunchy Data는 2012년부터 Postgres에 집중해 온 회사로, Crunchy Bridge(managed Postgres, AWS·Azure·GCP), Crunchy Postgres for Kubernetes(PGO operator), Crunchy Postgres for VMware가 주력 제품입니다. 정부·금융 등 컴플라이언스 요구가 강한 시장이 메인 타깃이고, FedRAMP·HIPAA·PCI-DSS 인증을 갖춘 Postgres SaaS로는 가장 오래된 선택지입니다.

2024년부터 Crunchy는 CloudNativePG(EDB와 Crunchy가 함께 기여한 K8s operator)에 인력을 투입했고, Kubernetes에서 Postgres를 운영하는 사실상 표준 operator가 되었습니다. 또한 Crunchy Data Warehouse(2025년 출시)는 Iceberg + Parquet + Postgres를 묶은 lakehouse 제품으로, Hydra·pg_mooncake와 같은 카테고리에서 경쟁합니다.

비교하자면 — Supabase는 풀스택 BaaS(Backend as a Service), Neon은 serverless Postgres + branching, Tembo는 익스텐션 중심 PaaS, Crunchy Bridge는 엔터프라이즈 컴플라이언스, AWS RDS / Aurora는 클라우드 통합. 한 회사가 모든 선택지를 동시에 쓰는 일은 거의 없지만, 워크로드별로 다른 Postgres 호스팅을 쓰는 패턴은 매우 흔합니다.

12. pglogical / pg_partman / pg_cron / pg_repack / pg_stat_statements — 운영 익스텐션

위에서 다룬 익스텐션이 "기능 추가" 중심이라면, 이 장에서 다룰 다섯 익스텐션은 "운영 자동화" 중심입니다.

pg_stat_statements: Postgres 12부터 contrib로 들어왔고, 사실상 모든 프로덕션 Postgres에서 활성화되어 있는 익스텐션입니다. 쿼리별 호출 횟수·총 시간·평균 시간·temp file 사용량을 집계해서, "느린 쿼리 TOP 20"을 SQL로 찾을 수 있게 해줍니다.

CREATE EXTENSION pg_stat_statements;

SELECT query, calls, mean_exec_time, total_exec_time, rows
FROM pg_stat_statements
ORDER BY total_exec_time DESC
LIMIT 20;

pg_partman: 시간/숫자 기준으로 테이블을 자동 파티셔닝하는 익스텐션입니다. Postgres 코어가 declarative partitioning을 지원하긴 하지만, 파티션 생성/삭제 자동화는 직접 짜야 합니다. pg_partman은 이 작업을 cron 한 줄로 끝냅니다.

SELECT partman.create_parent(
  p_parent_table => 'public.events',
  p_control => 'created_at',
  p_interval => '1 day',
  p_premake => 7,
  p_start_partition => '2026-05-01'
);

-- pg_cron + pg_partman 조합
SELECT cron.schedule('partition-maintenance', '0 3 * * *',
  $$ SELECT partman.run_maintenance(p_analyze => true) $$);

pg_cron: PostgreSQL 안에서 cron job을 실행하는 익스텐션입니다. Citus 팀이 만들었고, AWS RDS·GCP Cloud SQL·Azure·Tembo·Supabase·Neon에서 모두 기본 제공됩니다. VACUUM, REINDEX, 파티션 정리, materialized view refresh를 운영체제 cron 없이 DB 안에서 스케줄링합니다.

pg_repack: 운영 중인 테이블의 bloat 제거(자리 메우기)와 인덱스 재구성을 lock 없이 수행하는 익스텐션입니다. VACUUM FULL이 테이블 전체에 ACCESS EXCLUSIVE lock을 거는 반면, pg_repack은 임시 테이블에 복제 + 트리거 기반 동기화 + 짧은 swap으로 처리합니다. 운영 DB의 디스크 회수에 필수입니다.

pglogical: Postgres의 logical replication을 더 유연하게 만드는 익스텐션입니다. Postgres 코어의 logical replication은 동일 버전 간에서만 동작하지만, pglogical은 9.4 → 16 같은 메이저 버전 점프 + 양방향 복제 + 컬럼 필터링을 지원합니다. 대규모 Postgres 업그레이드(블루-그린 방식)에서 사실상 표준입니다.

다섯 익스텐션 모두 "운영자가 자기 손으로 짜야 했던 스크립트를 DB가 대신 해주는 것"이며, 한국·일본의 대형 Postgres 운영팀은 거의 항상 이 다섯 가지를 묶어 운영합니다.

13. pgmustard / Postgres.ai — Query Plan + AI

pgmustard는 영국의 두 명의 개발자(Michael Christofides, Nikolay Samokhvalov)가 만든 EXPLAIN ANALYZE 시각화 도구입니다. Postgres의 EXPLAIN ANALYZE 출력은 텍스트로 보기 어렵기로 악명이 높은데, pgmustard는 이를 시각적으로 보여주고 "어느 노드가 느린지", "왜 느린지", "어떻게 고치면 좋은지"를 자연어로 제안합니다.

# psql에서 JSON 형식으로 EXPLAIN
EXPLAIN (ANALYZE, FORMAT JSON, BUFFERS) SELECT ...;

# 결과를 pgmustard에 붙여넣기 (또는 CLI)
pgmustard plan.json

pgmustard는 2024년부터 "index suggestion"(누락된 인덱스를 추천), "rewrite suggestion"(쿼리 재작성), "bloat detection" 같은 자동화된 진단을 추가했습니다. SQL을 잘 모르는 개발자도 EXPLAIN 결과를 보고 행동할 수 있게 해주는 것이 핵심 가치입니다.

Postgres.ai는 Nikolay Samokhvalov가 만든 회사로, "DB Lab(논프로덕션 thin clone)"과 "Postgres AI Bot"이 주력 제품입니다. DB Lab은 ZFS/LVM snapshot을 활용해 TB 단위 DB를 초 단위로 clone해, 개발자가 자기 PR을 프로덕션과 같은 데이터로 테스트할 수 있게 합니다.

Postgres AI Bot은 2024년에 추가된 LLM 기반 어시스턴트로, "이 쿼리를 어떻게 빠르게 할까", "이 인덱스는 사용되고 있는가", "이 락은 왜 잡혀 있는가" 같은 질문에 EXPLAIN + pg_stat_statements + pg_locks를 자동 조회해 답합니다. SRE의 1차 트리아지를 자동화하는 것이 목표입니다.

비슷한 카테고리에는 Tigerdata Insights(Timescale), Datadog Database Monitoring, PgAnalyze(예전부터 가장 오래된 Postgres APM)이 있고, 2025~2026년의 큰 흐름은 "DBA 한 명을 LLM이 보조"입니다.

14. 백업 — pgBackRest / Barman / WAL-G / pg_dump

Postgres의 백업은 두 카테고리로 나뉩니다 — 물리 백업(데이터 디렉터리 + WAL)과 논리 백업(SQL dump). 둘은 용도가 완전히 다릅니다.

pg_dump / pg_dumpall: Postgres 기본 도구로, SQL 또는 custom 포맷으로 데이터를 덤프합니다. 작은 DB(수십 GB 이하)의 마이그레이션·테스트·아카이브에 적합합니다. 메이저 버전 점프 시 가장 안전한 방법이기도 합니다.

# 병렬 덤프 (custom format, jobs=8)
pg_dump -Fd -j 8 -f /backup/mydb.dir mydb

# 복원
pg_restore -d mydb_new -j 8 /backup/mydb.dir

pgBackRest: 가장 성숙한 물리 백업 도구로, 2026년 5월 현재 사실상 Postgres 백업의 de-facto standard입니다. 풀+인크리멘털+차등 백업, S3/GCS/Azure Blob 직접 업로드, 병렬 압축/암호화, PITR(Point-in-Time Recovery), encryption at rest, delta restore 같은 기능을 모두 제공합니다.

# pgbackrest.conf
[global]
repo1-path=/var/lib/pgbackrest
repo1-type=s3
repo1-s3-bucket=mybackups
repo1-s3-region=ap-northeast-2
repo1-retention-full=4

[mydb]
pg1-path=/var/lib/postgresql/17/data

# 풀 백업
pgbackrest --stanza=mydb backup --type=full

# PITR 복원
pgbackrest --stanza=mydb restore --target="2026-05-16 12:00:00" --type=time

Barman: 이탈리아 2ndQuadrant(현재 EDB)가 만든 백업 도구로, pgBackRest보다 오래되었고 텔코·금융 같은 보수적인 시장에서 많이 쓰입니다. Streaming WAL receiver, rsync 기반 백업, 다중 서버 관리가 강점입니다.

WAL-G: Citus Data가 만든 Go 기반 백업 도구로, S3 친화적 + 단순한 설정이 강점입니다. delta 백업·암호화·압축을 지원하며, AWS·GCP·Azure·Yandex 등 다양한 백엔드를 지원합니다.

# WAL-G 기본 백업
WALG_S3_PREFIX=s3://mybackups/mydb wal-g backup-push /var/lib/postgresql/17/data

# 복원
wal-g backup-fetch /restore LATEST

세 도구 모두 WAL archiving(archive_command 설정)을 전제로 동작하므로, "백업이 있는데 PITR이 안 된다"는 사고를 피하려면 archive_command 설정과 archive_status 모니터링이 가장 중요합니다.

마지막으로 pgexporter는 Prometheus용 Postgres 메트릭 익스포터로, 백업과 함께 운영 가시성을 책임집니다. Grafana 대시보드와 묶어 백업 성공률·WAL lag·archive lag·연결 수를 한 번에 봅니다.

15. 한국 / 일본 — 토스, 카카오, NAVER, 메르카리, NTT

한국 — 토스: 토스는 2020년 전후로 코어 거래 시스템 일부를 Oracle에서 Postgres로 이전하기 시작했고, 2024년 토스페이먼츠 기술 블로그에서 "10TB Postgres + Citus 기반 멀티테넌트 SaaS"의 운영 사례를 공개했습니다. 단일 거래 DB는 Postgres 16이며, pgBackRest + Patroni + PgBouncer + pg_partman + pg_cron 조합으로 운영합니다. pgvector는 부가 서비스(추천·검색)에서 활용 중입니다.

한국 — 카카오: 카카오는 2022년 SCC 화재 사고 이후 데이터베이스 다중화 전략을 전면 재설계했고, 코어 메시징·페이의 일부 워크로드를 Postgres + Citus로 옮겼습니다. 2025년 if(kakao) 컨퍼런스에서 "Kakao DB Platform"이 공개되었으며, Postgres 17·CloudNativePG·pgvector를 묶은 사내 PaaS가 운영됩니다.

한국 — NAVER: NAVER 클로바·검색·쇼핑 인프라에서 Postgres + pgvector + pgvectorscale 조합이 RAG·추천·검색에 적극적으로 활용되고 있습니다. 2024~2025년 NAVER D2 블로그에 "사내 LLM 플랫폼이 Postgres 기반"이라는 글이 다수 공개되었습니다.

일본 — 메르카리(Mercari): 메르카리는 마이크로서비스 별로 다른 DB를 쓰지만, 결제·계정·재고의 상당 부분이 Postgres + Cloud SQL입니다. 2024년 Mercari Engineering Blog에서 pgvector 기반 상품 추천을 공개했고, 2025년에는 pgvectorscale로 마이그레이션한 사례도 발표되었습니다.

일본 — NTT (Fujii Masao, Amit Langote): PostgreSQL Global Development Group의 핵심 committer 중 두 명이 NTT 그룹 출신입니다. Fujii Masao(NTT OSSセンタ)는 streaming replication·pg_basebackup·pg_rewind의 주요 저자이며, Amit Langote(EDB, 전 NTT)는 declarative partitioning과 JSON_TABLE의 핵심 기여자입니다. 일본은 NTT·SRA OSS·Fujitsu가 PostgreSQL 코어 개발에 가장 많은 인력을 투입하는 국가이며, 이는 2007년 NTT가 "PostgreSQL을 일본의 기간 DB로"라는 전략을 세운 데서 시작합니다.

한국 — PgKR / PostgreSQL Korea User Group: 한국 PostgreSQL 사용자 모임(PgKR)은 매년 PgDay 컨퍼런스를 열며, 2025년에는 Coupang·LINE+·Hyundai AutoEver의 Postgres 사례가 발표되었습니다. 2026년 행사는 9월 예정입니다.

16. 누가 Postgres를 골라야 하나 — 거의 모든 경우 ✓

2026년 5월 기준의 권고는 매우 단순합니다.

Postgres가 "안 맞는 경우"도 있습니다 — (1) 초저지연 KV(Redis/DragonflyDB), (2) 글로벌 strong consistency(Spanner), (3) 컬럼나 PB 분석(ClickHouse·Snowflake), (4) 그래프 traversal 깊이 10+(Neo4j), (5) 풀텍스트 검색의 ranking 미세 튜닝이 필요한 경우(Elasticsearch). 이 다섯을 제외하면 거의 모든 상황에서 Postgres가 첫 선택지가 되어도 큰 후회가 없습니다.

마지막 조언 — "Postgres 익스텐션은 강력하지만, 호스팅 환경의 허용 목록(AWS RDS·Cloud SQL·Azure)을 먼저 확인하세요." 익스텐션 자유도가 가장 높은 곳은 Tembo·Crunchy Bridge·Supabase·Neon·자체 운영(K8s + CloudNativePG)이고, RDS는 50개 정도만 지원합니다. 익스텐션 의존이 큰 워크로드라면 호스팅 선택이 곧 익스텐션 선택입니다.

17. 참고 / References

• PostgreSQL 17 release notes — https://www.postgresql.org/docs/17/release-17.html
• PostgreSQL 18 release notes — https://www.postgresql.org/docs/18/release-18.html
• PostgreSQL versioning policy — https://www.postgresql.org/support/versioning/
• pgvector GitHub — https://github.com/pgvector/pgvector
• pgvectorscale GitHub — https://github.com/timescale/pgvectorscale
• pgvectorscale launch blog — https://www.timescale.com/blog/pgvector-is-now-as-fast-as-pinecone-at-75-less-cost/
• pgvector.rs / VectorChord — https://github.com/tensorchord/VectorChord
• pgai (Timescale) — https://github.com/timescale/pgai
• TimescaleDB docs — https://docs.timescale.com/
• PostGIS docs — https://postgis.net/docs/
• pgRouting — https://pgrouting.org/
• H3-pg — https://github.com/zachasme/h3-pg
• PgBouncer — https://www.pgbouncer.org/
• Pgpool-II — https://www.pgpool.net/
• pgcat — https://github.com/postgresml/pgcat
• Supavisor — https://github.com/supabase/supavisor
• Citus Data — https://github.com/citusdata/citus
• Hydra Postgres — https://github.com/hydradatabase/hydra
• pg_mooncake — https://github.com/Mooncake-Labs/pg_mooncake
• Tembo — https://tembo.io/
• Trunk extension registry — https://pgt.dev/
• Crunchy Data — https://www.crunchydata.com/
• CloudNativePG — https://cloudnative-pg.io/
• Crunchy Postgres for Kubernetes (PGO) — https://github.com/CrunchyData/postgres-operator
• pg_stat_statements — https://www.postgresql.org/docs/current/pgstatstatements.html
• pg_partman — https://github.com/pgpartman/pg_partman
• pg_cron — https://github.com/citusdata/pg_cron
• pg_repack — https://github.com/reorg/pg_repack
• pglogical — https://github.com/2ndQuadrant/pglogical
• pgmustard — https://www.pgmustard.com/
• Postgres.ai — https://postgres.ai/
• pgBackRest — https://pgbackrest.org/
• Barman — https://pgbarman.org/
• WAL-G — https://github.com/wal-g/wal-g
• pgexporter — https://pgexporter.github.io/
• Apache AGE (graph) — https://age.apache.org/
• pgmq (Tembo) — https://github.com/tembo-io/pgmq
• DB-Engines Ranking — https://db-engines.com/en/ranking
• Stack Overflow Developer Survey 2024 — https://survey.stackoverflow.co/2024/technology
• Andrew Kane PGConf NYC 2024 talk — https://www.youtube.com/@PostgresConf
• Mercari Engineering Blog — https://engineering.mercari.com/en/blog/
• 토스 기술 블로그 — https://toss.tech/
• 카카오 if(kakao) — https://if.kakao.com/
• NAVER D2 — https://d2.naver.com/
• PgKR / PostgreSQL Korea — https://postgresql.kr/
• Fujii Masao (NTT) — https://www.postgresql.org/community/contributors/
• Amit Langote (EDB, 전 NTT) — https://www.postgresql.org/community/contributors/