When PostgreSQL Is the Wrong Tool

The honest list

PostgreSQL is the right answer for almost every persistent-data problem. It is not the right answer for everything. Knowing where it stops winning is part of using it well.

Where you outgrow PostgreSQL

Petabyte-scale analytics — column stores (BigQuery, Snowflake, ClickHouse) are an order of magnitude cheaper for this shape.
Sub-millisecond cache — Redis is purpose-built for it; Postgres can serve some of these workloads with UNLOGGED tables but won't beat Redis on raw speed.
Multi-region active-active — Postgres has logical replication and tooling, but databases like CockroachDB and Spanner are designed for it from the ground up.
Time-series at the high end — TimescaleDB extension takes Postgres a long way, but a billion datapoints/sec belongs in InfluxDB or VictoriaMetrics.
Truly massive write fan-out — Cassandra, ScyllaDB, and similar wide-column stores eat throughput Postgres struggles with.
Pure event log — Kafka is a different kind of system; SQL doesn't model "append-only stream of bytes for many consumers" well.

The decision rule

Default to Postgres. Add a specialist database only when you have measured the limits — not when you suspect them. The cost of running multiple databases (operations, integration, on-call) is usually larger than the marginal performance gain.

Code

UNLOGGED tables — Postgres as a fast-but-volatile cache·sql

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

-- Faster than logged tables (no WAL).
-- Survives normal operation, but is TRUNCATED on crash recovery.
-- A lightweight Redis substitute when you don't need cross-node sharing.

Postgres as a queue — when SKIP LOCKED is enough·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;
-- ... process ...
UPDATE jobs SET status = 'done' WHERE id = ?;
COMMIT;

When PostgreSQL Is the Wrong Tool

The honest list

Where you outgrow PostgreSQL

The decision rule

Code

External links

Exercise

Progress

Comments 0