Codewerk.
Get a quote
Home/Blog/Elasticsearch for product search: the parts that pay

Elasticsearch for product search: the parts that pay

MySQL LIKE queries die at 50,000 products. Here is what Elasticsearch fixes, what it does not, and the fields that decide relevance.

Photo: free stock photography (Unsplash licence) — see imprint

When you actually need it

Under roughly 10,000 simple products, the database is fine and Elasticsearch is a second system to operate for nothing. Above that — or with heavy faceting, synonyms and typo tolerance — search becomes the slowest page in the shop, and that is when it pays.

B2B search is not B2C search

Your buyers search by article number, manufacturer part number, EAN and internal codes — not by lifestyle adjectives. Weight those fields hard, make exact matches beat fuzzy ones, and never let a fuzzy match outrank an exact SKU.

Synonyms are a business asset

Your customers call it a 'grub screw', your catalogue says 'set screw'. A synonym list built from your real zero-result search log is one of the highest-ROI hours you will ever spend on the shop.

Reindexing is the operational cost

Every price or stock change must reach the index, and a full reindex of a large catalogue is not instant. Plan for incremental updates via queue and accept that the index is eventually consistent — then never show stock from it.

Key takeaways
  • Below 10k simple products, stay with the database.
  • Exact SKU must always beat fuzzy matches.
  • Mine your zero-result log for synonyms.

Frequently asked questions

Below roughly 10,000 simple products the database handles search fine, and Elasticsearch is a second system to operate for no return. It starts paying above that, or when you need heavy faceting, synonyms and typo tolerance and search has become the slowest page in the shop. If nobody is complaining about search, this is not your bottleneck.

Because it was tuned for a B2C catalogue. Your buyers search by article number, manufacturer part number, EAN and internal codes, not by lifestyle adjectives. Weight those fields hard and make an exact match always beat a fuzzy one. A fuzzy hit outranking an exact SKU is the single most common relevance bug we find in B2B shops.

No. The index is eventually consistent: every price and stock change has to reach it, normally through a queue, and there is always a window in which it is behind reality. Read stock from the source when you display it. Showing an availability count out of a search index is how you sell something you do not have.

A synonym list built from your own zero-result search log. Your customers type 'grub screw', your catalogue says 'set screw', nobody finds anything and nobody reports it. Reading that log and mapping the terms costs an hour, needs no new system, and often beats what a full search rewrite would have delivered.

We do this for a living — Shopware, Node.js, React, ERP integration and automation for B2B.

Talk to an engineer

// Keep reading

Related articles