What is Magento OpenSearch ?
Magento OpenSearch is the search engine Magento 2.4 uses for catalog search, layered navigation and search suggestions. Magento 2.4 has no MySQL catalog search any more, so every store needs OpenSearch or Elasticsearch running beside it, and from Magento 2.4.6 OpenSearch has its own engine option. OpenSearch is an Apache 2.0 fork of Elasticsearch 7.10, started after Elastic changed its license in 2021 and now run under the Linux Foundation. It is a separate Java service, usually on port 9200, and Magento talks to it over HTTP.
Five steps from install to live catalog search
OpenSearch is a separate service, not a PHP library, and Magento talks to it over HTTP. This is how I set it up on a store, step by step.
-
01
Install OpenSearch as a separate service
OpenSearch runs as its own Java service, usually on port 9200, separate from PHP-FPM and MySQL. For a small store I install it on the same server from the official APT or YUM repository; for bigger stores I prefer a managed service such as Amazon OpenSearch Service. On Adobe Commerce Cloud it comes with the platform. Before installing, I check Adobe’s system requirements for the OpenSearch version that the store’s exact 2.4.x release supports.
-
02
Point Magento at the search engine via CLI
On a fresh 2.4.6 or later install you pick the engine with
--search-engine=opensearchduringbin/magento setup:install. On an upgraded store I switch it withbin/magento config:set catalog/search/engine opensearch. The value is saved incore_config_dataand applies to every store view. -
03
Configure host, port, prefix, and auth
The connection settings live under
catalog/search/:opensearch_server_hostname(defaultlocalhost),opensearch_server_port(9200),opensearch_index_prefix, and for clusters with basic auth,opensearch_enable_authwithopensearch_usernameandopensearch_password. If staging and production could ever share a cluster, I give them different index prefixes so one never overwrites the other. The Test Connection button under Stores > Configuration > Catalog > Catalog > Catalog Search confirms the settings work. -
04
Reindex catalogsearch_fulltext to populate the engine
Magento fills OpenSearch through the
catalogsearch_fulltextindexer:bin/magento indexer:reindex catalogsearch_fulltext. A full reindex builds a new index for each store view, named like<prefix>_product_<storeId>_v2, and moves the alias to it only when the build is finished. Until then search keeps using the old index, so the storefront does not lose search while a full reindex runs. -
05
Storefront searches go through Magento to OpenSearch
When a product is saved, the indexer updates that product’s document (through cron when the indexer is set to Update by Schedule). When a customer searches or clicks a layered navigation filter, Magento’s PHP code builds the query, sends it to OpenSearch and renders the results itself; the browser never talks to OpenSearch directly. Synonym groups are managed in the admin under Marketing > SEO & Search > Search Synonyms, and Magento applies them when it builds the query.
Four scenarios where OpenSearch is the right call
On Magento 2.4 you need OpenSearch or Elasticsearch either way. These are the cases where I pick OpenSearch without much debate.
-
New Magento 2.4.6+ installs
On a new 2.4.6 or later install I go with OpenSearch. It is the engine current Magento releases are built and tested around, managed hosting for it is easy to find, and the Apache 2.0 license means no licensing questions later. I install it, point Magento at it, run a full reindex and move on to the parts of the build that need attention.
-
Migrating off Elasticsearch 7.x
Stores still on Elasticsearch 7 will have to move at some point, because current Magento releases are built around OpenSearch. OpenSearch started as a fork of Elasticsearch 7.10, so the queries Magento sends work the same way. On 2.4.6 or later the switch is mostly a config change (
catalog/search/engineset toopensearch, plus host and port) and a fullcatalogsearch_fulltextreindex. I still compare search results on staging first, because relevance can shift slightly between engines. -
Large catalogs and many store views
Magento 2.4 has no MySQL search fallback, so even a small store needs a search engine. Where the OpenSearch setup really starts to matter is size: every store view gets its own index, so a large catalog across several store views means more memory, longer reindexes and more load on the cluster. On stores like that I give OpenSearch a properly sized heap and keep the indexers on Update by Schedule, so product saves do not trigger heavy reindex work during the day.
-
Stores that need better search results
Customers mistype, use their own names for products, or search by an attribute such as colour or part number. With OpenSearch behind it, Magento gives you admin-managed synonym groups, search suggestions (Stores > Configuration > Catalog > Catalog > Catalog Search) and a Search Weight setting on each product attribute. When a store needs more than that, for example better typo handling or merchandising rules, I add a search module on top of OpenSearch instead of replacing the engine.
Three OpenSearch traps that crash Magento in production
Every emergency search-down ticket I have rescued in the last two years involved one of these three mistakes. Avoid them and OpenSearch is invisible infrastructure.
-
Underprovisioning JVM heap
OpenSearch ships with a default 1 GB JVM heap. That is a development setting: on a 50k-SKU production index it triggers OutOfMemory crashes the first time a customer runs a broad layered-navigation query. Set
-Xms2g -Xmx2gminimum, 4 GB for catalogs above 100k SKUs, and never give OpenSearch more than 32 GB heap (above 32 GB the JVM loses pointer compression and performance drops). Monitor heap pressure via the_cluster/statsendpoint or Datadog. -
Co-locating OpenSearch with PHP-FPM in production
On a 16 GB single-box install, OpenSearch's 4 GB heap, MySQL's 4 GB InnoDB buffer pool, Redis's 1 GB, and PHP-FPM's pool memory all fight for the same RAM. Under traffic, the kernel swaps OpenSearch heap to disk, GC pauses go to multi-second, and every storefront search times out. Always isolate OpenSearch on its own host (or managed cluster) the moment your store exceeds 10k orders/month. Adobe Commerce Cloud isolates it by default.
-
Forgetting to reindex after schema changes
Adding a new searchable product attribute, switching an attribute's "Use in Search" flag, or changing weight requires
indexer:reindex catalogsearch_fulltext. The schema is baked into the OpenSearch index at indexing time, not query time. Skip the reindex and the frontend silently returns stale or empty results for queries against the new attribute. Always reindex after any catalog attribute change and verify with a curl against/_cat/indices?v.
Magento OpenSearch: frequently asked questions
-
OpenSearch vs Elasticsearch: what changed and when?
In January 2021, Elastic relicensed Elasticsearch 7.11+ under the proprietary Elastic Licence 2.0 + SSPL, ending its Apache 2.0 (truly open-source) status. AWS, which had been distributing Elasticsearch as a managed service, forked the last Apache-licensed version (ES 7.10) under the new name OpenSearch in April 2021. The two have since diverged: OpenSearch 2.x adds vector search, k-NN, and a fully independent dashboards UI; Elasticsearch 8.x adds proprietary AI/ML licensed features. Adobe Commerce / Magento officially switched the default to OpenSearch in version 2.4.6 (April 2023) and deprecated Elasticsearch support in 2.4.7. -
Can I still use Elasticsearch 7.x with Magento 2.4.6+?
Yes for 2.4.6 (Elasticsearch 7.17 is still officially supported alongside OpenSearch 1.x and 2.x), but the support window is closing fast: Magento 2.4.7 deprecates Elasticsearch entirely, and 2.4.8+ removes it. If your hosting provider has already dropped Elastic Licence 2.0 packages from their repos, many shared hosts have, you cannot install Elasticsearch 7.11+ anyway. The pragmatic answer in 2026: do not start any new project on Elasticsearch, and migrate existing 7.x stores to OpenSearch before your next Magento upgrade. -
How much RAM does OpenSearch need?
JVM heap rule of thumb: 2 GB minimum for catalogs under 10k SKUs, 4 GB for 10k, 100k SKUs, 8 GB for 100k, 500k SKUs, scale horizontally above that with multi-node clusters. Never give OpenSearch more than 32 GB heap on a single node, above that the JVM loses compressed object pointers and per-query performance drops. On top of heap, leave at least the same amount of OS RAM for the filesystem cache (OpenSearch leans hard on mmap-backed segment files). A 4 GB heap on a 10 GB host is correctly sized for a mid-size Magento store. -
Why are my search results empty after upgrade?
Three usual causes after a 2.4.5 → 2.4.6 upgrade. First, the search engine config did not flip, run <code>bin/magento config:show catalog/search/engine</code>, expect <code>opensearch</code>, set it explicitly if it still says <code>elasticsearch7</code>. Second, OpenSearch is unreachable on the configured host:port: curl <code>http://localhost:9200</code> and check the service is running. Third, the catalogsearch_fulltext index is empty because the upgrade did not re-trigger it, run <code>bin/magento indexer:reindex catalogsearch_fulltext</code> and confirm via <code>curl http://localhost:9200/_cat/indices?v</code> that <code><prefix>_product_1_v1</code> shows a non-zero doc count. -
Can I cluster OpenSearch for high availability?
Yes: OpenSearch supports multi-node clusters out of the box, exactly like Elasticsearch did. Standard production topology is 3 master-eligible nodes (for quorum, avoiding split-brain) plus 2+ data nodes (for replication, capacity, and query parallelism). With one primary shard and one replica per index, a single data-node failure leaves the cluster healthy and search uninterrupted. Adobe Commerce Cloud provisions this automatically. On self-hosted Magento, AWS OpenSearch Service, Bonsai, and Elastic Cloud all offer managed clusters; building your own requires careful tuning of <code>discovery.seed_hosts</code>, <code>cluster.initial_master_nodes</code>, and shard allocation. -
Does Hyvä affect search?
No. Hyvä is a frontend stack swap (Tailwind + Alpine replacing Luma's jQuery + Knockout), but the search backend, OpenSearch, is entirely server-side. Magento builds the same OpenSearch query whether the storefront is Luma or Hyvä; only the rendering of the result HTML changes. Hyvä may make the result page feel faster (smaller JS bundle, less hydration cost), but the actual ranking, relevance, and result set are identical. If you are diagnosing a slow search, the bottleneck is almost always OpenSearch heap, MySQL flat-data lookup, or PHP rendering, not the storefront theme.
Slow Magento search? Empty results after upgrade?
Send your storefront URL and a description of the symptom: I will run an OpenSearch heap, index, and query audit and reply with a written diagnosis, fix plan, and fixed-price quote. 24-business-hour turnaround.