Search intent: informational/decisional — Magento developers and merchants choosing, configuring or migrating a search engine. We cover why the engine is mandatory, the licence split, version compatibility, configuration, reindexing, and performance tuning. It builds on our Magento 2 indexer guide and server requirements guide.

Before 2.4, Magento could fall back to MySQL for catalogue search. That option was removed: from Magento 2.4.0 the MySQL search engine was dropped entirely, and a dedicated search service became a prerequisite for installation, per the Adobe search engine prerequisites. The reason is architectural — MySQL full-text search scaled badly on large catalogues, made faceted navigation (layered navigation) expensive, and struggled with relevance, synonyms and stemming. Moving to Magento Elasticsearch shifted catalogue search, layered navigation filters and search-term relevance onto an engine built for the job. In practice this means product search, category filtering and search suggestions all traverse the search cluster rather than hammering MySQL — a significant performance gain on any catalogue beyond a few thousand SKUs.

The split happened in 2021, when Elastic relicensed Elasticsearch away from Apache 2.0 to a dual SSPL/Elastic Licence model. AWS forked the last Apache-2.0 release and created OpenSearch, which remains fully open source. Adobe followed the ecosystem: Magento Elasticsearch support continues, but OpenSearch became the default and recommended engine from Magento 2.4.6, and it is what Adobe Commerce Cloud provisions. Practically, the two are close cousins — OpenSearch forked from Elasticsearch 7.10 and retains a largely compatible query API, which is why Magento can support both through the same module layer and why swapping between them is usually a configuration change plus a reindex rather than a rewrite. The OpenSearch project site and Elastic’s Elasticsearch documentation set out each project’s current direction.

Configuration lives in Stores → Configuration → Catalog → Catalog → Catalog Search, where you pick the engine, hostname, port, index prefix and timeout — or set it from the CLI, which is what you want in a repeatable CI/CD deployment. Getting the index prefix right matters if multiple environments share a cluster: staging and production must not collide on the same prefix, or one environment’s reindex will clobber the other’s data. After any engine change, a full reindex of the catalogue search index is required — the config change alone does not populate the new cluster.

# set the engine (opensearch or elasticsearch7)
bin/magento config:set catalog/search/engine opensearch
bin/magento config:set catalog/search/opensearch_server_hostname localhost
bin/magento config:set catalog/search/opensearch_server_port 9200
bin/magento config:set catalog/search/opensearch_index_prefix prod
bin/magento config:set catalog/search/opensearch_server_timeout 15

# verify the cluster is reachable before reindexing
curl -s localhost:9200 | head

# rebuild the catalogue search index, then flush
bin/magento indexer:reindex catalogsearch_fulltext
bin/magento cache:flush

Two operational notes. First, check bin/magento indexer:status after reindexing — a search index stuck in “processing” or reporting invalid usually means the engine is unreachable or the prefix is wrong. Second, keep the search index on Update by Schedule rather than Update on Save for any store with meaningful catalogue churn, so product saves queue an incremental update instead of triggering a synchronous reindex during an admin action.

Once Magento Elasticsearch or OpenSearch is running, a handful of things drive real-world search performance. Give the cluster enough heap — the JVM heap should be roughly half of available RAM and generally not exceed ~31GB, and an undersized heap causes garbage-collection pauses that surface as slow, intermittent search. Run the engine on its own host once traffic grows, so it is not competing with PHP-FPM and MySQL for CPU. For multi-store setups, watch index count: every store view multiplies indices, and a cluster with hundreds of small indices spends more time on overhead than searching.

On the Magento side, the biggest wins are usually not engine tuning at all. Reduce the number of attributes marked searchable — every attribute with “Use in Search” enabled inflates the index and slows queries, and most catalogues have far more searchable attributes than they need. Similarly, attributes used in layered navigation should be genuinely filterable ones. Reviewing this list is often the single most effective Magento Elasticsearch optimisation available, and it costs nothing but attention. Our Magento team audits search configuration as part of performance work.