OpenSearch
Magento 2.4.9 accepts only OpenSearch 3, support for Elasticsearch 7.17 ended on 15 January 2026, and Shopware 6 works with either search service. For many shops the move is no longer a question but a date. Sharpness Solutions GmbH in Oldenburg, Germany, moves Magento, Adobe Commerce and Shopware shops from Elasticsearch to OpenSearch, improves result quality and runs the search service on its own servers in Germany. This page explains which version suits which shop release, how the move works without search going down, what good results depend on and what operation demands. It also says when your shop needs no search service of its own. The search index is a copy of your shop data — so the move can be planned like an update, not a migration.
Hardly any shop chooses a new search service of its own accord. Usually an update, an end of support or a complaint from sales puts the question on the table. Six starting points come up again and again. What they have in common: search only gets noticed when it does not work.
Magento 2.4.9 requires OpenSearch 3; Elasticsearch no longer appears in the system requirements. A shop running Elasticsearch 8 on 2.4.7 or 2.4.8 today has to swap the search service before or along with the update. Find that out during the update window and you no longer have an update window — you have a project.
Support for Elasticsearch 7.17 ended on 15 January 2026. Search keeps working, but bug fixes and security updates no longer arrive. Adobe recommends moving to a compatible OpenSearch version and supplies no fixes for third-party components after their end of life. The risk sits with whoever operates the shop.
Customers type part numbers with spaces, technical terms in everyday words, brand names misspelt. The result list shows accessories ahead of the main product, and an empty page when nothing matches. That is rarely a fault of the technology and almost always a matter of synonyms, weighting and data.
The more products, variants and attributes, the longer filters and listings take when the database has to compute them. A dedicated search service takes that load off — provided the index and the indexing are set up properly. An index that trails hours behind the stock levels soon shows the wrong prices.
In the catalogue, customer groups, visibility rules and customer prices apply. If the search does not know these rules, a suggestion shows a product that is blocked for this customer, or a price that does not apply to them. For a business customer, that is no cosmetic flaw.
The service was set up once and has been running ever since. Who checks whether there is enough memory, whether snapshots exist, whether the index is up to date and which version is in use? A search service without an owner only makes itself heard when it fails.
OpenSearch is a search service in its own right, created as a community fork of Elasticsearch after Elastic switched its licence from Apache 2.0 to licensing models of its own in 2021. OpenSearch is licensed entirely under Apache 2.0. Since September 2024 the project has been run by the OpenSearch Software Foundation, a project of the Linux Foundation — so its further development does not depend on a single company. Elasticsearch itself follows a different licensing model. That is not a legal assessment of your case, and for running a shop the licence is rarely what triggers the decision. The trigger is usually in the system requirements.
For Magento Open Source and Adobe Commerce, Adobe has made the decision. Version 2.4.9, released on 12 May 2026, supports only OpenSearch 3; Elasticsearch no longer appears in the requirements. 2.4.8 runs with Elasticsearch 8 or OpenSearch 3, 2.4.7 with Elasticsearch 8, OpenSearch 2.19 or 3. For 2.4.6 with current patches, Adobe lists only OpenSearch 2.19 and 3, and for 2.4.4 and 2.4.5 OpenSearch 2.19. Adobe Commerce on Cloud relies exclusively on OpenSearch. And because Magento 2.4 cannot even be installed without a search engine, this affects every shop, not just those with large ranges.
As for OpenSearch itself, 3.x is the current major version, generally available since May 2025; the latest minor release, 3.9.0, came out on 29 September 2026. The 2.x line is maintained with 2.19 until OpenSearch 4.0 is released, and 1.x has reached its end of life. Support for Elasticsearch 7.17 ended on 15 January 2026, and Adobe explicitly recommends moving to a compatible OpenSearch version. One point matters for planning: Adobe supplies no fixes for third-party components such as the search service once they have reached end of life — that is the operator’s job. Whoever runs a shop therefore has to watch the lifecycle of its search engine as closely as that of Magento.
The move starts with an inventory: Magento version and patch level, search service and version, and any extensions that talk to the search themselves. The order of steps follows from that. A shop on 2.4.7 with Elasticsearch 8 can switch to OpenSearch 3 on its current release and take the Magento updates afterwards. For 2.4.4 and 2.4.5, Adobe lists only OpenSearch 2.19; the route then leads through a Magento version that supports both OpenSearch 2.19 and 3 — that is, 2.4.6 or 2.4.7 — to the switch to OpenSearch 3, and from there on to 2.4.9. Worth knowing: 2.4.8 no longer supports OpenSearch 2.19. Get the order wrong and you pay for a second update window.
Technically, the search index is a copy of the catalogue data, not a data source of its own. So nothing is migrated during the move; the index is rebuilt. The new OpenSearch service runs alongside the old one, Magento is pointed at it, and the indexers rebuild the catalogue index. With large ranges that takes a while, and that is exactly the duration we measure in advance, on a staging system with a copy of the live data. There we check search, suggestions, filters and sorting against the previous state before the live shop switches over. Until the switch-over, the old service keeps serving your customers.
There is more to the move than configuration. Extensions that run their own search queries or extend the index are tested against the new version. Your own search settings, such as synonyms and weightings, are checked after the move against the same test searches as before. The Magento update itself is tested on the same staging system before it goes live — with the search service the live shop will actually use afterwards. The switch-over happens in the agreed maintenance window, with a backup beforehand and a way back in case something is not right. Afterwards we watch the indexers, the error logs and the searches of the first few days. A move is only finished once the list of searches without results has not grown.
In Shopware 6 a search service handles the searches explicitly marked for it — by default the product search, product listings and search suggestions in the Storefront; without a search service, search otherwise runs through the database. OpenSearch is connected through environment variables: OPENSEARCH_URL points to the service, SHOPWARE_ES_ENABLED switches on the search, SHOPWARE_ES_INDEXING_ENABLED the indexing, and SHOPWARE_ES_INDEX_PREFIX keeps the indices of different environments apart. Because search and indexing are switched separately, the new index can be built completely before the Storefront uses it. For the move, that means the new service first runs alongside the old one.
Indexing runs through console commands and the message queue. Commands such as bin/console es:index, es:reset and es:status control and check it; a full rebuild via the queue is started with dal:refresh:index --use-queue. The actual work is done by workers running bin/console messenger:consume. If no workers are running, the index is not kept up to date — the Storefront then shows no error message, just old results. So we set up the workers as permanently running services, monitor the length of the queue and measure on the staging system how long a full index takes for your catalogue.
That leaves the question of what happens when the search service does not respond. SHOPWARE_ES_THROW_EXCEPTION decides: either Shopware throws an exception, or the search falls back to the database. On the staging system we let errors show, so that they get noticed there; in the live shop the fallback is usually the better choice. The search in the Shopware Administration can also use OpenSearch, with settings of its own; whether that is worth it, we decide with you based on the volume of data. Extensions that run their own search queries are tested against the new service. A slower shop sells more than an error page.
A fast search is not yet a good one. Good results come from three things: data that can be searched, rules that reflect the language of your customers, and weighting that puts what matters at the top. Synonyms connect the technical term with everyday language, the abbreviation with the full form. Typo tolerance catches swapped letters but must not turn a part number into a similar product. Weighting decides whether a hit in the part number, in the name or somewhere in the description counts. What mapping and data quality mean for all this is described on our Elasticsearch page; the same applies to OpenSearch.
Filters and facets are the second part of search, and often the more important one. Anyone narrowing down by attributes needs those attributes as structured values, not as running text: sizes, materials, units, written consistently. Facets should show what actually occurs in the result and not offer filters that lead to zero hits. That is why we start with the real search queries from your shop: which terms are searched for, which return nothing, which return the wrong thing? Synonyms, weightings and data maintenance tasks come out of that list. A search does not become good in the configuration but on the list of searches without results.
In B2B, a third level is added: who is allowed to see what. Customer groups, range visibility and customer prices must apply in the result list, the filters and the search suggestions just as they do in the catalogue. There are two ways — rules in the index, or rules applied at query time — and both have a price: a larger index and more indexing, or more computation per query. Which route fits depends on the number of customer groups and how often prices change. This holds for any shop search, whatever service sits behind it. We know how much depends on visibility rules from B2B shops on Shopware 6 such as M&S Armaturen or Diderk Heinje Pflanzenhandel, a plant wholesaler whose prices only appear after registration. A price a customer should not see weighs more than a product they cannot find.
A search service is not a plugin you install once. It needs memory and disk space that grow with the catalogue, a version that matches the shop, and someone who keeps an eye on it. At Sharpness, OpenSearch runs on our own servers — Proxmox VE clusters in the Hetzner data centre in Falkenstein, Germany — inside the environment of the shop it belongs to. For Shopware we use it, as we do Valkey or Redis, where catalogue size and load justify it; for Magento always, because Magento cannot do without. A search service does not belong on the open internet; it is reachable only for its own shop. We run Shopware and Magento shops, and with them the services behind them.
Operation includes snapshots, monitoring and updates. Snapshots back up the indices so that, after a failure, the service does not have to wait for a full rebuild; the source remains the shop database, which is backed up with everything else. Monitoring covers the health of the service, memory, response times and the state of indexing — including whether workers and indexers are running. Updates within the OpenSearch major version are applied in the agreed maintenance windows, after a test on the staging system. An update nobody has tested is not a maintenance window but a risk.
Larger steps we plan as a project of their own: the move from OpenSearch 2 to 3, for instance, which Magento 2.4.9 requires and which the 2.x line will need at the latest when 4.0 is released. The process is the same as for the move from Elasticsearch: new service alongside, build the index, check on staging, switch over, retire the old service. After go-live we run and maintain shop and search under a service level agreement: 24, 8 or 4 hours’ response time, booked for a year; the work itself is billed by effort or within the agreed scope. Without an SLA we deal with requests within 48 hours during our business hours, Mon–Thu 9:00–16:00, Fri 9:00–13:00 (CET); on-call cover exists only with an SLA.
Process
Send us your shop system and version, your current search service and a few sentences on what bothers you about the search or which update is due. You get an initial assessment with no obligation: whether OpenSearch is necessary, in what order the move runs and what the effort depends on in your case. Phone +49 441 21 21 63 0, Mon–Thu 9:00–16:00, Fri 9:00–13:00 (CET). We work remotely across Germany, with meetings in Oldenburg and the north-west by arrangement.
You describe the situation: shop system and version, current search service, size of the range, what bothers you about the search and which deadline is pressing. We tell you whether OpenSearch is necessary, whether it pays off or whether database search is enough — with no obligation and before anyone talks about a quote.
We look into the shop release, search configuration, extensions and server environment, analyse the real search queries and measure the indexing. The result is a written findings report with the order of steps, the risks and the effort in person-days.
On a staging system with a copy of your live data we set up OpenSearch in the target version, switch over the shop and its extensions and build the index completely. In the process we measure how long a rebuild takes for your catalogue.
Synonyms, weighting, typo tolerance and filters are tuned against a list of real test searches; B2B visibility and customer prices are checked with test accounts for each customer group. You approve on the running staging system, not on screenshots.
In the agreed window the new service runs alongside the old one, the live index is built, then the shop switches over — with a backup beforehand and a way back while the old service is still in place. If a Magento update is due, it follows in the planned order.
After that we run OpenSearch on our servers in Germany, with snapshots, monitoring and updates in the maintenance windows, and maintain the shop under an SLA. In the first few days we keep a particularly close eye on searches without results.
Projects on this system
A selection — not the full client list.
Yes: according to Adobe, Magento Open Source and Adobe Commerce 2.4.9 support only OpenSearch 3, and Elasticsearch no longer appears in the system requirements. The version has been available since 12 May 2026 and has regular support until 31 May 2029. If you run Elasticsearch 8 on 2.4.7 or 2.4.8 today, the search service is switched before the update; both versions already support OpenSearch 3. Because Magento 2.4 cannot be installed without a search engine, there is no way around it. We plan the move and the update so that they do not block each other.
According to Adobe’s system requirements as of October 2026: 2.4.9 needs OpenSearch 3, 2.4.8 runs with OpenSearch 3 or Elasticsearch 8, and 2.4.7 with OpenSearch 2.19 or 3 or Elasticsearch 8. For 2.4.6 Adobe lists OpenSearch 2.19 and 3, for 2.4.4 and 2.4.5 only OpenSearch 2.19 — each with current patches. Adobe Commerce on Cloud runs exclusively with OpenSearch. A shop on 2.4.4 or 2.4.5 therefore first needs a Magento version that supports both OpenSearch lines before the search service can move to 3. Regular support for 2.4.6 ended on 11 August 2026.
Switch, and do it in a planned way: support for Elasticsearch 7.17 ended on 15 January 2026. Search keeps running, but without bug fixes or security updates. For Magento and Adobe Commerce, Adobe explicitly recommends moving to a compatible OpenSearch version and supplies no fixes for third-party components after their end of life; the risk lies with the operator. Which OpenSearch version fits depends on the Magento version, so a Magento update is often part of it. With Shopware, the change is mainly a matter of configuration and reindexing. In the inventory we establish whether everything can happen in one step or needs two.
Through environment variables and a freshly built index: OPENSEARCH_URL points to the OpenSearch service, and SHOPWARE_ES_ENABLED and SHOPWARE_ES_INDEXING_ENABLED switch on search and indexing separately. Because the two are separate, the new index can be built completely before the Storefront uses it. Indexing runs through the message queue, processed by workers with bin/console messenger:consume; bin/console es:status shows the progress. We do this first on a staging system with your data and measure how long the rebuild takes. In the live shop we then repeat exactly these steps in the maintenance window.
That is down to the configuration: SHOPWARE_ES_THROW_EXCEPTION determines whether Shopware throws an exception when the search service fails or falls back to the database search. In the live shop we usually recommend the fallback — search can do less for a while, but the shop stays usable. On the staging system we let errors show, so that they get noticed there and not by customers. In Magento 2.4 the search engine is an installation requirement, and a fallback to the database is not provided for. That makes monitoring and snapshots all the more important there.
The switch-over itself is short; the preparation sets the duration. How long the index rebuild takes depends on the number of products, variants, languages and sales channels; we measure it on the staging system rather than estimating it. On top of that come tests of extensions that run their own search queries, and a comparison of result quality with the previous state. If a Magento update is part of it, the update sets the pace, not the search service. We give a reliable schedule after the inventory, not on the phone.
No, a new search service on its own changes little about the results. Result quality comes from data, synonyms, weighting and filters, and these are carried over in the move or set up again. Combining the move with relevance work does make good use of the moment, though: the index is being rebuilt anyway, and the test searches for the comparison are already there. We start with the real search queries, above all those without results. How strongly mapping and data quality shape the result list is described on our Elasticsearch page — the same applies to OpenSearch.
Not necessarily: with a small catalogue, Shopware’s database search is enough, and in that case we say so and build the shop that way. A search service of its own costs memory, operation and attention, permanently. It pays off when range, variants and filter depth push the database to its limit, when typos and synonyms matter, or when listings become noticeably slow. Poor search is also often down to missing synonyms or unusable product names, which can be fixed without a new service. With Magento the question does not arise: a search engine is mandatory there.
Exactly as in the catalogue: a business customer may only see products and prices in the result list, filters and suggestions that apply to them. Technically there are two ways of doing this — the rules sit in the index, or they are applied at query time — and both have a price: larger indices and more indexing, or more computation per query. Which route fits depends on the number of customer groups and how often prices change. We check it with test accounts for each customer group before a customer does.
Often, but only once the cause is known. With large catalogues, slow searches and listings frequently come down to a database that has to compute filters itself, an index that lags behind, or workers that are not running. In Shopware, OpenSearch takes product search, listings and suggestions off the database. In Magento the search service is involved anyway; there we check memory, indexers and extensions. We first measure where the time is lost — in the search, in the database or in the template. A faster search service does not help if the time is lost at another point in the chain.
In most cases, yes: Magento 2.4.8 and 2.4.9 require OpenSearch 3 if the shop uses OpenSearch, and the 2.x line is only maintained, with 2.19, until OpenSearch 4.0 is released. 3.x is the current major version and has been generally available since May 2025. Moving now means moving on your own schedule rather than under deadline pressure. The process is the same as for the move from Elasticsearch: new service alongside, build the index, check on staging, switch over. For Shopware we check the target version against your shop release and your extensions beforehand.
With us, OpenSearch runs on our own servers in Germany, on Proxmox VE clusters in the Hetzner data centre in Falkenstein, with snapshots, monitoring and updates in the agreed maintenance windows. Sharpness runs and maintains shop and search under a service level agreement: 24, 8 or 4 hours’ response time, booked for a year, with the work billed by effort or within the agreed scope. Without an agreement we deal with requests within 48 hours during our business hours of Mon–Thu 9:00–16:00, Fri 9:00–13:00 (CET). The code is yours: configuration and custom code sit in your Git repository, domain and licences are registered to you; OpenSearch itself is licensed under Apache 2.0.
Enquiry
A few sentences are enough: shop system and version, current search service, what bothers you or which deadline is pressing. We come back with questions and an initial assessment — with no obligation and before anyone talks about a quote.