Your Elasticsearch Cluster is Probably Overkill
Instacart's move to PostgreSQL for search infrastructure reveals uncomfortable truths about search engine complexity versus relational database maturity.
The Search Engine Industrial Complex is Crumbling
Instacart just dropped a bombshell that should make every engineering team with an Elasticsearch cluster sweat: they’re consolidating their entire search infrastructure onto PostgreSQL and phasing out Elasticsearch entirely. This isn’t some small startup cutting corners, this is a company handling millions of grocery searches daily deciding that a 30-year-old relational database outperforms the specialized search engine everyone told them they needed.
The conventional wisdom that “real search requires Elasticsearch” is showing its cracks. Maintaining two separate databases introduced synchronization challenges that became increasingly painful at scale. The re-indexing process in Elasticsearch, particularly when dealing with embeddings and vector search, becomes cumbersome enough to make engineers question the entire stack.
When Your Search Engine Becomes the Bottleneck
The problem isn’t that Elasticsearch is bad at searching, it’s that it’s too good at being complicated. Teams implement Elasticsearch because they’ve been told it’s the “right tool for search”, only to discover they’ve traded one set of problems for another.
Consider the operational overhead: Elasticsearch clusters require specialized knowledge to maintain, scale, and troubleshoot. When something breaks, you’re not debugging standard SQL, you’re diving into distributed systems, shard allocation, and JVM tuning. Meanwhile, PostgreSQL runs on infrastructure your team already understands, with backup strategies you’ve perfected over years.
The synchronization challenge Instacart mentioned isn’t some edge case, it’s the fundamental tax you pay for maintaining multiple truth sources. Every change in your primary database needs to be replicated to your search engine, creating eventual consistency problems that break user experiences at the worst possible moments.
The PostgreSQL Search Revolution is Already Here
PostgreSQL’s full-text search capabilities have evolved dramatically, with features that rival dedicated search engines for many use cases. The tsvector and tsquery types provide sophisticated text search with ranking, phrase matching, and support for multiple languages. When combined with PostgreSQL’s transactional consistency, you get search results that actually match what’s in your database, right now, not eventually.
For Instacart’s use case, product search with filtering, sorting, and relevance ranking, PostgreSQL delivers comparable performance without the operational complexity. Their dataset might not be the petabytes-scale that justifies Elasticsearch’s distributed architecture, but that’s the point: most companies aren’t dealing with that scale either.
The embedding use case mentioned in the research is particularly telling. Vector operations in PostgreSQL using the pgvector extension can handle similarity search with performance that meets production requirements for many applications. You’re not getting the raw throughput of a dedicated vector database, but you’re also not managing another system.
The Scaling Question Everyone’s Afraid to Ask
The obvious counterargument, “PostgreSQL won’t scale like Elasticsearch!”, misses the reality that most applications never reach the scale where it matters. Instacart processes millions of searches daily and found PostgreSQL sufficient. How many teams are maintaining Elasticsearch clusters for applications that would be perfectly served by PostgreSQL’s search capabilities?
When you do hit scaling limits, PostgreSQL’s partitioning, read replicas, and connection pooling provide escape hatches that are often sufficient for another order of magnitude of growth. By the time you truly outgrow PostgreSQL, you’ll have the resources and expertise to implement something more specialized, and you’ll know exactly why you need it.
The real question isn’t whether PostgreSQL can replace Elasticsearch for every use case, it’s whether your specific use case actually requires Elasticsearch’s complexity. For log analytics, security monitoring, and truly massive full-text search, Elasticsearch remains unmatched. For product catalogs, user search, and content discovery, PostgreSQL might be all you need.
The Architecture Simplification Payday
Instacart’s move represents something bigger than technology choice: it’s about rejecting complexity for complexity’s sake. Every new system in your architecture introduces failure modes, operational overhead, and cognitive load. Removing systems is often the highest-leverage improvement you can make.
The teams celebrating this move aren’t just saving on Elasticsearch licensing costs, they’re eliminating entire categories of problems. No more worrying about search index consistency. No more debugging why a document isn’t appearing in search results. No more maintaining separate monitoring and alerting for the search cluster.
The industry’s obsession with specialized tools has created a generation of engineers who reach for Elasticsearch before considering whether their existing database could handle the workload. Instacart’s decision forces a reevaluation of that default, and that’s going to make a lot of architects uncomfortable about their current stack choices.
