Postgres Is All You Need
Every modern web application seems to follow the same pattern: PostgreSQL for relational data, Redis for caching and queues, MongoDB for document storage, ElasticSearch for search. Before you know it, you're managing four or five different data systems, each with its own deployment, monitoring, and failure modes.
But what if you didn't need all of that? Pat Spizzo makes a compelling case in this talk that PostgreSQL alone can handle most of what these specialized tools do - and often well enough for the majority of applications.
What PostgreSQL can replace
Queues, instead of Redis or RabbitMQ
Postgres gives you LISTEN/NOTIFY and SKIP LOCKED, which is enough to build a solid job queue. If you're processing a few hundred jobs a second - which covers most apps - a Postgres-backed queue is plenty. Laravel ships with database queues out of the box.
Documents, instead of MongoDB
The jsonb type gives you document storage with real indexing through GIN indexes. You can query nested fields, build partial indexes on specific keys, and still get ACID transactions - something MongoDB only added years later.
Full-text search, instead of ElasticSearch
Postgres has full-text search built in with tsvector and tsquery, including ranking, stemming, multiple languages, and phrase matching. Unless search is the product, that's usually enough.
Caching, instead of Redis
UNLOGGED tables skip the WAL overhead for fast writes, much like reaching for Redis as a cache. Combined with Postgres's own memory management, you get a caching layer without running another service.
Time-series data, instead of TimescaleDB or InfluxDB
Partition tables by date range, add the native compression in recent versions, and Postgres handles plenty of time-series workloads without a specialized store.
When does this approach break down?
This isn't about PostgreSQL being the best at everything. ElasticSearch will outperform Postgres for complex search queries across billions of documents. Redis will be faster for sub-millisecond caching. The question is whether your application actually needs that level of performance.
Most applications don't. Most applications have tens of thousands of rows, not billions. Most search needs are "find users by name" rather than "relevance-ranked full-text across terabytes." For those cases, adding another service to your infrastructure creates complexity that costs more than the marginal performance gain.
The real benefit
Running fewer services means fewer things that can break at 3 AM. It means one backup strategy, one monitoring setup, one connection pool to manage, and one technology for your team to master. That operational simplicity compounds over time - especially for small teams.
Start with Postgres. Add specialized tools only when you can measure a specific bottleneck that Postgres can't solve.