Elasticsearch vs PostgreSQL for Search
Fast recall
Quick revision
Core answer
Whether you understand that Elasticsearch is a specialized search engine optimized for a different problem than a relational database, and can articulate when each is the right choice.
Treating Elasticsearch as a general-purpose database or as a drop-in replacement for PostgreSQL. Elasticsearch lacks full ACID transactions and is not suitable as a primary data store.
Describe the dual-write pattern -- writing to PostgreSQL as the source of truth and syncing to Elasticsearch for search -- and how to handle consistency between the two.
Interview-ready guide
Interview answer
PostgreSQL and Elasticsearch solve different problems. PostgreSQL is a relational database with full-text search as an added feature; Elasticsearch is a search engine first that happens to store documents. The question is whether your search requirements justify the operational cost of a separate service.
Where PostgreSQL full-text search is sufficient
- PostgreSQL's
tsvectorandtsquerywith a GIN index provide fast keyword search, stemming, and basic relevance ranking on millions of documents — no separate service to operate, no sync pipeline to maintain - For a simple "search posts by keyword" feature on a moderately-sized dataset (up to a few million rows), PostgreSQL FTS is often enough and the simpler choice
Where Elasticsearch wins
- Elasticsearch is built around an inverted index optimized for search — it handles fuzzy matching (
fuzziness: AUTO), autocomplete (edge n-gram analyzers), multi-field relevance tuning (field boosting), and faceted navigation (aggregations) naturally, whereas each of these requires significant custom PostgreSQL work - At hundreds of millions of documents or high search query volume (thousands of search requests per second), Elasticsearch's distributed architecture scales horizontally in ways a single PostgreSQL instance cannot
- Complex relevance scoring — boosting recent articles, penalizing low-engagement posts, combining BM25 scores with custom signals — is expressed as a query in Elasticsearch and would require custom SQL functions and application-level sorting in PostgreSQL
The operational cost
- Elasticsearch requires a sync pipeline — writes go to PostgreSQL (the source of truth) and must be replicated to Elasticsearch; dual-write from the application, CDC via Debezium, or a scheduled sync job each have failure modes
- For a startup or small team, that operational overhead often isn't justified until the search requirements outgrow PostgreSQL FTS
Elasticsearch vs PostgreSQL for Search
Direct Answer
Elasticsearch is purpose-built for full-text search and analytics with an inverted index, relevance scoring, and near real-time search across large datasets. PostgreSQL supports full-text search via tsvector and GIN indexes, but lacks relevance tuning, distributed horizontal scaling, and the rich query DSL that Elasticsearch provides. For simple keyword search on small datasets, PostgreSQL is sufficient; for complex, relevance-ranked, or large-scale search, use Elasticsearch.
Common Mistakes & Pitfalls
Treating Elasticsearch as a general-purpose database or as a drop-in replacement for PostgreSQL. Elasticsearch lacks full ACID transactions and is not suitable as a primary data store.
Check your understanding
Answer these without looking back at the article.
- How do you keep Elasticsearch in sync with PostgreSQL when both are written to?
- What is the Elasticsearch refresh interval and how does it affect search latency?
- When would you use PostgreSQL full-text search instead of Elasticsearch?
Related interview prep categories
1Looking for a structured roadmap?
Every module on this page is also part of the full Java backend interview track.