When Elasticsearch is overkill for Bitrix e-commerce

I wrote about why Elasticsearch is a UX tool, not just a speed layer. Since then, three clients have asked me the same question.

"Do we actually need Elasticsearch?"

The honest answer: often no. Here's how to decide.

Start with one number

How many active SKUs does your store have right now?

That's not a rhetorical opener. It's the first filter.

Under 3,000 SKUs — Bitrix's built-in search with proper indexing handles most stores fine. Not perfect, but good enough for conversion. On the 28k SKU project we migrated to Elasticsearch, search conversion went up 18%. On an 800-SKU store, the same move would have created infrastructure overhead with no measurable result.

3,000–10,000 SKUs — gray zone. Depends on what's actually breaking. More on that below.

Above 10,000 SKUs with active facets, synonyms, and real load — Elasticsearch is probably worth it. Though even here, the math matters.

What Bitrix search does out of the box

The built-in Bitrix search runs on MySQL LIKE and full-text indexing. That's not a failure state. With proper setup, you get:

• exact search by article number and product name — works fine
• description search — works with a FULLTEXT index
• basic relevance ranking — supported if you configure field weights in the admin panel
• fast response on small catalogs — MySQL LIKE on an indexed table answers in 10–30ms

Most stores under 3,000 SKUs haven't even implemented these basics. The problem isn't the engine. Nobody bothered to configure it.

The first step isn't "deploy Elasticsearch" — it's looking at your search logs. What are people searching for and not finding? You'll usually see that most problems are solved by fixing synonyms and field weights, not switching engines.

Where built-in search actually breaks

Three scenarios where SQL genuinely fails, regardless of configuration.

First — typos and transliteration. A user types "sumsung" instead of "samsung", or mixes keyboard layouts mid-query. MySQL LIKE can't handle that without an extra preprocessing layer. You need either Elasticsearch with fuzziness or a PHP-side query preprocessor. The PHP approach is real and works fine for smaller catalogs.

Second — morphology and synonyms. In Russian e-commerce specifically, "носки" (socks), "носков" (of socks), and "носочки" (little socks) aren't the same string. Bitrix partially handles this through a built-in morphological analyzer, but it slows down under large synonym dictionaries. Once you hit 200+ synonym pairs, MySQL starts to hurt.

Third — facets under load. 50 concurrent users, each filtering by 5 attributes. MySQL with JOINs across property tables is O(n) per facet. Above 10k SKUs this bottleneck appears sooner than most teams expect. Elasticsearch denormalizes the data and responds in 5–15ms regardless of how many facets you're stacking.

MySQL FULLTEXT as a middle ground

Between "basic LIKE" and "full Elasticsearch cluster" there's an option most teams skip over.

MySQL FULLTEXT with InnoDB is real full-text search. It supports relevance ranking, boolean mode, and stop words — no separate server, no index synchronization, running inside the same database you already have.

For Bitrix, this means switching from LIKE queries to MATCH ... AGAINST. Up to 20–30 RPS on search, it holds fine.

Limitations: no fuzzy matching, no complex synonyms, no aggregations for facets. But if you have 5,000 SKUs and no serious morphology problems — this is a legitimate intermediate step before making the Elasticsearch call.

Five signals that Elasticsearch is actually worth it

1. Search misses what's definitely in the catalog — often. Open your zero-results log. If it's above 15% of total queries, the engine isn't handling the morphology or typos.

1. Catalog above 10,000 SKUs with active facets. Faceted filter response time exceeds 300ms under real load.

1. You need business-level boosting. Want to surface high-margin products, in-stock items, or products with recent order history? MySQL can't do that. Elasticsearch function_score gets you there in half a day.

1. Autocomplete with sub-100ms latency. The search box needs to show live suggestions mid-keystroke. That's Elasticsearch Completion Suggester, not MySQL.

1. Load above 50 search RPS with complex queries. MySQL starts to slow. Elasticsearch scales horizontally.

The decision is about scale, not preference

Elasticsearch isn't "better search." It's the right tool for a specific scale of problem.

Catalog under 3,000 SKUs, simple queries, no critical typo failures: configure Bitrix's built-in search. In the 3,000–10,000 range: check your zero-results log and response times under load. If those numbers are fine, leave it alone.

When clients ask "should we add Elasticsearch?", I usually turn it around: "What's actually broken in your search right now?"

If the answer is "nothing, we just want it like Amazon" — that's not an Elasticsearch problem. That's a prioritization problem.

If the answer is "here's the log, here are the zero-results, here's the latency" — then we have a real conversation. And it often turns out the issue is a day of MySQL tuning, not a month of Elasticsearch deployment.

Search without Elasticsearch isn't a compromise. For most stores, it's the right call.