Just Use Postgres: One Database for Almost Everything

For most applications, PostgreSQL can replace Redis, RabbitMQ, Elasticsearch, MongoDB, and Pinecone — not because it beats each of them at their specialty, but because it is good enough at all of them and you only have to operate one system. The availability math alone is persuasive: three datastores each promising 99.9% uptime compound to roughly 99.7%, which is about 26 hours of expected downtime a year instead of 8.7. Cloudflare runs the control-plane metadata for a network serving 55 million HTTP requests per second on 15 Postgres clusters. Tiger Data counts 48,000+ companies running Postgres in production. The pattern even has its own site, postgresisenough.dev, cataloging 70+ extensions that turn one database into a queue, a cache, a search engine, and a vector store. The argument of this guide is simple: start with Postgres, and add a specialized system only after you have measured Postgres failing at the job.

Why should Postgres be your default database?

Because your capacity for operating unfamiliar infrastructure is small and your product does not care how novel your stack is. Dan McKinley's 2015 essay Choose Boring Technology put a number on it: a company gets about three "innovation tokens" to spend on new technology. Each specialized datastore you adopt spends one — on its failure modes, its operational quirks, its security patching, its hiring pool. Postgres, in continuous development since 1996 and descended from Michael Stonebraker's POSTGRES project at Berkeley (1986), costs zero tokens. Every developer, ORM, BI tool, and managed hosting provider already speaks it.

Scale is rarely the real constraint. Cloudflare's control plane — the metadata behind a network serving 55 million HTTP requests per second, about 20% of internet traffic — runs on 15 Postgres clusters on bare metal, fronted by PgBouncer. Instagram famously scaled Postgres to hundreds of millions of users before most teams would have finished evaluating alternatives. The gap between "our startup's write volume" and "workloads Postgres has already survived" is usually several orders of magnitude.

What can Postgres actually replace?

Each row below is a workload teams habitually buy a separate system for, next to the Postgres feature or extension that covers it. The extensions are production software, not weekend projects — PostGIS has been in production since 2001, TimescaleDB and pgvector are offered by every major managed-Postgres provider.

If the left column reads like your architecture diagram, the practical question is not "which best-of-breed tool do I pick per box" but "which boxes genuinely cannot be Postgres yet". For the relational-vs-document decision specifically, the PostgreSQL vs MongoDB guide walks through why JSONB removed MongoDB's main selling point.

How does one database cut operational cost?

The cost of a second datastore is not the instance bill — it is everything around it. Two backup strategies and two restore drills. Two monitoring and alerting setups. Two security patch cadences. Two sets of credentials to rotate, and data-synchronization code between the systems that is itself a source of bugs. Stephan Schmidt, a 25-year engineering leader who has coached over a hundred CTOs, calls consolidation onto Postgres "technical credit" — the opposite of technical debt.

The compounding-SLA arithmetic is the sharpest version of the argument. Systems fail independently, so their availability multiplies: 99.9% × 99.9% × 99.9% ≈ 99.7%. That is the difference between 8.7 and roughly 26 hours of expected downtime a year — before counting the outages caused by the glue code that keeps cache, queue, and database consistent with each other.

Tiger Data's 2026 consolidation case studies put numbers on it: Plexigrid collapsed four databases into one Postgres instance and reports 350× faster queries because the data no longer crosses system boundaries; Flogistix cut database costs by 66%; Latitude saved $12,000 a month from columnar compression alone. The vendor has an obvious interest, but the mechanism is general — every join that used to be an HTTP round-trip between two datastores becomes an index scan.

How do you cache in Postgres instead of Redis?

With an UNLOGGED table. The PostgreSQL docs state the trade precisely: data written to unlogged tables skips the write-ahead log, "which makes them considerably faster than ordinary tables", at the cost that an unlogged table "is automatically truncated after a crash" and is not replicated to standbys. Losing your cache on a crash is exactly the durability contract you already accepted by putting the data in Redis.

CREATE UNLOGGED TABLE cache (
  key        text PRIMARY KEY,
  value      jsonb NOT NULL,
  expires_at timestamptz NOT NULL
);

-- set (upsert)
INSERT INTO cache VALUES ('user:42:profile', '{"name":"Ada"}', now() + interval '5 minutes')
ON CONFLICT (key) DO UPDATE SET value = EXCLUDED.value, expires_at = EXCLUDED.expires_at;

-- get, ignoring expired entries
SELECT value FROM cache WHERE key = 'user:42:profile' AND expires_at > now();

