OpenSearch
Magento 2.4.9 kennt nur noch OpenSearch 3, für Elasticsearch 7.17 endete der Support am 15. Januar 2026, und Shopware 6 arbeitet mit beiden Suchdiensten. Für viele Shops ist der Umstieg deshalb keine Frage mehr, sondern ein Termin. Die Sharpness Solutions GmbH aus Oldenburg stellt Magento-, Adobe-Commerce- und Shopware-Shops von Elasticsearch auf OpenSearch um, verbessert die Trefferqualität und betreibt den Suchdienst auf eigenen Servern in Deutschland. Diese Seite erklärt, welche Version zu welchem Shopstand passt, wie ein Umstieg abläuft, ohne dass die Suche ausfällt, woran gute Treffer hängen und was der Betrieb dauerhaft verlangt. Und sie sagt, wann Ihr Shop gar keinen eigenen Suchdienst braucht. Der Suchindex ist eine Kopie Ihrer Shopdaten — deshalb lässt sich der Umstieg planen wie ein Update, nicht wie eine Migration.
Kaum ein Shop entscheidet sich aus freien Stücken für einen neuen Suchdienst. Meist bringt ein Update, ein Support-Ende oder eine Beschwerde aus dem Vertrieb die Frage auf den Tisch. Sechs Ausgangslagen kehren dabei immer wieder. Gemeinsam haben sie eins: Die Suche fällt erst auf, wenn sie nicht funktioniert.
Magento 2.4.9 setzt OpenSearch 3 voraus; Elasticsearch steht nicht mehr in den Systemanforderungen. Wer heute mit Elasticsearch 8 auf 2.4.7 oder 2.4.8 läuft, muss den Suchdienst vor oder mit dem Update tauschen. Wer das erst im Update-Fenster merkt, hat kein Update-Fenster mehr, sondern ein Projekt.
Für Elasticsearch 7.17 endete der Support am 15. Januar 2026. Die Suche funktioniert weiter, Fehlerbehebungen und Sicherheitsupdates kommen aber nicht mehr. Adobe empfiehlt den Wechsel auf eine kompatible OpenSearch-Version und liefert für Drittkomponenten nach deren Lebensende keine Fixes. Das Risiko liegt beim Betreiber des Shops.
Kunden tippen Artikelnummern mit Leerzeichen, Fachbegriffe in Umgangssprache, Marken falsch geschrieben. Die Trefferliste zeigt Zubehör vor dem Hauptartikel und bei null Treffern eine leere Seite. Das ist selten ein Fehler der Technik und fast immer eine Frage von Synonymen, Gewichtung und Daten.
Je mehr Artikel, Varianten und Merkmale, desto länger brauchen Filter und Listings, wenn die Datenbank sie berechnen muss. Ein eigener Suchdienst entlastet sie — vorausgesetzt, Index und Indexierung sind sauber eingerichtet. Ein Index, der Stunden hinter dem Warenbestand herläuft, zeigt schnell die falschen Preise.
Im Katalog greifen Kundengruppen, Sichtbarkeiten und Kundenpreise. Kennt die Suche diese Regeln nicht, zeigt der Suchvorschlag einen Artikel, der für diesen Kunden gesperrt ist, oder einen Preis, der für ihn nicht gilt. Für einen Geschäftskunden ist das kein Schönheitsfehler.
Der Dienst wurde einmal eingerichtet und läuft seitdem. Wer prüft, ob der Speicher reicht, ob Snapshots existieren, ob der Index aktuell ist und welche Version im Einsatz ist? Ein Suchdienst ohne Zuständigen meldet sich erst, wenn er ausfällt.
OpenSearch ist ein eigenständiger Suchdienst, entstanden als Community-Fork von Elasticsearch, nachdem Elastic 2021 die Lizenz von Apache 2.0 auf eigene Lizenzmodelle umgestellt hatte. OpenSearch steht vollständig unter der Apache-2.0-Lizenz. Seit September 2024 trägt die OpenSearch Software Foundation das Projekt, ein Projekt der Linux Foundation — die Weiterentwicklung hängt damit nicht an einem einzelnen Unternehmen. Elasticsearch selbst folgt lizenzrechtlich einem anderen Modell. Eine juristische Bewertung für Ihren Fall ist das nicht, und für den Betrieb eines Shops ist die Lizenz selten der Auslöser. Der Auslöser steht meist in den Systemanforderungen.
Für Magento Open Source und Adobe Commerce hat Adobe die Entscheidung getroffen. Version 2.4.9, erschienen am 12. Mai 2026, unterstützt nur noch OpenSearch 3; Elasticsearch steht nicht mehr in den Anforderungen. 2.4.8 läuft mit Elasticsearch 8 oder OpenSearch 3, 2.4.7 mit Elasticsearch 8, OpenSearch 2.19 oder 3. Für 2.4.6 nennt Adobe mit aktuellen Patches nur OpenSearch 2.19 und 3, für 2.4.4 und 2.4.5 OpenSearch 2.19. Adobe Commerce on Cloud setzt ausschließlich auf OpenSearch. Und weil Magento 2.4 ohne Suchmaschine gar nicht installiert werden kann, betrifft das jeden Shop, nicht nur die mit großen Sortimenten.
Bei OpenSearch selbst ist 3.x die aktuelle Hauptversion, allgemein verfügbar seit Mai 2025; die neueste Minor-Version 3.9.0 erschien am 29. September 2026. Die Linie 2.x wird mit 2.19 gepflegt, bis OpenSearch 4.0 erscheint, 1.x hat ihr Lebensende erreicht. Für Elasticsearch 7.17 endete der Support am 15. Januar 2026, und Adobe empfiehlt ausdrücklich den Wechsel auf eine kompatible OpenSearch-Version. Wichtig für die Planung: Adobe liefert keine Fehlerbehebungen für Drittkomponenten wie den Suchdienst, sobald deren Lebensende erreicht ist — das liegt beim Betreiber. Wer einen Shop betreibt, muss also den Lebenszyklus der Suche ebenso im Blick haben wie den von Magento.
Der Umstieg beginnt mit einer Bestandsaufnahme: Magento-Version und Patchstand, Suchdienst und Version, Erweiterungen, die selbst mit der Suche sprechen. Daraus ergibt sich die Reihenfolge. Ein Shop auf 2.4.7 mit Elasticsearch 8 kann auf seinem Stand zu OpenSearch 3 wechseln und danach die Magento-Updates nehmen. Für 2.4.4 und 2.4.5 nennt Adobe nur OpenSearch 2.19; dann führt der Weg über eine Magento-Version, die OpenSearch 2.19 und 3 kennt — also 2.4.6 oder 2.4.7 —, zum Wechsel auf OpenSearch 3 und von dort weiter auf 2.4.9. Wichtig zu wissen: 2.4.8 unterstützt OpenSearch 2.19 nicht mehr. Eine falsche Reihenfolge kostet ein zweites Update-Fenster.
Technisch ist der Suchindex eine Kopie der Katalogdaten, keine eigene Datenquelle. Beim Umstieg wird deshalb nichts migriert, sondern neu aufgebaut: Der neue OpenSearch-Dienst läuft neben dem alten, Magento wird auf ihn umgestellt, die Indexer bauen den Katalogindex neu auf. Bei großen Sortimenten dauert das eine Weile, und genau diese Dauer messen wir vorher, auf einem Staging-System mit einer Kopie der Live-Daten. Dort prüfen wir Suche, Suchvorschläge, Filter und Sortierung gegen den bisherigen Stand, bevor im Live-Shop umgeschaltet wird. Bis zur Umschaltung bedient der alte Dienst Ihre Kunden weiter.
Zum Umstieg gehört mehr als die Konfiguration. Erweiterungen, die eigene Suchabfragen stellen oder den Index erweitern, testen wir gegen die neue Version. Eigene Einstellungen zur Suche, etwa Synonyme und Gewichtungen, prüfen wir nach dem Umstieg gegen dieselben Testsuchen wie vorher. Das Magento-Update selbst testen wir auf demselben Staging-System, bevor es produktiv geht — mit dem Suchdienst, den der Live-Shop danach tatsächlich nutzt. Umgeschaltet wird im vereinbarten Wartungsfenster, mit Backup davor und einem Rückweg, falls etwas nicht stimmt. Danach beobachten wir Indexer, Fehlerprotokolle und die Suchanfragen der ersten Tage. Fertig ist ein Umstieg erst, wenn die Liste der Suchen ohne Treffer nicht länger geworden ist.
In Shopware 6 übernimmt ein Suchdienst die ausdrücklich dafür markierten Suchen, standardmäßig Produktsuche, Produktlisting und Suchvorschläge in der Storefront; ohne Suchdienst läuft die Suche sonst über die Datenbank. Angebunden wird OpenSearch über Umgebungsvariablen: OPENSEARCH_URL zeigt auf den Dienst, SHOPWARE_ES_ENABLED schaltet die Suche ein, SHOPWARE_ES_INDEXING_ENABLED die Indexierung, und SHOPWARE_ES_INDEX_PREFIX hält die Indizes verschiedener Umgebungen auseinander. Weil Suche und Indexierung getrennt geschaltet werden, lässt sich der neue Index vollständig aufbauen, bevor die Storefront ihn nutzt. Für den Umstieg heißt das: Der neue Dienst läuft zuerst neben dem alten.
Die Indexierung läuft über Konsolenbefehle und die Message Queue. Befehle wie bin/console es:index, es:reset und es:status steuern und prüfen sie; einen vollständigen Neuaufbau über die Warteschlange startet dal:refresh:index --use-queue. Die eigentliche Arbeit erledigen Worker mit bin/console messenger:consume. Laufen keine Worker, wird der Index nicht aktuell gehalten — die Storefront zeigt dann keine Fehlermeldung, sondern alte Treffer. Deshalb richten wir die Worker als dauerhaft laufende Dienste ein, überwachen die Länge der Warteschlange und messen auf dem Staging-System, wie lange ein Vollindex bei Ihrem Katalog dauert.
Bleibt die Frage, was passiert, wenn der Suchdienst nicht antwortet. SHOPWARE_ES_THROW_EXCEPTION legt das fest: Entweder wirft Shopware eine Ausnahme, oder die Suche fällt auf die Datenbank zurück. Auf dem Staging-System lassen wir Fehler sichtbar werden, damit sie dort auffallen; im Live-Shop ist meist der Rückfall die bessere Wahl. Auch die Suche im Shopware-Admin kann OpenSearch nutzen, mit eigenen Einstellungen; ob sich das lohnt, entscheiden wir mit Ihnen nach Datenmenge. Erweiterungen, die eigene Suchabfragen stellen, prüfen wir gegen den neuen Dienst. Ein langsamerer Shop verkauft mehr als eine Fehlerseite.
Eine schnelle Suche ist noch keine gute. Gute Treffer entstehen aus drei Dingen: Daten, die sich durchsuchen lassen, Regeln, die die Sprache Ihrer Kunden abbilden, und einer Gewichtung, die das Wichtige nach oben stellt. Synonyme verbinden Fachbegriff und Umgangssprache, Abkürzung und ausgeschriebene Form. Tippfehlertoleranz fängt vertauschte Buchstaben ab, darf aber aus einer Artikelnummer keinen ähnlichen Artikel machen. Die Gewichtung entscheidet, ob ein Treffer in der Artikelnummer, im Namen oder irgendwo in der Beschreibung zählt. Welche Rolle Mapping und Datenqualität dabei spielen, beschreibt unsere Seite zu Elasticsearch; für OpenSearch gilt dasselbe.
Filter und Facetten sind der zweite Teil der Suche, und oft der wichtigere. Wer nach Merkmalen einschränkt, braucht diese Merkmale als strukturierte Werte, nicht als Fließtext: Größen, Werkstoffe, Einheiten, einheitlich geschrieben. Facetten sollen zeigen, was im Ergebnis tatsächlich vorkommt, und keine Filter anbieten, die zu null Treffern führen. Wir beginnen deshalb mit den echten Suchanfragen aus Ihrem Shop: Welche Begriffe werden gesucht, welche liefern nichts, welche liefern das Falsche? Aus dieser Liste entstehen Synonyme, Gewichtungen und Aufgaben für die Datenpflege. Eine Suche wird nicht in der Konfiguration gut, sondern an der Liste der Suchen ohne Treffer.
Im B2B kommt eine dritte Ebene dazu: wer was sehen darf. Kundengruppen, Sortimentssichtbarkeiten und Kundenpreise müssen in Trefferliste, Filtern und Suchvorschlägen genauso gelten wie im Katalog. Dafür gibt es zwei Wege — die Regeln stehen im Index, oder sie greifen bei der Abfrage —, und beide haben ihren Preis: mehr Indexgröße und Indexierung auf der einen, mehr Rechenarbeit je Anfrage auf der anderen Seite. Welcher Weg passt, hängt an der Zahl der Kundengruppen und daran, wie oft sich Preise ändern. Das gilt für jede Shopsuche, unabhängig vom Suchdienst dahinter. Wie viel an Sichtbarkeitsregeln hängt, kennen wir aus B2B-Shops auf Shopware 6 wie bei M&S Armaturen oder Diderk Heinje Pflanzenhandel, wo Preise erst nach Registrierung sichtbar sind. Ein Preis, den ein Kunde nicht sehen sollte, wiegt schwerer als ein Artikel, den er nicht findet.
Ein Suchdienst ist kein Plugin, das man einmal installiert. Er braucht Arbeitsspeicher und Plattenplatz, die mit dem Katalog wachsen, eine Version, die zum Shop passt, und jemanden, der ihn beobachtet. Bei Sharpness läuft OpenSearch auf eigenen Servern — Proxmox-PVE-Clustern im Hetzner-Rechenzentrum Falkenstein, Deutschland — in der Umgebung des Shops, zu dem er gehört. Bei Shopware setzen wir ihn wie Valkey beziehungsweise Redis dort ein, wo Katalog und Last es rechtfertigen, bei Magento immer, weil es ohne nicht geht. Ins offene Internet gehört ein Suchdienst nicht; erreichbar ist er nur für seinen Shop. Wir betreiben Shopware- und Magento-Shops und damit auch die Dienste dahinter.
Zum Betrieb gehören Snapshots, Monitoring und Updates. Snapshots sichern die Indizes, damit der Dienst nach einem Ausfall nicht erst auf einen vollständigen Neuaufbau warten muss; die Quelle bleibt ohnehin die Shopdatenbank, die mit den übrigen Backups gesichert wird. Das Monitoring beobachtet den Zustand des Dienstes, Speicher, Antwortzeiten und den Stand der Indexierung — also auch, ob Worker und Indexer laufen. Updates innerhalb der OpenSearch-Hauptversion spielen wir in den vereinbarten Wartungsfenstern ein, nach einem Test auf dem Staging-System. Ein Update, das niemand getestet hat, ist kein Wartungsfenster, sondern ein Risiko.
Größere Schritte planen wir als eigenes Vorhaben: den Wechsel von OpenSearch 2 auf 3 etwa, den Magento 2.4.9 verlangt und der für die Linie 2.x spätestens mit dem Erscheinen von 4.0 ansteht. Der Ablauf ist derselbe wie beim Umstieg von Elasticsearch: neuer Dienst daneben, Index aufbauen, auf Staging prüfen, umschalten, alten Dienst abbauen. Nach dem Go-live betreiben und warten wir Shop und Suche mit einer Service-Level-Vereinbarung: 24, 8 oder 4 Stunden Reaktionszeit, für ein Jahr gebucht; die Arbeit selbst rechnen wir nach Aufwand oder im vereinbarten Rahmen ab. Ohne SLA bearbeiten wir Anfragen innerhalb von 48 Stunden in unseren Geschäftszeiten Mo–Do 9:00–16:00 Uhr, Fr 9:00–13:00 Uhr; Rufbereitschaft gibt es nur mit SLA.
Ablauf
Schicken Sie uns Shopsystem und Version, den heutigen Suchdienst und ein paar Sätze dazu, was an der Suche stört oder welches Update ansteht. Sie bekommen eine erste, unverbindliche Einordnung: ob OpenSearch nötig ist, in welcher Reihenfolge der Umstieg läuft und wovon der Aufwand in Ihrem Fall abhängt. Telefon 0441 21 21 63 0, Mo–Do 9:00–16:00 Uhr, Fr 9:00–13:00 Uhr. Wir arbeiten bundesweit remote, Termine in Oldenburg und im Nordwesten nach Absprache.
Sie schildern die Lage: Shopsystem und Version, heutiger Suchdienst, Größe des Sortiments, was an der Suche stört, welcher Termin drängt. Wir sagen, ob OpenSearch nötig ist, ob es sich lohnt oder ob die Datenbanksuche genügt — unverbindlich und bevor über ein Angebot gesprochen wird.
Wir sehen in Shopstand, Suchkonfiguration, Erweiterungen und Serverumgebung, werten die echten Suchanfragen aus und messen die Indexierung. Ergebnis ist ein schriftlicher Befund mit der Reihenfolge der Schritte, den Risiken und dem Aufwand in Personentagen.
Auf einem Staging-System mit einer Kopie Ihrer Live-Daten richten wir OpenSearch in der Zielversion ein, stellen Shop und Erweiterungen um und bauen den Index vollständig auf. Dabei messen wir, wie lange der Neuaufbau bei Ihrem Katalog dauert.
Synonyme, Gewichtung, Tippfehlertoleranz und Filter stimmen wir an einer Liste echter Testsuchen ab; B2B-Sichtbarkeiten und Kundenpreise prüfen wir mit Testkonten je Kundengruppe. Sie geben am laufenden Staging-System frei, nicht anhand von Screenshots.
Im vereinbarten Fenster läuft der neue Dienst neben dem alten, der Live-Index wird aufgebaut, dann schaltet der Shop um — mit Backup davor und einem Rückweg, solange der alte Dienst noch steht. Steht ein Magento-Update an, folgt es in der geplanten Reihenfolge.
Danach betreiben wir OpenSearch auf unseren Servern in Deutschland, mit Snapshots, Monitoring und Updates in den Wartungsfenstern, und warten den Shop mit SLA. In den ersten Tagen beobachten wir die Suchen ohne Treffer besonders genau.
Projekte auf diesem System
Ein Auszug — nicht die vollständige Kundenliste.
Ja: Magento Open Source und Adobe Commerce 2.4.9 unterstützen laut Adobe nur noch OpenSearch 3, Elasticsearch steht nicht mehr in den Systemanforderungen. Die Version ist seit dem 12. Mai 2026 verfügbar und hat regulären Support bis zum 31. Mai 2029. Wer heute mit Elasticsearch 8 auf 2.4.7 oder 2.4.8 läuft, stellt den Suchdienst vor dem Update um; beide Versionen kennen OpenSearch 3 bereits. Weil Magento 2.4 ohne Suchmaschine nicht installiert werden kann, gibt es auch keinen Weg daran vorbei. Wir planen Umstieg und Update so, dass sie sich nicht gegenseitig blockieren.
Nach den Systemanforderungen von Adobe, Stand Oktober 2026: 2.4.9 braucht OpenSearch 3, 2.4.8 läuft mit OpenSearch 3 oder Elasticsearch 8, 2.4.7 mit OpenSearch 2.19 oder 3 oder Elasticsearch 8. Für 2.4.6 nennt Adobe OpenSearch 2.19 und 3, für 2.4.4 und 2.4.5 nur OpenSearch 2.19 — jeweils mit aktuellen Patches. Adobe Commerce on Cloud läuft ausschließlich mit OpenSearch. Wer auf 2.4.4 oder 2.4.5 steht, braucht also erst eine Magento-Version, die beide OpenSearch-Linien kennt, bevor der Suchdienst auf 3 wechseln kann. Für 2.4.6 endete der reguläre Support am 11. August 2026.
Umstellen, und zwar geplant: Für Elasticsearch 7.17 endete der Support am 15. Januar 2026. Die Suche läuft weiter, aber ohne Fehlerbehebungen und Sicherheitsupdates. Für Magento und Adobe Commerce empfiehlt Adobe ausdrücklich den Wechsel auf eine kompatible OpenSearch-Version und liefert für Drittkomponenten nach deren Lebensende keine Fixes; das Risiko liegt beim Betreiber. Welche OpenSearch-Version passt, hängt an der Magento-Version, deshalb gehört oft ein Magento-Update dazu. Bei Shopware ist der Wechsel vor allem eine Frage von Konfiguration und Neuindexierung. In der Bestandsaufnahme klären wir, ob alles in einem Schritt geht oder in zweien.
Über Umgebungsvariablen und einen neu aufgebauten Index: OPENSEARCH_URL zeigt auf den OpenSearch-Dienst, SHOPWARE_ES_ENABLED und SHOPWARE_ES_INDEXING_ENABLED schalten Suche und Indexierung getrennt ein. Weil beides getrennt ist, lässt sich der neue Index vollständig aufbauen, bevor die Storefront ihn nutzt. Die Indexierung läuft über die Message Queue, die Worker mit bin/console messenger:consume abarbeiten; den Stand zeigt bin/console es:status. Wir machen das zuerst auf einem Staging-System mit Ihren Daten und messen dabei, wie lange der Neuaufbau dauert. Im Live-Shop wiederholen wir genau diese Schritte im Wartungsfenster.
Das legt die Konfiguration fest: Mit SHOPWARE_ES_THROW_EXCEPTION entscheidet sich, ob Shopware bei einem Fehler des Suchdienstes eine Ausnahme wirft oder auf die Datenbanksuche zurückfällt. Im Live-Shop empfehlen wir meist den Rückfall — die Suche kann dann weniger, aber der Shop bleibt bedienbar. Auf dem Staging-System lassen wir Fehler sichtbar werden, damit sie dort auffallen und nicht erst bei Kunden. Bei Magento 2.4 ist die Suchmaschine Installationsvoraussetzung, ein Rückfall auf die Datenbank ist dort nicht vorgesehen. Umso mehr zählen dort Monitoring und Snapshots.
Die Umschaltung selbst ist kurz, die Vorbereitung bestimmt die Dauer. Wie lange der Neuaufbau des Index braucht, hängt an Artikelzahl, Varianten, Sprachen und Verkaufskanälen; wir messen das auf dem Staging-System, statt es zu schätzen. Dazu kommen der Test von Erweiterungen, die eigene Suchabfragen stellen, und der Abgleich der Trefferqualität mit dem bisherigen Stand. Gehört ein Magento-Update dazu, gibt das Update den Takt vor, nicht der Suchdienst. Einen belastbaren Zeitplan nennen wir nach der Bestandsaufnahme, nicht am Telefon.
Nein, ein neuer Suchdienst allein ändert an den Treffern wenig. Trefferqualität entsteht aus Daten, Synonymen, Gewichtung und Filtern, und die kommen beim Umstieg mit oder werden neu eingestellt. Wer den Umstieg mit Relevanzarbeit verbindet, nutzt allerdings einen guten Zeitpunkt: Der Index wird ohnehin neu aufgebaut, und die Testsuchen für den Abgleich liegen vor. Wir beginnen mit den echten Suchanfragen, vor allem mit denen ohne Treffer. Wie stark Mapping und Datenqualität die Trefferliste prägen, beschreibt unsere Seite zu Elasticsearch — für OpenSearch gilt dasselbe.
Nicht unbedingt: Bei einem kleinen Katalog genügt die Datenbanksuche von Shopware, und dann sagen wir das auch und setzen es so um. Ein eigener Suchdienst kostet Arbeitsspeicher, Betrieb und Aufmerksamkeit, und zwar dauerhaft. Er lohnt sich, wenn Sortiment, Varianten und Filtertiefe die Datenbank an ihre Grenze bringen, wenn Tippfehler und Synonyme eine Rolle spielen oder Listings spürbar langsam werden. Oft liegt eine schlechte Suche auch an fehlenden Synonymen oder unbrauchbaren Artikelnamen, und das lässt sich ohne neuen Dienst beheben. Bei Magento stellt sich die Frage nicht: Dort ist eine Suchmaschine Pflicht.
Genauso wie im Katalog: Ein Geschäftskunde darf in Trefferliste, Filter und Suchvorschlag nur Artikel und Preise sehen, die für ihn gelten. Technisch gibt es dafür zwei Wege — die Regeln stehen im Index, oder sie greifen bei der Abfrage —, und beide haben ihren Preis: größere Indizes und mehr Indexierung oder mehr Rechenarbeit je Anfrage. Welcher Weg passt, hängt an der Zahl der Kundengruppen und daran, wie oft sich Preise ändern. Wir prüfen das mit Testkonten je Kundengruppe, bevor ein Kunde es tut.
Oft, aber erst nach der Ursachensuche. Langsame Suchen und Listings haben bei großen Katalogen häufig mit einer Datenbank zu tun, die Filter selbst berechnen muss, mit einem Index, der hinterherläuft, oder mit Workern, die nicht laufen. In Shopware nimmt OpenSearch der Datenbank Produktsuche, Listings und Suchvorschläge ab. Bei Magento ist der Suchdienst ohnehin beteiligt; dort prüfen wir Speicher, Indexer und Erweiterungen. Wir messen zuerst, wo die Zeit verloren geht — in der Suche, in der Datenbank oder im Template. Ein schnellerer Suchdienst hilft nicht, wenn die Zeit an anderer Stelle verloren geht.
In den meisten Fällen ja: Magento 2.4.8 und 2.4.9 setzen OpenSearch 3 voraus, wenn der Shop OpenSearch nutzt, und die Linie 2.x wird mit 2.19 nur noch gepflegt, bis OpenSearch 4.0 erscheint. 3.x ist die aktuelle Hauptversion und seit Mai 2025 allgemein verfügbar. Wer jetzt wechselt, wechselt geplant statt unter Termindruck. Der Ablauf ist derselbe wie beim Umstieg von Elasticsearch: neuer Dienst daneben, Index aufbauen, auf Staging prüfen, umschalten. Für Shopware prüfen wir die Zielversion vorher gegen Ihren Shopstand und Ihre Erweiterungen.
OpenSearch läuft bei uns auf eigenen Servern in Deutschland, auf Proxmox-PVE-Clustern im Hetzner-Rechenzentrum Falkenstein, mit Snapshots, Monitoring und Updates in den vereinbarten Wartungsfenstern. Sharpness betreibt und wartet Shop und Suche mit einer Service-Level-Vereinbarung: 24, 8 oder 4 Stunden Reaktionszeit, für ein Jahr gebucht, die Arbeit nach Aufwand oder im vereinbarten Rahmen. Ohne Vereinbarung bearbeiten wir Anfragen innerhalb von 48 Stunden in unseren Geschäftszeiten Mo–Do 9:00–16:00 Uhr, Fr 9:00–13:00 Uhr. Der Code gehört Ihnen: Konfiguration und eigener Code liegen in Ihrem Git-Repository, Domain und Lizenzen laufen auf Sie; OpenSearch selbst ist Apache-2.0-lizenziert.
Anfrage
Ein paar Sätze genügen: Shopsystem und Version, heutiger Suchdienst, was stört oder welcher Termin drängt. Wir melden uns mit Rückfragen und einer ersten Einordnung — unverbindlich und bevor über ein Angebot gesprochen wird.