Default platform search matches strings. Real catalogs are full of things that do not match cleanly — a half-inch fitting written four ways, a part number with or without dashes, a brand spelled the way customers hear it.

That is the whole problem statement. Choosing an engine is choosing how much of it you have to solve yourself.

What default search gets wrong

  • No meaningful typo tolerance, so one wrong character returns nothing
  • Weak or absent faceting, so filters have to be rebuilt in the application
  • No synonym management, so trade vocabulary is invisible
  • Ranking on text-match score alone, so discontinued products outrank in-stock ones
  • No search analytics, so nobody learns what failed

Where Elasticsearch fits — and does not

Elasticsearch can do all of this and considerably more. The cost is operational: cluster management, shard planning, JVM heap tuning, mapping migrations. For a team running a catalog of tens or hundreds of thousands of products, that is a large ongoing burden for capability they will not use.

Where Elasticsearch genuinely wins is log and event analytics at scale, complex aggregation, and search over very large heterogeneous corpora. Product discovery is not that problem.

What Typesense does differently

  • Typo tolerance is on by default and tunable per field
  • Faceting and filtering are first-class, not an add-on
  • Synonyms are a managed configuration, not application logic
  • Sub-15ms p95 latency at catalog scale on modest hardware
  • A single binary to run, and self-hostable
// ranking that reflects the business, not just text score
{
  q: "brass faucet 1/2",
  query_by: "name,sku,tags",
  sort_by: "_text_match:desc,in_stock:desc,margin_rank:desc",
  num_typos: 2,
  facet_by: "category,brand,size"
}

Relevance is a data problem

No engine fixes inconsistent source data. Dimensions written four ways still need normalising on the way into the index; part numbers still need indexing with and without separators; trade synonyms still have to be captured from real query logs and sales knowledge.

The highest-value input to relevance is your own zero-result query log. If you are not recording it, start there before changing engine.

When not to choose it

If the requirement is log analytics, heavy aggregation, or a corpus in the hundreds of millions of heterogeneous documents, Elasticsearch or OpenSearch remains the correct answer. If the team has no capacity to host anything, a managed service is worth its price.

For a product catalog where the actual complaint is that customers search and find nothing, Typesense self-hosted has been the right call in every engagement we have made it — 12ms p95, and relevance that improves as the query log grows.