-- purge expired rows on a schedule (pg_cron)
SELECT cron.schedule('purge-cache', '*/5 * * * *',
  $$DELETE FROM cache WHERE expires_at < now()$$);

Martin Heinz's write-up of this pattern adds LRU eviction with a last_read column. Be honest about the ceiling: Redis serves hot keys from memory in microseconds, while a Postgres round-trip costs on the order of a millisecond. If a profiler shows cache latency dominating your p99, that is the measured limit this guide keeps asking for — add Redis then, and see the Redis vs Memcached comparison for that decision. Most applications never get there; they cache to avoid recomputing queries, and a materialized view or an UNLOGGED table does that without a second system.

Can Postgres store documents like MongoDB?

Yes — JSONB has been in Postgres since 9.4 (2014) and is a binary, indexable document type, not a text blob. A single GIN index makes arbitrary containment queries fast, and the documents live next to your relational data, inside the same transactions:

CREATE TABLE events (
  id      bigint GENERATED ALWAYS AS IDENTITY PRIMARY KEY,
  user_id bigint REFERENCES users(id),
  payload jsonb NOT NULL
);

CREATE INDEX ON events USING gin (payload jsonb_path_ops);

-- find events whose payload contains this shape
SELECT * FROM events WHERE payload @> '{"type": "checkout", "status": "failed"}';

Schema flexibility where you want it, foreign keys and ACID where you need them — that combination is why the PostgreSQL vs MongoDB comparison concludes Postgres wins for roughly 95% of projects. If an application truly needs the MongoDB wire protocol, FerretDB speaks it on top of Postgres.

What about queues, search, and vectors?

Each deserves (and this series will give it) a full guide, but the short versions:

• Queues — FOR UPDATE SKIP LOCKED (Postgres 9.5, 2016) lets many workers pull jobs from a table without lock contention, and the job enqueue commits atomically with the business change that caused it — something a separate broker cannot offer. pgmq packages the pattern as an SQS-like extension.
• Full-text search — built-in tsvector with a GIN index handles the "search our products/docs" use case most teams buy Elasticsearch for; ParadeDB adds BM25 relevance ranking when the built-in ranking stops being good enough.
• Vectors — pgvector stores embeddings next to the rows they describe, so a RAG query is one SQL statement instead of a two-system fan-out plus a sync pipeline. Timescale's pgvectorscale benchmark reports 28× lower p95 latency than Pinecone at 99% recall on 50 million vectors — vendor numbers, but a strong hint that "Postgres can't do vectors" is outdated.

When is Postgres NOT enough?

The claim is "enough for almost everything", not "best at everything". Genuine exits from Postgres, with the symptom that justifies them:

• Log analytics and petabyte-scale search — ingesting terabytes a day of append-only logs with complex aggregations is what Elasticsearch and ClickHouse are built for.
• Event streaming as an integration backbone — dozens of services consuming replayable, ordered streams is Kafka's home turf. LISTEN/NOTIFY and logical replication cover one app's needs, not an enterprise event bus.
• Multi-region active-active writes — Postgres replication is single-writer at heart; if every region must accept writes with conflict resolution, look at purpose-built systems.
• Sub-millisecond cache p99 at extreme QPS — an in-memory store still wins the last order of magnitude.

Note the shape of every item: a measured, workload-specific symptom. "We might need it at scale" is not on the list — postgresisenough.dev's maintainers put it well: the bar for specialized infrastructure should be reached only after pushing Postgres to its limits. Keep the PostgreSQL cheat sheet handy while you do.

Frequently Asked Questions

References

• Postgres Is Enough — directory of 70+ extensions and tools organized by the system they replace
• Dan McKinley — Choose Boring Technology — the innovation-tokens argument (2015)
• Stephan Schmidt — Just Use Postgres for Everything — the consolidation case, SLA math, and "technical credit"
• Ethan McCue — Just Use Postgres — a systematic walk through the alternatives and why each is the wrong default
• Tiger Data — It's 2026, Just Use Postgres — consolidation case studies (Plexigrid, Flogistix, Latitude) and adoption numbers
• System Design Newsletter — Cloudflare on 15 Postgres clusters — how the control plane behind 55M requests/second is structured
• PostgreSQL docs — CREATE TABLE (UNLOGGED) — the exact durability trade-off of unlogged tables
• Martin Heinz — You Don't Need a Dedicated Cache Service — UNLOGGED-table caching with TTL and LRU eviction