Why your site search is worse than Google's

Most in-product search starts as a `LIKE '%term%'` query, which works until someone makes a typo, searches a plural, or types two words in the wrong order.

Users have been trained by search engines to expect far more, and they judge your search against that.

What users actually expect

• Typo tolerance — "inviocing" should still find invoicing.
• Word stemming — "running" matches "run".
• Relevance ranking — a title match outranks a passing mention in a footnote.
• Partial matching as they type, not only on submit.
• Sensible handling of multiple words in any order.

A substring query delivers none of these.

Postgres full-text goes surprisingly far

Before adding a search service, it is worth knowing how much Postgres already does: stemming, stop words, weighted ranking across fields, and a GIN index to make it fast.

For a catalogue in the tens of thousands of rows, this is frequently sufficient, and it avoids running and syncing a second system. The notable gap is typo tolerance, which needs the trigram extension alongside it.

When a dedicated engine earns its place

At larger catalogues, when you need faceting across many attributes at once, when typo tolerance must be excellent rather than adequate, or when sub-50ms results matter commercially.

The cost is a second system to run, and the hard part is keeping it synchronised. An index that silently drifts from the database produces results users cannot reproduce, which is worse than slow search.

Measure what people search for

The most valuable thing you can do costs almost nothing: log queries, and log which ones returned nothing.

A zero-results list is the clearest product feedback you will ever receive. It tells you what people expected to find, in their own words — which is both a search problem and a roadmap.

Do I need Elasticsearch for site search?

Usually not. Postgres full-text search with a GIN index and the trigram extension covers typo tolerance, stemming and weighted ranking, and handles catalogues in the tens of thousands of rows comfortably. A dedicated engine earns its complexity at larger scale, with heavy faceting, or when search quality is itself a competitive feature — not simply because the current search is bad.

Why does my search return nothing for obvious terms?

Most often because it is matching exact substrings rather than normalised tokens, so a plural, a hyphen or a different word order misses. Check what your query actually does before replacing the engine — the usual fix is stemming and ranking rather than a new system. Then log the zero-result queries, because they will tell you precisely which assumptions are wrong. Search quality is a recurring theme in e-commerce, where it directly decides whether people keep browsing.