Algolia runs on a Hyva storefront, but not out of the box. The backend indexing is theme-agnostic and works the same on Hyva as on Luma. What breaks is the frontend: Algolia’s official Magento 2 extension ships Luma templates that Hyva does not include, so you add a Hyva compatibility module to render autocomplete and InstantSearch.
That single distinction, backend fine, frontend needs adapting, is the thing most guides skip. This article covers how Algolia indexes a large Magento catalog, which Hyva compatibility module to pick, how Algolia’s vanilla-JavaScript search widgets coexist with Alpine.js without flickering, and when Algolia is worth paying for versus Adobe Commerce Live Search or a self-hosted OpenSearch. It is written for merchants running real catalogs on Magento and Adobe Commerce, not for a demo store.
The one thing that breaks Algolia on Hyva, and the one thing that does not
Algolia’s Magento integration has two halves. The first is a PHP layer that reads your catalog, prices, categories, and inventory, and pushes them to Algolia’s hosted index. The second is a JavaScript frontend that renders the autocomplete dropdown and the instant results page in the shopper’s browser. Only the second half is theme-specific.
Hyva deliberately removes the legacy Luma frontend stack: no RequireJS, no Knockout, no jQuery. It renders server-side HTML and hydrates with Alpine.js and Tailwind. Algolia’s official extension, algoliasearch-magento-2, was built for Luma, so its frontend templates reference modules that do not exist in a Hyva theme. Install it on Hyva unchanged and indexing runs correctly while the storefront search UI fails to render.
The practical consequence is reassuring. You are not rebuilding Algolia for Hyva. You are replacing one layer, the frontend templates, with a Hyva-native equivalent, and the indexing pipeline you configure is identical to any other Magento store. Understanding that split keeps the project scoped correctly and stops teams from assuming Algolia is incompatible with Hyva when it is not.
How Algolia indexing actually works at catalog scale
At ten thousand SKUs the indexing model barely matters. At a hundred thousand it decides whether your search stays current and whether a full reindex takes down your store. Algolia’s Magento extension does not push every catalog change to the API the moment it happens. It queues the operations and drains the queue on a schedule.
Every relevant save (a price change, a stock movement, a new product) writes a job to a database table, and a dedicated indexer processes that table in batches. The mechanics, documented in Algolia’s indexing queue guide, are worth knowing before you scale:
| Mechanism | What it does | Why it matters at scale |
|---|---|---|
| Queue table | Catalog changes are written as jobs rather than pushed instantly | Absorbs bulk updates (imports, price rules) without hammering the API |
| Queue-runner indexer | A Magento indexer drains the queue on cron, typically every 5 minutes | Keeps search current within minutes, not real time, which is the right tradeoff |
| Jobs per run | A configurable batch size processed each cron tick | Tune it so a run finishes before the next one starts, or the queue backs up |
| Temporary indices | A full reindex builds a temp index, then atomically swaps it into production | Shoppers never see a half-built index or duplicate results mid-reindex |
Two settings decide whether this is healthy. The cron must actually run on your infrastructure, and the batch size must match your server so each run completes before the next begins. A queue that grows faster than it drains means stale search results, which on a large catalog shows up as out-of-stock products still appearing and price changes lagging. The atomic temporary-index swap is the feature that lets you run a full reindex during business hours without breaking live search, and it is on by default in current versions. Getting cron health right here is the same discipline that keeps any Magento store’s indexers and queues from silently falling behind, which is core Magento operations hygiene rather than an Algolia-specific concern.
Choosing a Hyva compatibility module
Because the official extension’s frontend is Luma-first, the community and Hyva’s own team maintain compatibility modules that re-implement the search UI in Alpine and Tailwind. They are not interchangeable. They differ in which Algolia features they cover, and the wrong choice means shipping a storefront that has autocomplete but no working results page, or InstantSearch without Recommend.
The main options, all delivered as separate Composer packages on top of the official extension:
| Compatibility module | Covers | Notes |
|---|---|---|
| Official Hyva-themes Algolia module | Autocomplete and InstantSearch on Hyva | Maintained alongside the theme; requires a Hyva license |
| Blackbird hyva-algolia-search | InstantSearch, Autocomplete, Recommend, Insights, Query Rules and redirects | Broadest feature coverage; needs the external-resource-loader package and a recent Algolia extension version |
| Imagination Media InstantSearch module | The instant results page | Narrower scope; pair with another module for autocomplete |
Three things to verify before you commit. First, the module requires a current major version of the official extension (recent Hyva modules expect the newer 3.17-and-up line), so upgrade the base extension first. Second, most require a Hyva license because they ship theme source. Third, confirm the module covers the features you actually sell on: if you plan to use Algolia Recommend for related products or Query Rules for merchandised redirects, the module has to support them, and not all do. Adapting third-party modules so they coexist cleanly on a Hyva build is routine integration work, and it is the same discipline behind Bemeir’s wider technology partner ecosystem, where every add-on has to render in the theme and hold its performance budget.
InstantSearch on Alpine.js: the hydration and flicker problem
This is the part no ranking guide explains, and it is where a naive Algolia-on-Hyva build goes wrong. Algolia’s frontend widgets, InstantSearch.js and autocomplete.js, are vanilla-JavaScript libraries that manage their own DOM. They mount into an element, render results, and update the markup themselves. Hyva works differently: it renders HTML on the server, then Alpine hydrates it in the browser with x-data and x-init.
Put the two together carelessly and you get flicker. The page paints Hyva’s server-rendered markup, then Algolia’s widgets tear it down and re-render their own, producing a visible flash or a double render on the results page and on the first keystroke in the autocomplete panel. On a store that bought Hyva specifically to improve Largest Contentful Paint and interaction responsiveness, reintroducing a client-side flash is the opposite of the point.
The compatibility modules exist to reconcile this. They wrap the Algolia widget lifecycle so the vanilla-JS libraries initialise inside Hyva’s Alpine components rather than fighting them, mount into containers the theme controls, and style results with Tailwind classes from an overridable stylesheet instead of Luma CSS. When you evaluate an implementation, the search page and the autocomplete dropdown should paint once, cleanly, with no flash of a fallback layout. If they flicker, the widget lifecycle is not properly integrated with Alpine, and that is a build defect, not an Algolia limitation. Keeping client-side behaviour from undoing the theme’s speed is the entire reason a Hyva build is worth doing, and search is one of the easiest places to get it wrong.
Autocomplete at catalog scale
Autocomplete is where large catalogs earn back the cost of Algolia. Typo tolerance, instant product suggestions, and multi-section results (products, categories, pages, suggested queries) turn the search box into the primary navigation for a store with tens of thousands of SKUs. On Hyva, the autocomplete panel is rendered by the compatibility module, and its sections are configured through a theme-level configuration file plus the admin settings under the Algolia Search configuration.
At scale, three details matter more than the defaults. Keep the number of autocomplete sections disciplined, because each section is an extra query and extra render work on every keystroke. Make sure keyboard and focus behaviour work, since a search box that traps focus or ignores the arrow keys fails accessibility and frustrates power users. And test on mobile, where the panel has to coexist with the on-screen keyboard without layout jumps. These are the same interaction concerns that separate a fast Hyva storefront from a slow one, and they apply to search as much as to any other component.
Algolia vs Live Search vs OpenSearch: the honest three-way
Most comparisons stop at “Live Search is free, Algolia costs money.” The real decision has more variables, and one of them, that Adobe Commerce Live Search also needs its own Hyva compatibility work, is almost never mentioned.
| Factor | Algolia | Adobe Commerce Live Search | OpenSearch / Elasticsearch |
|---|---|---|---|
| Cost model | Paid; priced on records indexed plus search requests | Free with Adobe Commerce | Free software; you pay to host and scale it |
| Edition requirement | Any Magento or Adobe Commerce | Adobe Commerce 2.4.4+ only, not Open Source | Any Magento; required for catalog search |
| Hosting | Fully hosted SaaS | Hosted SaaS via the Commerce Services connector | Self-hosted; your infrastructure |
| Non-product content | Yes; multiple indices, federated search across CMS and external sources | Products only | Products; other content needs custom work |
| Hyva frontend | Needs a compatibility module | Also needs a Hyva-compatible storefront layer | Native Magento search results render in the theme |
| Merchandising | Rules, synonyms, Recommend, Query Rules | Managed in the Adobe admin, no code | Manual; you build ranking and synonyms |
Read this way, the choice clarifies. If you are on Magento Open Source, Live Search is off the table and the real comparison is Algolia versus a self-hosted OpenSearch you tune yourself. If you are on Adobe Commerce and search only your product catalog, Live Search is free and capable, and its Sensei ranking is a genuine reason to stay in the Adobe stack, though you still need to render it on Hyva. Algolia earns its cost when you need federated search across products and non-product content (a blog, a knowledge base, CMS pages), fine-grained ranking control, or Recommend, and when the merchandising team wants a mature rules interface. For the Adobe-native side of that decision, our guide to Live Search on a Hyva storefront covers the setup and the ranking model in depth.
On cost, model it honestly before you commit. Algolia prices on records indexed and search requests, and a detail that surprises teams is that each sort order you configure creates a replica index, which multiplies your record count. On a large catalog with several sort options, that multiplication is a real line item. Algolia’s own pricing page is the only reliable source for current per-unit rates, so budget from there rather than from a blog estimate.
A decision framework you can act on
Strip it to the questions that actually decide it:
- What edition are you on? Open Source rules out Live Search, leaving Algolia versus self-hosted OpenSearch.
- Do you need to search more than products? If yes, Algolia’s federated search is the clean answer.
- How big is the catalog and how many sort orders? Both drive Algolia’s cost through record and replica counts.
- Who runs search day to day? A merchandising team that wants a no-code rules interface is well served by either Algolia or Live Search; a lean engineering team comfortable tuning OpenSearch can keep search free.
- Are you on Hyva? Whichever you pick, budget for the frontend compatibility layer, because both Algolia and Live Search were built Luma-first.
Search is a cross-platform discipline
The principles here are not unique to Magento. The tradeoff between a hosted search SaaS and a self-managed engine, the cost multiplication of replica indices, and the need to render search cleanly in a modern frontend all recur whether you run Adobe Commerce, Shopify, BigCommerce, or Shopware. What changes per platform is how native the search primitives are and how the storefront renders results. Bemeir builds and integrates search across all of these, which is part of who we are as a full ecommerce shop rather than a single-platform vendor. If you are weighing a search change as part of a larger storefront project, start a conversation with us.
Frequently asked questions
Does the official Algolia extension work on a Hyva theme out of the box?
No. The official algoliasearch-magento-2 extension’s frontend was built for the Luma theme and depends on RequireJS and Knockout templates that Hyva does not include. Indexing and the backend work unchanged, but you need a Hyva compatibility module, such as the official Hyva-themes package or Blackbird’s module, to render autocomplete and InstantSearch on a Hyva storefront.
Is Algolia search updated in real time, or is there a delay?
It is near real time through a queue. Catalog changes are written to a database queue table and pushed to Algolia by a dedicated queue-runner indexer, typically on a five-minute cron that processes a configurable batch each run. Full reindexes build a temporary index and swap it into production atomically, so shoppers never see a half-built or duplicated index during the rebuild.
Will Algolia cause flicker on my Hyva storefront?
It can if it is integrated naively. Algolia’s InstantSearch.js and autocomplete.js manage their own DOM, while Hyva server-renders HTML and hydrates it with Alpine.js, so a careless setup can flash or double-render the results page and autocomplete panel. The Hyva compatibility modules exist to mount Algolia’s widgets inside Alpine components and style them with Tailwind, so a correct build paints once with no flash.
How does Algolia’s cost compare to Adobe’s free Live Search?
Live Search is free but requires Adobe Commerce 2.4.4 or newer and is not available on Magento Open Source. Algolia is priced on records indexed plus search requests, and costs scale with catalog size and traffic. Each configured sort order creates a replica index that adds to your record count, so confirm current per-unit rates on Algolia’s pricing page and model the replica multiplication before budgeting.
Can Algolia search my blog and CMS content, not just products?
Yes. Algolia supports multiple indices and federated search, so it can search products alongside CMS pages, a blog, or a knowledge base in one experience. Adobe Commerce Live Search indexes products only and cannot search non-Commerce sources, which is one of the main reasons merchants who need unified search across their whole site choose Algolia.
The takeaway
Algolia on Hyva is a solved problem once you understand the split: the indexing pipeline is theme-agnostic and works exactly as it does on any Magento store, while the search UI needs a Hyva compatibility module because the official extension was built for Luma. Get the indexing queue and cron healthy so search stays current at catalog scale, pick a compatibility module that covers the features you sell on, integrate the widgets with Alpine so the storefront never flickers, and choose between Algolia, Live Search, and OpenSearch on edition, content scope, and cost rather than on marketing. Done properly, search becomes the fastest path through a large catalog instead of a client-side tax on the speed you bought Hyva to gain.
