I’ve got the 2am scars from a pg_cron job gone rogue and an autovacuum that decided 3am was a great time to lock a queue table for 90 seconds. That’s the perspective I’m writing from today — not a vendor pitch, but the actual operational calculus of collapsing four separate systems into one Postgres instance.
Here’s the short version: Postgres can replace Redis, Mongo, and RabbitMQ for a surprising chunk of real workloads — but only if you operate below specific thresholds. If you’re pushing fewer than 10,000 requests per second with a dataset under 1TB, your team is around five people, and the data you’re caching or queuing is directly related to relational rows already in your database, then yes, consolidating into Postgres will simplify your ops radically. Once you cross those thresholds, you’re not consolidating complexity — you’re compressing it into a single point of failure that’s harder to debug than the four systems you just retired.
The Real Cost of Four Systems (It’s Not Just “More Dashboards”)
You know the argument. “Why run Redis for caching, RabbitMQ for queues, Mongo for blobs, and Postgres for relational data when one database could do it all?” The sales pitch stops at “fewer moving parts.” The operational reality starts with three a.m. pages.
Credential rotation alone becomes a recurring project. Each of those four systems has its own auth mechanism, its own secret management lifecycle, and its own SDK configs scattered across your services. Rotating a RabbitMQ password isn’t just updating a k8s secret — it’s coordinating the restart of every queue consumer that holds a long-lived AMQP connection, or you discover that the Python pika library has a connection-recovery bug with your version of Erlang and now half your workers are dead. Multiply that by four systems, four sets of credentials, four compliance checklists.
Disaster recovery consistency is the one that actually wakes me up. Say you have a checkout flow that charges a card in Postgres and enqueues a receipt email in RabbitMQ. Those are two independent durable-storage systems with two independent crash-recovery modes. If your Postgres restore is point-in-time to 14:04:17 UTC but your RabbitMQ messages relied on durable queues with a different snapshot cadence, you now have a distributed transaction problem that you didn’t even recognize as distributed. You charged the card but the receipt never went out. Or worse: you restored RabbitMQ to an earlier point and the receipt got sent twice. This is the two-phase-commit-shaped hole nobody talks about during architecture meetings.
On-call surface area is the metric I actually care about. Every additional system is a new category of pages. RabbitMQ node-partition alarms. Redis maxmemory eviction storms. Mongo replication-lag alerts. Postgres autovacuum wraparound warnings (don’t get me started). If your team is five people, one person on call is expected to triage four different databases they barely know. Consolidation helps here — until the single Postgres instance becomes a four-headed monster and the one person on call is debugging queue bloat while OLTP queries pile up behind it. That’s the trade-off, and we’ll get to it.
The Decision Framework: Four Questions (Plus a Dataset Limit) Before You Consolidate
Copy this into your design doc. If you answer “yes” to all five, consolidation is worth testing. If you trip on any one, you’re going to
Top comments (0)