Just Use Postgres

Definition

“Just Use Postgres (for everything)” is a pragmatic engineering stance: before adopting a purpose-built system (Kafka, Redis, Elasticsearch, MongoDB, a vector DB), check whether PostgreSQL already solves the problem well enough. It’s a reaction against resume-driven design — adopting the Hot New Stack for novelty rather than need.

---

Core Ideas

Two camps

• Buzzword camp — chases “real-time, infinitely scalable, cloud-native, serverless, AI-powered” without asking if it fits. System-design interviews and career incentives reward replatforming to trendy tech.
• Common-sense camp — strips unnecessary complexity, reasons from first principles, treats vendor claims skeptically.

Why the pendulum is swinging

• Small Data movement — most datasets aren’t actually big, and single machines are huge (rent a 128-core / 4 TB instance). Vertical scale goes a long way.
• Postgres Renaissance — one engine now covers many needs:
  • Elasticsearch → tsvector / tsquery full-text search
  • MongoDB → jsonb
  • Redis → UNLOGGED TABLE (and LISTEN/NOTIFY for pub/sub)
  • Vector DBs → pgvector / pgai
  • Kafka → a table used as a queue or pub/sub log

The trade-off

Fewer moving parts means less operational surface, simpler transactions, and one system to reason about. The counter-case (“it won’t scale”) is often premature — Postgres scales far past most companies’ real needs, and you can always extract a specialized component later, once the load genuinely demands it.

---

Contradictions

The “Vector DBs → pgvector / pgai” substitution above is the weakest item on the list, and Alex Jacobs argues it is wrong in production. Both sides, with attribution:

Claim	Source
Postgres covers vector search well enough via pgvector, so skip the dedicated store	Kafka is fast — I’ll use Postgres / Redis is fast — I’ll cache in Postgres
pgvector works in a demo and breaks in production: memory-hungry index builds, no clean real-time indexing, a query planner with no cost model for filtered vector search, hybrid search you must build yourself — and for many small teams a managed vector database is the simpler and cheaper option	The Case Against pgvector

Both can hold: the consolidate-first instinct is right, and vector search is the one workload where the specialised store earns its keep earliest. The deciding question is not “does Postgres have the feature” but “am I willing to own the operational complexity.” Detail in Vector Databases and pgvector in Production.

Worth noting the same essay undercuts the escape hatch: pgvectorscale, the extension that fixes much of this, is not available on AWS RDS — so the “keep it simple” path ends at running your own Postgres.

---

Relationships

• NoSQL and Document Databases — the specialized alternative Postgres often replaces (jsonb)
• Query Optimization — Postgres indexing carries most workloads
• Microservices — resisting per-service datastore sprawl
• Go — shares the simplicity-first engineering ethos
• System Design — scale for the load you have, not an imagined one
• Vector Databases and pgvector in Production — the strongest counter-case to this principle

---

References

• Kafka is fast — I’ll use Postgres
• Redis is fast — I’ll cache in Postgres
• The Case Against pgvector — Alex Jacobs, 2025-10-29 (the counter-case)