PostgreSQL for Everything: Escaping the Expensive Managed Database Trap

The short answer

"PostgreSQL for everything" means running your cache, job queue, full-text search, document store, and vector search on a single Postgres instance instead of renting five separate managed databases. Companies do it to cut SaaS and cloud database bills, reduce the number of systems that can fail, and stop paying markup on commodity infrastructure. Postgres extensions like pgvector, pg_search, and pgmq now cover most of the ground that used to require Redis, Elasticsearch, MongoDB, and Kafka.¹

Why the stack got fragmented in the first place

A typical startup stack grows one decision at a time. You need a cache, so you add Redis. You need full-text search, so you add Elasticsearch. You need a job queue, so you add Kafka or RabbitMQ. You need flexible documents, so you add MongoDB. Each choice is defensible in isolation. Together they create what one Postgres consultant calls "dotted line complexity": every pair of systems that shares data adds its own failure mode, monitoring surface, and backup strategy.

The math on reliability alone is bad. If you run three separate systems each rated at 99.9% uptime, your combined SLA is roughly 99.7%, not 99.9%. More systems does not mean more resilience. It means more places for things to break.²

What actually gets replaced

The "Postgres for everything" pattern, popularized by CTO coach Stephan Schmidt and picked up widely across engineering blogs, maps specialized tools onto native Postgres features and extensions:²

• Cache (replacing Redis): UNLOGGED tables or JSONB columns with expiry logic, often faster to reason about than a second in-memory system.
• Job queue (replacing Kafka/RabbitMQ): SELECT ... FOR UPDATE SKIP LOCKED gives you a working queue with no extra broker.
• Full-text search (replacing Elasticsearch): built-in text search, extended with pg_search for BM25-style ranking.
• Document store (replacing MongoDB): JSONB columns with GIN indexes.
• Vector search (replacing Pinecone/dedicated vector DBs): the pgvector extension.
• Distributed locks, rate limiting, session storage, cron jobs: advisory locks, atomic updates, and pg_cron.

The underlying claim is not that Postgres is faster at any one of these jobs. It usually is not. The claim is that Postgres is fast enough, and the productivity and operational savings from running one system outweigh the performance gap for the vast majority of applications, an argument made explicitly using Instagram's own history of scaling on plain Postgres.²

Where the actual dollars go

This is a cost story as much as an architecture story. Two separate cost structures are stacked on top of each other in a fragmented database stack, and both are worth breaking down.

First, the managed-database markup. A detailed teardown of cloud RDS pricing found that Alibaba Cloud's managed Postgres carries a 7x to 11x markup over raw compute, AWS RDS runs 14x to 22x, and cloud block storage can run 6x to 24x the cost of self-purchased storage at the same spec, depending on commitment term.³ The same analysis found a self-hosted 8-core instance costing roughly ¥432/month in raw compute versus ¥1,582/month for the equivalent AWS RDS HA instance, and 1TB of self-purchased storage at ¥16/month versus roughly ¥1,900 to ¥3,200/month on AWS or Alibaba Cloud.³ None of that markup is unique to Postgres. It's the standard tax on any managed relational database, and it compounds every time you add another managed service (a managed Redis, a managed Elasticsearch cluster, a managed vector DB) on top of it.

Second, the sprawl tax. Each additional managed database is not just an added line item, it's an added team's worth of learning curve, monitoring dashboard, backup policy, and on-call runbook. A managed Redis Cloud cache alone can run in the hundreds of euros per month even at modest scale, according to one practitioner comparison of MongoDB Atlas and Redis pricing.⁴ A managed vector search product or Elasticsearch cluster adds another recurring bill on top of that. Collapse five specialized services into one Postgres instance and you are not just avoiding five markups, you are avoiding five separate monitoring stacks, five sets of credentials, and five vendors whose renewal cycles rarely line up with your budget calendar.

Rough monthly cost comparison, small-to-mid scale workload

Figures are directional, based on published entry and mid-tier pricing for each category rather than a single vendor quote; actual bills vary heavily by data volume and traffic.⁴³

The counterargument, and where it holds

This is not a call to never use a specialized database. Postgres advocates themselves are careful to frame it as anti-overengineering, not anti-tooling: don't reach for Kafka on day one when you have 200 users, because the operational cost of a second system arrives immediately while the performance need may never arrive at all.⁵ The honest failure mode is the opposite one: bolting caching, queueing, and search onto a single primary Postgres instance without capacity planning, so they all compete for the same connection pool, memory, and I/O, and everything gets slower together during a traffic spike.⁶

The practical rule that shows up across the practitioner writing on this topic: start on Postgres for everything, and only peel off a dedicated system once you have a measured, specific bottleneck, not a hypothetical one.¹⁵ Consolidation isn't the end state forever. It's the default you should have to argue your way out of.

Why this matters beyond engineering

The broader pattern here is not really about Postgres. It is about companies re-examining what they are actually paying for when they rent infrastructure by the seat or by the service. The same math that makes five managed databases expensive shows up across the SaaS stack: every specialized tool is a recurring bill, a renewal date, and a vendor relationship, even when a general-purpose tool you already run could do the job. For teams thinking hard about which of their rented systems are worth owning outright, platforms like Remy apply the same logic to internal software generally, treating what you build and run yourself as an asset rather than a subscription.

FAQ

What is "PostgreSQL for everything"? An architecture pattern where a single Postgres instance, extended with native features and extensions, replaces separate systems for caching, queueing, search, and vector storage instead of running each as its own managed service.

Does Postgres actually perform as well as Redis or Elasticsearch? Not on raw benchmarks in most cases. The argument is that Postgres performance is sufficient for the majority of workloads, especially early-stage and mid-scale ones, and the operational savings from one system outweigh a performance gap most applications never hit.²

How much cheaper is self-managed or consolidated Postgres than a fragmented managed stack? Managed cloud database instances alone commonly carry markups of 7x to over 20x on raw compute, on top of whichever additional managed services (cache, search, queue) get added around them.³

When should a team NOT consolidate onto Postgres? When a specific, measured bottleneck shows up, such as extreme write throughput on a queue or search relevance requirements Postgres extensions can't match, and the cost of adding one more specialized system is clearly justified by that measured need rather than by habit.⁵⁶

Is this only a startup pattern? No. Instagram's early scaling story and OpenAI's Postgres scaling work are both cited as evidence that the pattern holds well beyond a handful of users, though very large organizations still add specialized systems selectively once they hit genuine limits.²