I Replaced 8 Services With Postgres. Here's Where It Actually Breaks.
Over the last few months I've written about replacing Redis, Elasticsearch, Pinecone, MongoDB, InfluxDB, Snowflake, a GIS stack, and a hand-built API layer — all with a single Postgres instance. Every one of those posts was true, tested, and worth doing for most teams.
None of that means Postgres has no limits. It means most applications never actually reach them. Here's exactly where the line sits, because “it depends” isn't a real answer and I'd rather just tell you.
Where this genuinely stops working
Horizontal sharding is still hard
Postgres scales vertically with real grace, but splitting one logical database across many physical nodes adds genuine operational complexity. Tools like Citus help — they don't make it free.
Extreme ingest rates
If you're ingesting millions of events per second, a single Postgres primary becomes your bottleneck before your application code does.
Sub-millisecond, massive-fanout caching
Thousands of concurrent WebSocket connections, or read-after-write caching at extreme QPS, still wants a pure in-memory store. This is the one place on the list where the tool I told you to delete is genuinely the right one.
Connection limits
Postgres handles a few thousand direct connections comfortably. Past that you need a pooler — PgBouncer or Supavisor — which is normal operations at scale, not a flaw to work around.
Vacuum and bloat
Heavy update/delete workloads need autovacuum tuned deliberately, or table bloat creeps in over time. This is routine Postgres maintenance, not optional homework.
One database, one blast radius
Consolidating everything onto one instance means a single maintenance window or outage touches everything it powers. Plan replicas and backups accordingly — this is the actual cost of the simplicity, not a hidden one.
The honest takeaway
None of this means don't do it. It means know exactly where the line is, and cross it on purpose — not by accident, three months after your traffic graph quietly tripled.
If you've read the previous eight posts in this series and are wondering “so when do I actually need to reach for something else” — this is that answer, in full, with nothing softened for the sake of a tidier narrative.
The series is complete · Every recipe tested
Eight swaps, one manual, and the limits written down.
Just Use Postgres collects all nine pieces — including the honest limits above, plus a 5-phase rollout plan for migrating without a 2am incident — with runnable SQL for every recipe.
Know where the line is. Cross it on purpose.
The full series
Nine parts, from SKIP LOCKED to the honest limits. Start at the beginning.
See the full series →