PostgreSQL 이 모든 걸 충분히 잘 해서 이김

아키텍처 축소 패턴

대부분 팀이 specialist DB 잡는 건 PostgreSQL 이 일반 목적 으로 보여서 어느 한 일에 best-in-class 아니라 생각해서. 현실: PostgreSQL 이 대부분 일에 best-in-class — 그리고 4 specialist 시스템 운영하는 통합 비용 이 보통 어느 한 시스템의 marginal 성능 이득 압도.

PostgreSQL 이 "충분히 좋은" 곳

Document store: JSONB + GIN 이 거의 모든 use case 에서 MongoDB 대체.
Full-text search: tsvector + GIN 이 십억 document 미만 대부분 use case 에서 Elasticsearch 대체.
Vector 검색: pgvector + HNSW 가 ~10M vector 미만 dedicated vector DB 대체.
Geospatial: PostGIS 가 진짜 best-in-class — 타협 없음.
Time-series: TimescaleDB extension 이 Postgres 를 강한 시계열 DB 로.
Cache 레이어: UNLOGGED 테이블 + LISTEN/NOTIFY 가 많은 use case 에서 Redis 대체.
Message queue: SKIP LOCKED job 큐가 많은 use case 에서 lightweight Celery/SQS 대체.

솔직한 예외

진짜 specialist 도구가 스케일 포인트 넘어가면 이김: 페타바이트 분석 웨어하우스 (BigQuery, Snowflake), sub-ms 캐시 (Redis), 초당 수백만 write (Cassandra), real-time 스트림 (Kafka). 다른 모두: Postgres 로 시작, 측정된 고통이 강제하면 specialist 추가.

Code

Postgres 한 대가 4 서비스 대체·sql

-- 1. Document store (MongoDB 였음)
CREATE TABLE events (id BIGINT PRIMARY KEY, data JSONB);
CREATE INDEX events_data_gin ON events USING gin (data);

-- 2. Full-text search (Elasticsearch 였음)
ALTER TABLE articles ADD COLUMN tsv tsvector
GENERATED ALWAYS AS (to_tsvector('english', body)) STORED;
CREATE INDEX articles_tsv_gin ON articles USING gin (tsv);

-- 3. Vector 검색 (Pinecone 였음)
CREATE EXTENSION vector;
ALTER TABLE documents ADD COLUMN embedding vector(1536);
CREATE INDEX documents_embedding_hnsw
ON documents USING hnsw (embedding vector_cosine_ops);

-- 4. Job 큐 (Celery + Redis 였음)
CREATE TABLE jobs (
    id INTEGER GENERATED ALWAYS AS IDENTITY PRIMARY KEY,
    payload JSONB NOT NULL,
    status TEXT NOT NULL DEFAULT 'pending',
    created_at TIMESTAMPTZ NOT NULL DEFAULT now()
);
-- Worker 가 가져옴: SELECT ... FOR UPDATE SKIP LOCKED LIMIT 1

PostgreSQL 이 모든 걸 충분히 잘 해서 이김

아키텍처 축소 패턴

PostgreSQL 이 "충분히 좋은" 곳

솔직한 예외

Code

External links

Exercise

Progress

댓글 0