Choosing a Search Engine: Elasticsearch vs Postgres vs Redis vs OpenSearch, Solr and Typesense

Your Postgres database already ships with a real full-text search engine, built on the same inverted index idea as Lucene. Most teams never try it before adding a whole new cluster. This blog is about that choice: when the search you already have is enough, and which engine to reach for when it isn't.

For this blog, we compare what each engine is, how it indexes, and what it costs you to run. There are no benchmarks here. Speed depends on your data and hardware, and vendor numbers are marketing until you test them yourself.

01The real question: one more system, or not?

You don't buy a second fridge because you bought more milk. You first check whether the one you have has room. Search engines are the same.

A separate search engine costs you more than its server bill:

• A second copy of your data, which can drift from the first.
• A sync pipeline (an outbox or CDC feed) to keep that copy fresh. We built one in Elasticsearch for system design.
• Lag between "saved" and "searchable".
• Another thing to page someone at 3 a.m.

In return, you get richer relevance tuning, typo tolerance, facets, scale-out across many machines, and heavy search traffic kept off your primary database. Those are real wins, when you need them.

02Postgres full-text search: the one you already have

Postgres has had full-text search built in for years. The introduction to its text search chapter names the pieces:

• tsvector: a document turned into normalised words (lexemes) with their positions. "Running shoes" becomes 'run':1 'shoe':2.
• tsquery: the parsed search query, with AND, OR and NOT.
• @@: the match operator. "Does this tsvector match this tsquery?"
• Dictionaries, including Snowball stemmers: Postgres's version of analyzers, deciding that "running" and "run" are the same word.

The index is the part that matters. Postgres's page on preferred index types for text search says GIN is the preferred choice, because it's an inverted index with one entry per lexeme. GIN literally stands for Generalized Inverted Index. The alternative, GiST, is lossy: it can return false matches, so Postgres must recheck each candidate row. Here's the whole thing in a few lines:

-- One column that holds the analysed text, kept up to date by Postgres
ALTER TABLE products ADD COLUMN search tsvector
  GENERATED ALWAYS AS (
    to_tsvector('english', coalesce(title, '') || ' ' || coalesce(body, ''))
  ) STORED;

-- The inverted index
CREATE INDEX products_search_idx ON products USING GIN (search);

-- Match with @@, rank with ts_rank
SELECT id, title, ts_rank(search, q) AS rank
FROM products, websearch_to_tsquery('english', 'running shoes') AS q
WHERE search @@ q
ORDER BY rank DESC
LIMIT 10;

It's the same pipeline as Lucene, inside your database, as the diagram shows: analyse the text, invert it, match, rank.

Where it hurts. Ranking. The text search controls page warns that ts_rank and ts_rank_cd can be expensive, because they read the tsvector of every matching document. Finding 50 matches is cheap; ranking 2 million matches to show the top 10 is not. Also, the built-in ranking isn't BM25, typo tolerance is limited, there are no facets out of the box, and scaling out across machines is your problem.

Substring search. For "find '%shoe%' anywhere in a name" or fuzzy-ish name matching, the pg_trgm extension indexes three-letter slices (trigrams) with GIN or GiST. Those indexes support LIKE, ILIKE and regex matches, and unlike a B-tree, the search string need not be anchored at the start.

CREATE EXTENSION IF NOT EXISTS pg_trgm;
CREATE INDEX products_title_trgm ON products USING GIN (title gin_trgm_ops);
-- Now this can use the index instead of scanning every row:
SELECT id, title FROM products WHERE title ILIKE '%shoe%';

The strengths are big. It's transactional: the row and its index change together, so there's no sync pipeline and no lag. You can join search results with the rest of your data in one query. And it's one system to run, not two.

A real example: Instacart moved its full-text search to sharded Postgres, using GIN indexes and a modified ts_rank, and later added pgvector for hybrid search in the same engine. They report a 10x drop in write workload, because a normalised schema meant far fewer partial updates than their denormalised search index needed.