Send a brief
Menu

What is Magento OpenSearch?

Magento OpenSearch is the default search engine for Magento 2.4.6+ (and Adobe Commerce 2.4.6+), replacing Elasticsearch after Elastic relicensed under the proprietary Elastic Licence. OpenSearch is an Apache 2.0, community-driven fork of Elasticsearch 7.10 maintained by AWS. Magento uses it for catalog product search, layered navigation, auto-suggest, and synonym handling, running as a separate JVM service on port 9200.

Send a brief WhatsApp first
  • Default since Magento 2.4.6+ (Apr 2023)
  • Stack JVM · Apache 2.0 · fork of ES 7.10
  • Resource Heap 2-4 GB · port 9200

Five steps from install to live catalog search

OpenSearch is a service, not a library: Magento talks to it over HTTP. Here is exactly what that pipeline looks like end-to-end.

  1. 01Install OpenSearch as a separate service

    OpenSearch runs as its own JVM-based daemon on port 9200: separate from PHP-FPM, separate from MySQL. Install via the official APT/YUM repo (apt install opensearch) on the same box for small stores, or use AWS OpenSearch Service / Bonsai / Elastic Cloud for managed deployments. Adobe Commerce Cloud ships managed OpenSearch as part of the platform. Both OpenSearch 1.x and 2.x are officially supported by Magento 2.4.6+.

  2. 02Point Magento at the search engine via CLI

    Magento 2.4.6+ ships with opensearch as the default catalog/search/engine value on fresh installs. On upgraded stores you swap it explicitly: bin/magento config:set catalog/search/engine opensearch. From this moment Magento writes its product, category, and KQL search documents to OpenSearch rather than MySQL or Elasticsearch. The config is stored in core_config_data and respected by every store-view.

  3. 03Configure host, port, prefix, and auth

    Four settings drive the connection: catalog/search/opensearch_server_hostname (default localhost), opensearch_server_port (9200), opensearch_index_prefix (per-environment isolation so staging and prod don't collide), and opensearch_enable_auth + opensearch_username / opensearch_password for managed clusters that require basic auth. All four are stored in core_config_data and applied without a deploy.

  4. 04Reindex catalogsearch_fulltext to populate the engine

    On first connect, and after every bulk catalog change, Magento needs to write its catalog into OpenSearch indices: bin/magento indexer:reindex catalogsearch_fulltext. This creates one index per store-view named <prefix>_product_<storeId>_v1, populates it with attribute-weighted documents, and flips the alias on completion. The "blue-green" alias swap means search never goes dark mid-reindex.

  5. 05Frontend search queries hit OpenSearch directly

    On every product save, Magento writes a delta document to OpenSearch via the indexer; on every search-box keystroke and every layered-navigation click, the storefront issues an HTTP query straight to OpenSearch and renders the result via the standard Magento search controller. Synonyms, "did you mean", stopword lists, and the analyzer pipeline are all OpenSearch-side configuration. Magento itself only orchestrates indexing and query construction.

Four scenarios where OpenSearch is the right call

On Magento 2.4.6+ the choice is mostly made for you. These four scenarios make the case unambiguous.

  • New Magento 2.4.6+ installs

    OpenSearch is the default search engine on every fresh Magento 2.4.6 and later install. There is no decision to make: accept the default, point it at localhost:9200, reindex, and move on. Picking Elasticsearch 7.x on a new 2026 install is pure regret: you pay the migration cost the moment 2.4.6 reaches end-of-life or the moment your hosting provider drops Elastic Licence 2.0 packages.

  • Migrating off Elasticsearch 7.x

    Stores still on Elasticsearch 7.x (Magento 2.4.4 / 2.4.5) face two pressures: Elastic relicensed 7.11+ under the proprietary Elastic Licence 2.0 (no longer truly open-source) and Magento officially deprecated Elasticsearch support in 2.4.7. OpenSearch is a drop-in fork of ES 7.10: same query DSL, same wire protocol, same index format. Migration is a config rename + reindex, not a rewrite.

  • Catalogs with 10k+ SKUs

    Magento's MySQL fallback search is acceptable for under ~5k SKUs but degrades sharply above 10k: full-text LIKE queries on catalogsearch_fulltext_scope1 become the dominant cost on every PLP request. OpenSearch indices use inverted files, BM25 scoring, and segment merging: query times stay sub-50 ms at 100k+ SKUs on commodity hardware. Any growing catalog must move off MySQL search before it hits the wall.

  • Stores needing fuzzy, synonym, "did you mean"

    Customers mistype, use vendor-specific names, or search by attribute when you index by SKU. OpenSearch's search.search_analyzer ships with edge n-gram, fuzzy matching with configurable Levenshtein distance, stem-based synonym expansion, and a "did you mean" suggester. None of these are available on MySQL search and only the basic synonym map exists on Elasticsearch without plug-ins. If search-driven conversion is a tracked KPI, OpenSearch unlocks the easiest wins.

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 -Xmx2g minimum, 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/stats endpoint 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.

Where OpenSearch sits in the wider Magento stack

Five neighbour concepts most readers want next: caching layers, performance levers, hosting, and the developer behind the page.

Read the Redis entryRead the Varnish entry

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 bin/magento config:show catalog/search/engine, expect opensearch, set it explicitly if it still says elasticsearch7. Second, OpenSearch is unreachable on the configured host:port: curl http://localhost:9200 and check the service is running. Third, the catalogsearch_fulltext index is empty because the upgrade did not re-trigger it, run bin/magento indexer:reindex catalogsearch_fulltext and confirm via curl http://localhost:9200/_cat/indices?v that _product_1_v1 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 discovery.seed_hosts, cluster.initial_master_nodes, 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.

Send a briefWhatsApp