The pattern has become familiar enough to have a name: the Postgres consolidation. Over the last three years, the database that once handled only relational storage has quietly absorbed the roles of Redis, Elasticsearch, and Pinecone. What was a stack of four or five services is now, for many teams, just Postgres with a few extensions loaded. The question is no longer whether Postgres can do it. The question is when it cannot.

The consolidation pattern

This is not accidental. Postgres’s expansion is driven by a deliberate pattern of extension adoption that mirrors the rise of the specialized databases it now replaces. Martin Heinz, in his blog post on using PostgreSQL as a cache, notes that many new databases are implemented on top of Postgres, citing TimescaleDB and others as examples that are “really just PostgreSQL with some extra features sprinkled on top.” The same logic applies to the extensions that turn Postgres into a cache, a search engine, or a vector database.

The pgvector extension, first released in 2023, added vector similarity search capabilities that compete with dedicated vector databases like Pinecone. The pg_trgm extension, documented in the PostgreSQL manual, provides trigram-based text search that can replace Elasticsearch for many use cases. And as Heinz demonstrates, PostgreSQL itself, without any extension, can replace Redis for caching through UNLOGGED tables.

Each of these extensions arrived not as a compromise but as a deliberate trade-off. The question is whether your team can live with the trade-offs.

What Postgres now handles

Start with caching. Heinz demonstrates that UNLOGGED tables in PostgreSQL can implement a cache with expiration, eviction, and invalidation, avoiding the need to deploy a separate service like Redis or Memcached. UNLOGGED tables do not generate Write Ahead Log information, which Heinz notes provides huge improvements in write performance and saves disk space. The trade-off is explicit: these tables are not crash-safe and are only available on the primary, not on replicas. If the database crashes, the cache is gone. For many applications, that is acceptable. The cache was going to be rebuilt anyway.

For full-text search, pg_trgm offers trigram-based matching that handles fuzzy search, autocomplete, and relevance ranking without a separate Elasticsearch cluster. The indexing is simpler, the query syntax is SQL, and there is no second system to monitor. For vector search, pgvector provides approximate nearest neighbor search that works for most recommendation and similarity use cases without spinning up a Pinecone instance.

PostgreSQL’s LISTEN/NOTIFY feature adds asynchronous messaging between database sessions, often used as a lightweight alternative to dedicated message queues like RabbitMQ or Redis Pub/Sub. One database, one operational surface, one set of backups.

Each extension arrived not as a compromise but as a deliberate trade-off. The question is whether your team can live with the trade-offs.

Cases where a specialty store still wins

The trade-offs matter most at the edges. Heinz acknowledges that using one tool like PostgreSQL for multiple purposes can save costs and overhead, but the benefits of purpose-built services become clear when performance demands exceed Postgres’s capabilities.

Redis still wins for high-throughput caching where every microsecond of latency counts. An UNLOGGED table is fast, but it is still Postgres: same query planner, same connection pool, same contention with other workloads. When your cache is handling millions of requests per second and cannot afford to share a connection pool with the primary database, Redis earns its place.

Elasticsearch still wins for complex search analytics: faceted search, aggregations across large indexes, and time-series log analysis. pg_trgm is excellent for autocomplete and fuzzy matching on a single table, but it does not replace a dedicated search index built for exploratory queries across heterogeneous data.

Pinecone still wins for large-scale vector similarity when you need dedicated hardware for distance calculations and the recall guarantees of a purpose-built index. pgvector works well up to millions of vectors. Beyond that, the performance characteristics shift.

The cost of breadth

The same features that make Postgres versatile introduce operational risks. Heinz notes that UNLOGGED tables are not crash-safe, meaning a database restart can wipe your cache entirely. That is fine for a cache. It is not fine if you start treating UNLOGGED tables as persistent storage.

At scale, write-heavy workloads can saturate the single primary Postgres instance. Replicas help with reads, but writes still hit one node. Specialty databases often distribute writes across a cluster natively. And while Postgres extensions are powerful, they add complexity to upgrades and migrations. An extension that was stable in version 14 may behave differently in version 16.

Multi-tenant isolation is another pressure point. In a shared Postgres instance, one tenant’s heavy query can degrade performance for everyone. A dedicated cache or search service provides natural isolation boundaries that are harder to enforce in a single database.

A practical checklist

The decision framework is straightforward. Use Postgres for caching when your cache can tolerate a cold start after a crash. Use pg_trgm for full-text search when your search needs are limited to a few tables and you do not need faceted aggregation. Use pgvector for vector search when your vector count is in the millions, not billions, and your latency requirements are measured in milliseconds, not microseconds.

Switch to a specialty database when your performance demands exceed Postgres’s capabilities. That threshold is different for every team, but it usually arrives when the operational cost of tuning Postgres for a single workload exceeds the cost of running a second service.

Postgres wins on simplicity and cost for most workloads. Specialty databases win on raw performance for the top ten percent of use cases. The teams that choose wisely are the ones that know which ten percent they are in.

The database that ate everything did not eat everything. It just ate enough that the remaining questions are worth asking.