PostgreSQL 이 잘못된 도구일 때

솔직한 리스트

PostgreSQL 이 거의 모든 영속 데이터 문제의 정답. 모든 거에 정답은 아님. 어디서 이기기 멈추는지 아는 게 잘 쓰는 일부.

PostgreSQL 졸업하는 곳

페타바이트 스케일 분석 — column store (BigQuery, Snowflake, ClickHouse) 가 이 모양에 한 자릿수 쌈.
Sub-ms 캐시 — Redis 가 이거 위해 만들어짐; Postgres 가 UNLOGGED 테이블로 일부 워크로드 처리 가능하나 raw 속도엔 Redis 못 이김.
다중 region active-active — Postgres 에 logical replication 과 도구 있지만, CockroachDB 와 Spanner 같은 DB 가 이거 위해 처음부터 설계됨.
고급 시계열 — TimescaleDB extension 이 Postgres 멀리 가지만, 초당 십억 datapoint 는 InfluxDB 또는 VictoriaMetrics 영역.
진짜 거대한 write fan-out — Cassandra, ScyllaDB 같은 wide-column store 가 Postgres 어려워하는 처리량 먹음.
순수 event log — Kafka 는 다른 종류 시스템; SQL 이 '많은 소비자 위한 byte append-only stream' 잘 모델 안 함.

결정 룰

Default Postgres. 한계 측정 했을 때만 specialist DB 추가 — 의심할 때 아님. 여러 DB 운영 비용 (운영, 통합, on-call) 이 보통 marginal 성능 이득보다 큼.

Code

UNLOGGED 테이블 — Postgres 를 빠르지만 휘발성 캐시로·sql

CREATE UNLOGGED TABLE session_cache (
    key    TEXT PRIMARY KEY,
    value  JSONB NOT NULL,
    expires_at TIMESTAMPTZ NOT NULL
);

-- Logged 테이블보다 빠름 (WAL 없음).
-- 정상 운영엔 살아남지만 크래시 복구 시 TRUNCATE.
-- Cross-node 공유 불필요할 때 lightweight Redis 대체.

큐로서 Postgres — SKIP LOCKED 충분할 때·sql

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
BEGIN;
SELECT id, payload FROM jobs
WHERE status = 'pending'
ORDER BY created_at
LIMIT 1
FOR UPDATE SKIP LOCKED;
-- ... 처리 ...
UPDATE jobs SET status = 'done' WHERE id = ?;
COMMIT;

PostgreSQL 이 잘못된 도구일 때

솔직한 리스트

PostgreSQL 졸업하는 곳

결정 룰

Code

External links

Exercise

Progress

댓글 0