Elasticsearch and Lucene for a technical catalog: what you'll have to build yourself

Let's start with what's true

Lucene is the most battle-tested indexing library in the industry. Elasticsearch, which clusters it, runs search for thousands of companies. On plenty of ground, they have no equal.

If your need looks like one of these, don't read the rest: log analysis and observability, very large-scale vector search, analytical aggregations over hundreds of millions of documents, cross-region replication, or a team already running a cluster for other uses. In those cases, Elasticsearch is the right answer and Heurix isn't.

This article's question is narrower: what happens when you want to search a catalog of technical references?

The problem isn't power, it's what you have to write

Take a diameter-8, length-20 screw. In a real catalog, with a real import history, it shows up in these forms:

To a generalist engine, these are five different strings. The standard analyzer splits text according to Unicode segmentation rules: it doesn't know that M8 denotes a diameter, that 20 is a length, or that the hyphen and the "x" play the same separator role here.

What you'll have to write in Elasticsearch

It's doable. Here's the honest inventory, in the order you'll discover it:

• A custom analyzer per reference family, with character filters to normalize separators
• A pattern tokenizer (pattern_capture) to extract diameter, length, standard, material — one pattern per attribute, per industry
• A hand-maintained synonym graph, with the classic multi-word synonym trap at indexing time
• A custom scoring function: the default score, based on term frequency, favors short labels — not exact references
• Multiple fields for each extracted attribute, with the corresponding mapping
• A full reindex on every mapping or analyzer change, since they only apply at indexing time

Budget a few weeks for a developer who already knows Lucene. More if they're learning it along the way — which is the most common case.

Then comes operations, which never stops

Development is a one-time cost. Operations is permanent:

• Three nodes minimum for a production quorum. A single node isn't production, it's a demo.
• Sizing the JVM heap, shard count, segment size. Getting it wrong doesn't cause an outage: it slows things down, gradually.
• Version upgrades with breaking changes, and reindexing that comes with them.
• Monitoring cluster health — it's a distributed system, with the failure modes that come with one.

And one point many discover late: the licensing question. Since 2021, Elasticsearch is no longer under Apache 2.0. It's now available under a choice of three licenses — AGPLv3, added in September 2024, SSPL, and Elastic License 2.0 — but the official distributions remain under Elastic's terms. That change is what triggered AWS's OpenSearch fork, now under Apache 2.0 and governed by the Linux Foundation. Nothing blocking, but a decision to make knowingly if you're embedding the engine in a product you resell.

Heurix's approach: the business logic is already written

Heurix doesn't replace Elasticsearch on its own turf. It does one thing: it ships, pre-written, the analysis work you would have had to produce.

Here's the actual output of its engine on the five spellings above, with the "hardware" rule pack:

M8x20                  → DIAM_M8, LONG_20, VIS_M8X20
M8 x 20                → DIAM_M8, LONG_20, VIS_M8X20
M8X20                  → DIAM_M8, LONG_20, VIS_M8X20
M 8 x 20               → DIAM_M8, LONG_20, VIS_M8X20
M8-20 screw stainless  → DIAM_M8, DIAM_M8_INOX, FAM_VIS, MAT_INOX

Five spellings, the same annotations. That's what lets a customer typing M8-20 screw stainless find a product whose label says M8X20 A2.

Ten industry packs cover hardware, electronics, industry, automotive, electrical, plumbing, fashion, wine, books, and finance. Whatever the pack doesn't recognize, you add from your console — with no regular expression to write, by describing what it should recognize.

What Heurix doesn't do

Might as well say it plainly, it'll save you an unpleasant discovery:

• No log analysis, no observability, no generalist analytics dashboards
• No large-scale vector search
• No self-hosting: it's an API, not a cluster you operate
• Volume limits by plan, where a cluster you size yourself has no limit but your own hardware

How to decide

The question isn't "which is the better engine." Elasticsearch is more powerful, broader, and will stay that way. The question is whether you want to build and maintain your references' analysis logic, or find it already done.

If you're on the fence: the API documentation is complete, and the five-minute tutorial will tell you in ten minutes whether the engine recognizes your references. That's shorter than a first Lucene analyzer.