Magento AI search: scoring three stacks at 320k queries

It is a Tuesday in May. The operations lead at a Dutch homewares shop running Magento 2.4 forwards us a screenshot. Her assistant typed "cluttercore lamp" into the storefront search box and got zero results. The shop sells exactly that lamp; the SKU is tagged "vintage brass table lamp." She wants to know what a sane semantic-search upgrade looks like before Black Friday, and her board has handed her a number: under €5,000 per year, all in.

That number sounds tight until you actually price three options against 320,000 monthly queries. Then it sounds about right.

This is the method we use when an operator hands us that situation. It is not a vendor shootout. It is a scoring sheet that tries to be honest about the two costs nobody puts on the slide: per-1k-query economics at the volume you actually have, and the human cost of keeping the search relevant when your buyers start typing slang nobody on your team has heard of.

What the operator is actually asking for

"AI search" on a sub-€10M Magento storefront almost never means a chatbot. It means three smaller things:

• The catalog should find "cluttercore lamp" when the SKU is tagged "vintage brass table lamp."
• The catalog should not find a lamp when someone searches for "cluttercore bedding."
• When buyers misspell, abbreviate, or use TikTok slang, the relevant results still come up.

That is mostly vector search plus a reranker plus an actively maintained synonym list. The question is who runs which part of that stack, and what it costs you per thousand searches at the volume you actually have.

For our hypothetical shop, that volume is around 320,000 monthly searches: roughly 18% of sessions trigger search, 60,000 sessions per day in peak weeks, search-to-purchase conversion about four times the browse-to-purchase number. A small shop in absolute terms, but a real workload.

The three candidates on the table

We narrow the shortlist to three, because they cover the realistic spread.

Algolia NeuralSearch. Fully managed, vector and lexical hybrid out of the box, a dashboard your marketing lead can actually drive. NeuralSearch sits on the Grow and Premium tiers; Build does not include it. Public Algolia pricing is roughly $1 per 1,000 requests on Build, but NeuralSearch is quote-based and noticeably higher per query.

Typesense Cloud with vector mode. Also managed, priced by cluster spec rather than per query. You bring your own embeddings or use a built-in model. Open-source core, so you can self-host the same engine later without rewriting your integration. The vector search documentation is short, which is usually a good sign.

Self-hosted Meilisearch with a Qwen reranker. Meilisearch handles the lexical layer and serves vectors; an open-weights Qwen3 reranker reorders the top 50 candidates. You run both on a Hetzner box or your own Kubernetes cluster. Cheapest at this volume in cash, expensive in operator attention.

Other engines exist (Elastic, OpenSearch with the rerank pipeline, Vespa, Weaviate, Marqo). For a sub-€10M shop on Magento 2.4 we have stopped putting them on the shortlist. The integration cost dominates, and the marketing team cannot drive them.

Per-1k-query cost at 320k searches

Here is the back-of-the-envelope we share with the operator. Round numbers; treat them as ranges, not quotes.

volume:              320,000 searches / month
target SLA:          p95 under 250 ms end-to-end
retrieval budget:    € 5,000 / year, all in

Algolia NeuralSearch
  query fee:         quote-based, ~€ 0.001 to 0.003 / search
  monthly run-rate:  ~€ 320 to 960
  setup labour:      ~ 8 to 12 hours
  total year 1:      ~€ 4,500 to 12,000
  who owns slang:    marketing, in the Algolia dashboard

Typesense Cloud, 4 GB HA cluster, vector mode
  cluster:           ~€ 90 to 140 / month
  embed cost:        ~€ 20 / month at this volume with a hosted embedder
  monthly run-rate:  ~€ 110 to 160
  setup labour:      ~ 12 to 20 hours
  total year 1:      ~€ 2,500 to 4,500
  who owns slang:    you, via the synonyms API and a CSV in git

Meilisearch self-hosted + Qwen3 reranker on a CPX31
  VPS:               ~€ 15 / month
  embed + rerank:    ~€ 0 if you batch nightly on the same box
  monthly run-rate:  ~€ 15 to 30
  setup labour:      ~ 30 to 50 hours
  total year 1:      ~€ 2,800 to 4,800
  who owns slang:    you, via the settings JSON and a script

The first thing the operator usually says when she sees this is, "so Meilisearch is the cheapest." It is, in cash. It is not the cheapest in operator hours, and at 320,000 searches a month the cash difference between Typesense Cloud and self-hosted Meili is roughly two engineering days a year. That is the number that matters.

The synonym question nobody costs in

"Cluttercore" was a TikTok aesthetic before it was a search query. So was "tomato girl," "coastal grandmother," and whatever lands next quarter. None of these words exist in your product feed. None of them exist in your category tree. Vector search will get you closer than lexical search, but it will still miss when the visual aesthetic does not map cleanly to a noun your catalog already uses.

The fix is a living synonym list. The question is who keeps it alive.

