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.

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

Talk to an engineer

// Keep reading

Related articles