Algolia alternatives for a technical catalog: what each engine does with M8x30

The question put to every engine

An M8 screw, 30 mm long, DIN 933 standard, reaches a catalog under several spellings, and buyers type still others:

An engine has to do two things with these spellings: bring them together, and rank the right dimension above the wrong one. An M8x300 contains the same characters as an M8x30, and it is not the same screw.

What we read, and what we didn't do

For each competitor, we read its public documentation on September 16, 2026, and every claim below links to its page. We didn't try any of these products. When a documentation page says nothing about a case, we say so rather than guess. Heurix, on the other hand, is measured, and what it gets wrong is further down.

Algolia

According to its tokenization documentation, letters and digits form a single block and the dash is a separator. By that rule, "M8x30" stays one word, and a query with a dash requires its pieces to appear in order. Algolia can also join two words typed apart or split one word in two, with an exception that affects references: a piece that starts with a digit isn't joined to its neighbors. What happens to "DIN 933" against "DIN933", that page doesn't say, and we haven't tried it.

For codes with dashes, its guide recommends storing in each record the list of spellings of the reference, with and without spaces. Its rules recognize literal words or any value of a declared facet. So you can target every value of a "diameter" field; the page doesn't offer a way to write a pattern such as "M followed by a number".

Typesense

Its documentation says Typesense removes special characters by default, when indexing and when searching: in its example, a reference with dots becomes a single joined string. You can declare those characters as separators, field by field. The split_join_tokens parameter treats a space as a typo and tries the joined or split form, but only when the original query returns nothing. The same page enables typo tolerance by default on words that mix letters and digits.

Its curation rules can filter on a facet value found in the query. As with Algolia, recognition works on declared values, not on a pattern.

Meilisearch

In its tokenizer's code, the dash is among the default separators. Its documentation describes concatenation: up to three consecutive query words are also tried joined, and each joined form counts as one typo in ranking. By that rule, "DIN 933" can find "DIN933", behind an exact match; that is what the page describes, not what we measured.

Its search rules support, according to their own page, neither regular expressions nor numeric patterns.

Elasticsearch

Elasticsearch provides building blocks rather than a behavior. Its standard tokenizer follows the Unicode text segmentation algorithm. The word_delimiter_graph filter splits by default at letter-digit boundaries, as in their example where "j2se" gives three pieces; its re-joining options produce tokens that indexing doesn't support without precautions, the same page says. For an exact code, a normalizer emits a single token. Everything is possible, provided you assemble it: we inventoried that work in a dedicated article.

Doofinder and Sensefuel

Doofinder indexes a product's identifiers by default, including SKU, reference and GTIN, and offers fields that search on parts of a reference number. Its custom results include or exclude products for given terms. What those fields do with a dash or a space in a code, we didn't find in its documentation.

Sensefuel presents a search that understands semantics and tolerates typos. We found no public page on how it handles product codes, and its help center didn't open to our reading. So we say nothing about it.

Platform native engines

• Shopify: SKU is searched, and part of a code is found only when the code contains dashes (documentation).
• PrestaShop: the shipped configuration sets the minimum word length to 3 characters, and the search code skips shorter words. "M8" typed alone doesn't count.
• WooCommerce: the storefront search code (version 11.1.0) matches words against the title, excerpt and content; SKU isn't among them.
• Adobe Commerce (Magento): the documentation says searching by the end of a SKU isn't supported out of the box.

What these engines do by default, in detail: why your platform's native search engine isn't enough.

Heurix: recognition, not normalization

Heurix doesn't bring these spellings together by cleaning the text. Its normalization only unifies casing: "din-933", "din 933" and "din933" remain three different splits. Rules written as regular expressions, grouped by industry, read each spelling and produce the same label. Output of the production engine, hardware industry:

M8x30      → DIAM_M8, LONG_30, VIS_M8X30
M8 x 30    → DIAM_M8, LONG_30, VIS_M8X30
M8-30      → DIAM_M8, LONG_30, VIS_M8X30
DIN-933    → NORME_DIN933
DIN 933    → NORME_DIN933
din933     → NORME_DIN933

The same rules read product records and queries. That is what ranks the right dimension above the wrong one: on our bench, the query "M8x30" puts the five M8x30 screws, whatever their spelling, above the M8x300, the M8x35 and the M10x30. Spelling still weighs: the same screw scores 36 or 22.5 depending on whether its record says "M8x30" or "M8 X 30".

What Heurix gets wrong, measured

Bench run on September 16, 2026 against the production engine (cbfc93d): a test catalog of 12 screws with the hardware industry, one of 5 bearings with the industry sector, identical results across two runs. A bench this size tells you whether a case works, not how often it comes up in your catalog.

And bearings are recognized only when the catalog uses the industry sector: the hardware sector doesn't read "6205-2RS".

When to choose another engine

• Your customers search by words, not codes. The criterion in this article then weighs little, and the comparison plays out elsewhere.
• You want to host the engine yourself. Typesense documents self-hosting; Heurix is an API, hosted in France at OVH.
• Visual merchandising comes before references. Doofinder documents its custom results, Sensefuel highlights banners and promoted products.

How to decide

Take a reference from your catalog and type it into your current engine in every spelling from the table at the top, then in an incomplete form. Count the results, and check whether the right dimension comes first. Then run the same test on Heurix, free for 14 days: you'll also see what it gets wrong on your catalog.

On references themselves: configuring search by reference on a B2B e-commerce site.

Sources

Documentation read on September 16, 2026. Algolia: tokenization, splitting and concatenation, hyphenated codes, rules. Typesense: common data types, search parameters, curation, installation. Meilisearch: tokenizer code, typo tolerance, search rules. Elasticsearch: standard tokenizer, word_delimiter_graph, normalizers. Doofinder: indexing, search fields, custom results. Sensefuel: search page. Shopify: search behavior. PrestaShop 9.1.5: shipped configuration and Search.php. WooCommerce 11.1.0: class-wc-query.php. Adobe Commerce: search results. Each page is linked where it is cited.

Rewritten on September 16, 2026. The July version claimed these engines make you write rules "one by one, reference by reference", without a source: their documentation shows they already bring together some spellings without any rule. It also compared prices without a source, and said nothing about what our engine gets wrong.