Algolia

Synonyms are a first-class object in the dashboard. NeuralSearch also surfaces zero-result queries with volume, ranked. A marketing person can sit down for thirty minutes a week, look at the top twenty zero-result queries, and add cluttercore → vintage brass, eclectic, maximalist without opening a terminal. This is the single biggest reason operators keep paying Algolia at this scale.

Typesense

Synonyms are a JSON API. You can edit them via a small admin page you build inside Magento, or via a CSV in git. We have built that admin page twice now; it takes about a day. Once it exists, marketing can drive it. Without it, every synonym edit becomes a developer ticket.

Meilisearch

Same API shape as Typesense. Same trade-off. The difference is that the reranker has opinions: a Qwen3 reranker will sometimes pull the right product into the top spot without a synonym entry at all, because the embedding catches the semantic distance. It will also confidently rank a chair above a lamp when both score 0.81 and you have no idea why.

The honest version of this comparison is not "Algolia is better at AI." It is: Algolia ships you a workflow for the part that drifts. The other two ship you an API and the assumption that you will build the workflow yourself.

The scoring sheet

We score every candidate on six axes. Two-point scale per axis (1 = fine, 2 = good). The point of the scale is to force a conversation, not to be statistically meaningful.

1. Query economics at current volume. Cash run-rate, not list price.
2. Query economics at three times current volume. The Black Friday version of the same number.
3. Time to first useful result. Days from kickoff to "the cluttercore lamp shows up."
4. Who owns vocabulary drift. Marketing or engineering. Scored harder than the cash axes.
5. Lock-in. Can we walk away in a week if pricing changes?
6. Failure mode under load. What breaks first when traffic spikes five times during a TV ad.

For the Dutch homewares operator, the sheet came out roughly:

                       Algolia   Typesense   Meili+Qwen
1. economics now           1          2            2
2. economics at 3x         1          2            2
3. time to live            2          2            1
4. drift ownership         2          1            1
5. lock-in                 1          2            2
6. failure mode            2          2            1
                         -------   ---------   ----------
total                      9         11            9

Typesense wins for this operator. It would not win for a fashion retailer doing eight million monthly searches with a dedicated merchandising team; that team can drive Algolia and the per-query premium pays for itself in conversion lift. It would not win for a hobbyist project either; Meilisearch self-hosted is genuinely cheaper if your time is free.

The Magento 2.4 integration shape

None of this matters if the integration is fragile. Magento 2.4's built-in catalog search has used OpenSearch 2.x by default since 2.4.6. You have three integration shapes, in order of how often we actually ship them.

Replace the storefront search endpoint only

Keep Magento's indexer and admin search on OpenSearch. Point the storefront's quickSearch and catalogsearch controllers at your new engine via a thin module. Lowest blast radius, but you maintain two indexes.

Mirror the catalog into the new engine

This is what we usually ship. A bin/magento command does a full sync; a RabbitMQ consumer handles deltas. Product saves, stock changes, and price-rule recalculations all push. The handler at the heart of it looks like this.

// app/code/Abn/SearchSync/Observer/ProductSaveAfter.php
public function execute(Observer $observer): void
{
    $product = $observer->getEvent()->getProduct();
    if (!$product instanceof Product) {
        return;
    }
    $this->publisher->publish(
        'search.product.upsert',
        $this->serializer->serialize([
            'sku'        => $product->getSku(),
            'name'       => $product->getName(),
            'price'      => (float) $product->getFinalPrice(),
            'in_stock'   => (bool) $product->isAvailable(),
            'updated_at' => $product->getUpdatedAt(),
        ])
    );
}

Full replacement, including admin search

Almost never worth it under €10M. Magento's admin grids depend on the default search in places you will not find until they break.

One non-negotiable across all three shapes: do not let the new engine become the source of truth for stock. Magento's reservation system on 2.4 expects to own that. Index is_in_stock from Magento; do not compute it in the search layer. We learned this the second time a ghost out-of-stock product sold during a flash sale.

Where this client landed

When we built the search layer for a Dutch homewares operator on Magento 2.4 earlier this quarter, the thing we ran into was not the embedding pipeline; it was that the marketing lead refused to learn a synonyms CSV. We ended up putting Typesense behind a small in-Magento admin screen so she could add cluttercore → vintage brass, eclectic between coffee and her stand-up. That last mile is the part of the process automation work that pays for itself, every time.

What to do today

Pull your last 30 days of zero-result queries out of Magento. The query is one line:

SELECT query_text, num_results, popularity
FROM   search_query
WHERE  num_results = 0
ORDER  BY popularity DESC
LIMIT  100;

If more than 5% of the top 100 are real product intents written in slang, the problem you are about to solve is not "we need AI search." It is "we need a synonym workflow." Pick the stack that gives your marketing lead one, before you pick the stack that costs the least per thousand queries.