# Elasticsearch vs PostgreSQL full-text search > Choose PostgreSQL full-text search when keyword search needs to work closely with relational filters, permissions, and transactional updates without another datastore. Choose Elasticsearch when search needs richer relevance controls, built-in fuzzy matching, or independent distributed scaling, and you can operate an asynchronously updated search index. Source: https://sysround.com/compare/elasticsearch-vs-postgres-full-text-search Updated: 2026-11-05 ## Side by side | | Elasticsearch | PostgreSQL full-text search | |---|---|---| | Core model | Dedicated document search engine | Full-text search inside a relational database | | Text indexing | Analyzed fields backed by inverted indexes | tsvector fields, commonly indexed with GIN | | Relevance | BM25 by default; extensive scoring controls | ts_rank and ts_rank_cd; custom SQL scoring | | Search features | Built-in fuzzy queries, analyzers, and aggregations | Stemming, weighting, phrase queries; extensions for fuzzy matching | | Freshness | Search visibility follows indexing and refresh | Transactionally maintained vectors follow SQL visibility | | Relational filtering | Often requires denormalized search documents | SQL joins, predicates, and row-level security | | Scaling | Built-in sharding and replication | Replicas and partitioning; distributed sharding needs more design | | Operational cost | Search cluster plus synchronization and rebuild pipeline | Fewer systems, but search competes with database workloads | ## The differences that matter Both can use inverted indexes, so the distinction is not indexed search versus table scans. PostgreSQL commonly uses a GIN index over a tsvector to find matching rows. Its standard full-text ranking functions then score candidates, and broad matches can require substantial ranking and sorting work. Elasticsearch offers a dedicated retrieval engine with more built-in relevance controls, but its performance still depends on query shape, shard layout, and data distribution. Elasticsearch gives you more search-specific tools out of the box: BM25 scoring, field boosts, fuzzy queries, configurable analyzers, and aggregations for facets. PostgreSQL supports stemming, stop words, weighted fields, phrase matching, and highlighting. Typo tolerance can be added with pg_trgm, but that is a separate matching mechanism you must combine with full-text retrieval and ranking. PostgreSQL can update a row and its search vector in the same transaction, using a generated column, trigger, or explicit write. Searches then follow normal transaction snapshot rules, with replicas potentially lagging. Elasticsearch search visibility follows refresh, and a PostgreSQL-to-Elasticsearch architecture also adds ingestion lag. Waiting for a refresh does not make the two stores one transaction. PostgreSQL lets search use current relational data through joins, predicates, and row-level security. Elasticsearch usually stores denormalized fields so it can filter without cross-service joins. That improves search independence, but changes to shared metadata or permissions can require many document updates. For sensitive data, explain how current authorization is enforced before returning results rather than trusting stale indexed permissions. Elasticsearch can scale search separately from transactional writes, but introduces shard sizing, replica placement, mappings, index rebuilds, and synchronization failures. PostgreSQL avoids that extra system, yet text indexes add storage and write maintenance, while expensive searches can compete with transactions for CPU and I/O. There is no universal document-count threshold where one becomes the right answer; benchmark representative queries and update traffic. ## Choose Elasticsearch when - Search is a core product feature requiring typo tolerance, custom analyzers, field-specific scoring, and repeated relevance tuning. - Search traffic needs capacity and failure isolation separate from the transactional database. - A distributed search index is justified by measured corpus size, query concurrency, or aggregation workload. - The product accepts a defined search-freshness delay, and the team can build reliable ingestion, replay, deletion, and reindexing workflows. ## Choose PostgreSQL full-text search when - You already store the searchable records in PostgreSQL, and stemming, phrase matching, and weighted keyword ranking meet the requirements. - Search depends heavily on relational joins, tenant boundaries, or current permissions. - A committed edit must be searchable through the primary database without waiting for a separate indexing pipeline. - Representative load tests meet latency targets, and avoiding another datastore matters more than advanced search features. ## Worked example: A marketplace where freshness and relevance pull apart Suppose a marketplace stores 2 million listings in PostgreSQL, serves 100 search requests per second, and targets a 200 ms p95. These are design requirements, not a capacity claim. If users need keyword matching plus category, price, and seller filters, test PostgreSQL with a maintained tsvector and GIN index first. If requirements expand to typo tolerance, multilingual analysis, and complex facets, evaluate Elasticsearch with the same queries. Keep listing state authoritative in PostgreSQL and publish changes through CDC or an outbox. Define a search-lag target, monitor it, and recheck availability before purchase. For private listings, validate authorization before returning content. ## In the interview - Start with the search contract: keyword versus fuzzy matching, languages, ranking quality, filters, facets, and acceptable freshness. These requirements justify the choice better than saying Elasticsearch is for large datasets. - Estimate document count, average indexed text size, query rate, update rate, and filter selectivity. Expect follow-up questions about broad queries, ranking cost, hot tenants, and index storage overhead. - If choosing Elasticsearch alongside PostgreSQL, name the source of truth and explain CDC or a transactional outbox. Cover idempotent indexing, document versions, deletes, retry handling, and a rebuild that does not overwrite newer changes. - State the consistency boundary explicitly. Search can return stale candidates, but purchases and other authoritative actions must validate current database state; permission-sensitive results need a current authorization check before disclosure. - Describe the growth path and failure behavior. PostgreSQL can be the initial choice with a later search projection; an Elasticsearch outage can degrade search without stopping transactional writes if ingestion is durable. ## Common mistakes - Claiming PostgreSQL full-text search scans every row. A suitable GIN index can accelerate matching, although ranking and sorting may still be expensive. - Treating PostgreSQL full-text search and pg_trgm as interchangeable. Lexeme-based matching and trigram similarity solve different problems. - Writing separately to PostgreSQL and Elasticsearch without durable synchronization, then ignoring partial failures, out-of-order updates, and missed deletes. - Choosing by row count alone or assuming Elasticsearch is always faster. Query shape, relevance requirements, filters, update load, and operational constraints change the answer. ## Interview questions where it comes up - [Design Facebook post search](https://sysround.com/questions/design-facebook-post-search): The choice determines distributed keyword retrieval, index freshness, and how permission changes remain safe despite stale search documents. - [Design Wikipedia or Notion](https://sysround.com/questions/design-wikipedia): Document search must balance relevance and indexing freshness against current page permissions and transactional edits. - [Design Facebook Marketplace](https://sysround.com/questions/design-facebook-marketplace): Listing discovery combines keyword relevance and filters while search results may lag authoritative availability and visibility. - [Design a restaurant review app like Yelp](https://sysround.com/questions/design-yelp): Restaurant discovery can require ranked text search and facets alongside relational review data and frequently changing metadata. ## FAQ ### Is Elasticsearch faster than PostgreSQL full-text search? Not for every workload. Elasticsearch offers a dedicated distributed search engine, while PostgreSQL can perform well for indexed keyword searches combined with selective SQL filters. Compare representative queries, ranking behavior, update traffic, and tail latency rather than relying on a universal benchmark. ### Can PostgreSQL replace Elasticsearch? Yes, when PostgreSQL's text matching, ranking, and operational capacity meet the product requirements. It is particularly useful when search must join current relational data or share transaction visibility with writes. Replacing advanced relevance behavior, fuzzy retrieval, or large distributed aggregations may require extensions, custom logic, or a different design. ### Should I use PostgreSQL and Elasticsearch together? Use both when PostgreSQL is the transactional source of truth and Elasticsearch provides a search experience or scaling model that justifies a separate index. Synchronize through CDC or a transactional outbox rather than uncoordinated application dual writes. Plan for lag, duplicate events, version ordering, deletes, and complete index rebuilds. ## Related concepts - [Full-text search](https://sysround.com/concepts/full-text-search) - [Inverted index](https://sysround.com/concepts/inverted-index) - [Database indexing](https://sysround.com/concepts/database-indexing) - [Change data capture](https://sysround.com/concepts/change-data-capture) - [Eventual consistency](https://sysround.com/concepts/eventual-consistency) --- SysRound (https://sysround.com) is an AI practice tool for system design interviews: a voice or typed AI interviewer, a shared whiteboard, then feedback on every skill and a model answer. Its feedback is AI-generated and can be wrong.