"Just use Postgres for everything" is good advice with a scale limit nobody puts in the headline

There's a genre of engineering blog post that resurfaces every year or two: "You don't need Kafka. You don't need Redis. You don't need Elasticsearch. Just use Postgres." Raphael Bauer's piece is a recent, well-argued entry in that tradition and it's not wrong, exactly. It's just less universal than the headline wants it to be.

The case, stated fairly

The argument is genuinely strong on its own terms. PostgreSQL, with the right extensions, can function as a message queue (via SKIP LOCKED), a cache (via UNLOGGED tables), a full-text search engine (via tsvector), a time-series store (via TimescaleDB), and more all from one connection string, one backup strategy, one system to understand at 3am when something breaks. For a team running five specialized systems where each one is lightly used, that's a real, defensible simplification. One well-understood system beats five half-understood ones. Fewer moving parts genuinely does mean fewer ways for things to quietly break. That part of the argument holds up.

Where the doubts start

The trouble is what happens when "cache," "queue," "search index," and "analytics" all start competing for the same connection pool, the same disk I/O, and the same CPU as your actual transactional workload - the orders, the payments, the core business data the whole system exists to protect.

• A cache built on disk-backed tables isn't the same thing as a cache. Redis lives in memory and answers in sub-millisecond time by design. Postgres, even with UNLOGGED tables, is still writing to disk and competing with your primary workload for buffer cache. Under real load, "cache traffic" and "checkout traffic" start fighting each other for the same resources — the opposite of what a cache is supposed to buy you.

• A queue built on SKIP LOCKED isn't a substitute for Kafka once you need Kafka's actual features. It works fine for straightforward job queues. It does not give you Kafka's log retention, replay, partitioned consumer groups, or the ability to have ten different systems independently read the same event stream at their own pace. If you don't need those things, you never needed Kafka. If you do, Postgres doesn't quietly grow them for you.

• Search and analytics are the same story. tsvector handles "search my product catalog" well. It does not do faceted search, relevance tuning, or fuzzy matching at the level Elasticsearch or Typesense were built for. And row-store Postgres, extensions aside, is not a columnar engine — throw a genuinely large analytical aggregation at it and it will show you exactly why ClickHouse exists.

• One system to debug at 3am is only simpler if it's the transactional database going down, not the queue-that's-secretly-also-your-database taking your checkout flow with it. Mixing workloads on one Postgres instance means a runaway analytics query or a backed-up job queue can degrade the same database your core product depends on. Splitting workloads isn't only about avoiding complexity — it's also about isolating blast radius. That trade-off disappears from most "just use Postgres" arguments entirely.

• This isn't actually less expertise required — it's expertise moved, not removed. Running Postgres as five systems in one demands real depth: autovacuum tuning, connection pooling, extension management, understanding exactly how each workload behaves under contention. That's a legitimate skill set, but it's not the free lunch the "one thing to learn" framing implies. And on managed platforms like RDS, some of the extensions these arguments lean on aren't available at all, or need superuser access you don't have.

The honest version of the advice

"Default to Postgres, and earn your way into a specialized system" is good, defensible engineering advice — probably the right default for most teams below a certain scale, especially when a workload is genuinely light. "Postgres replaces Kafka, Redis, and Elasticsearch, full stop" is a much bigger claim, and the popular version of this argument tends to blur the line between the two. The honest question isn't "can Postgres technically do this" — with enough extensions, it usually can. It's "at the load and isolation guarantees my system actually needs, does doing it in Postgres cost me less than running a separate tool would."

For a lot of early-stage systems, the answer really is yes. For systems with meaningfully different workloads sharing a lot of load, the answer flips — and the flip tends to arrive quietly, as degraded p99 latency on your main database rather than a clean failure that tells you it's time to split things out.