PostgreSQL for Everything

Raphael Bauer wrote a manifesto for using PostgreSQL as your entire infrastructure. Not just as a relational database. As your cache. As your full-text search. As your message queue. As your time-series store. The pitch is simple. PostgreSQL already has pgvector for embeddings, pg_trgm for fuzzy search, LISTEN/NOTIFY for pub-sub, and partitioning for time-series data. You get ACID transactions across all of it. One backup strategy. One connection pool. One thing to monitor. The counterargument is also simple. Redis is faster for caching. Elasticsearch has better relevance tuning. Kafka has better throughput for event streams. Specialised tools exist because general-purpose databases make compromises. But the article is not wrong about operational complexity. I have seen teams spend two weeks debugging a Redis cluster failover that would have been a one-line PostgreSQL query. I have seen Elasticsearch mappings drift from the source of truth because someone forgot to update both schemas. Message queues add latency and failure modes that do not exist when you write to a table and poll it. The trick is knowing when PostgreSQL stops being enough. If you are handling 10,000 requests per second and every one needs a cache lookup, you will hit connection limits. If your search corpus is five hundred million documents, you will want inverted indices that PostgreSQL cannot build efficiently. If your event stream is append-only at fifty thousand messages per second, a table with a sequential scan is the wrong tool. But for the median application, the one serving a few hundred requests per second with a team of three engineers, PostgreSQL for everything is not a meme. It is a forcing function. It makes you ask whether the complexity of adding another service is worth the marginal performance gain. Most of the time, it is not.

---

Source: PostgreSQL for Everything