WooCommerce HPOS, kurz für High Performance Order Storage, verlagert Bestellungen aus den WordPress-Tabellen posts und postmeta in vier eigene Bestelltabellen. Seit WooCommerce 8.2 im Oktober 2023 ist das der Standard für neue Installationen. Ältere Shops nutzen weiter die bisherige Struktur, bis jemand bewusst umstellt. Entscheidend ist daher nicht, ob HPOS grundsätzlich sinnvoll ist. Entscheidend ist, ob dein Shop mit seinen Plugins jetzt bereit dafür ist.
WooCommerce HPOS im Vergleich zur bisherigen Postmeta-Speicherung
Animierter Vergleich der bisherigen Speicherung in posts und postmeta mit vier eigenen HPOS-Bestelltabellen
Was HPOS ist
Die Änderung betrifft die Datenstruktur, nicht das Aussehen deines Shops. Produkte, Kunden und Checkout bleiben unverändert. Nur der Speicherort für Bestelldaten ändert sich. Das berührt allerdings überraschend viel Code.
HPOS verlagert Bestelldaten aus dem überfüllten bisherigen Speicher von wp_posts und wp_postmeta in eigene Tabellen für Bestellungen, Adressen, Betriebsdaten und Bestellmetadaten.
Von Posts und Postmeta zu eigenen Bestelltabellen
Im bisherigen Modell ist eine WooCommerce-Bestellung ein WordPress-Post vom Typ shop_order. Jedes Detail dazu, etwa Rechnungsadresse, Versandart, Bestellsumme, Zahlungsmethode oder Transaktions-ID, liegt als eigene Zeile in wp_postmeta. Verbunden sind sie über die Bestell-ID.
HPOS ersetzt das durch vier spezialisierte Tabellen: wp_wc_orders für die Bestellung selbst, wp_wc_order_addresses für Rechnungs- und Lieferadressen, wp_wc_order_operational_data für operative Felder und wp_wc_orders_meta für alles Übrige. Was früher in untypisierten Metadatenzeilen lag, steht nun in echten Spalten mit passenden Indizes.
Warum WooCommerce die Änderung gemacht hat
wp_postmeta war nie als Bestelldatenbank gedacht. Die Tabelle ist ein allgemeiner Schlüssel-Wert-Speicher, den alle Post-Typen deiner Website teilen. Eine Bestellabfrage durchsucht dort also auch Seitenrevisionen, Produktattribute und Daten anderer Plugins.
Eigene Tabellen erlauben WooCommerce, die tatsächlich benötigten Felder zu indizieren. Gleichzeitig entlasten sie eine Tabelle, die WordPress an vielen anderen Stellen ständig verwendet.
Bisherige posts- und postmeta-Speicherung im Vergleich zu HPOS-Bestelltabellen
Aspekt
Bisherige posts- und postmeta-Speicherung
HPOS-Bestelltabellen
Speicherort einer Bestellung
Eine wp_posts-Zeile plus viele wp_postmeta-Zeilen
Eine wp_wc_orders-Zeile plus drei zugehörige Tabellen
Feldspeicherung
Untypisierte Meta-Keys, eine Zeile pro Feld
Typisierte Spalten mit Indizes
Geteilte Tabellen
Geteilt mit jedem Post-Typ und Plugin
Nur Bestelldaten
Eine Bestellung lesen
Mehrere Joins mit einer großen, geteilten Tabelle
Direkte Zeilenabfragen
Eigene Abfragen
meta_query gegen postmeta
wc_get_orders() und die Bestelltabellen
Standard für neue Installationen
Vor WooCommerce 8.2
WooCommerce 8.2 und neuer
Wo der Performance-Gewinn spürbar ist
Prozentangaben in Artikeln sind mit Vorsicht zu genießen. Der Gewinn hängt von Bestellzahl, Hosting, Datenbankkonfiguration und davon ab, wie viele Plugins Bestellungen ungünstig abfragen. Gut vorhersehbar ist, wo du den Unterschied merkst: in der Bestellliste im Admin, bei der Suche, bei Filtern nach Status oder Datum und in Reports. Genau dort bremste postmeta am stärksten.
Einen schnelleren Shop für Kunden solltest du allerdings nicht erwarten. Produkt- und Kategorieseiten sowie der Warenkorb greifen kaum auf Bestelldaten zu. HPOS bringt für die Ladezeit im Frontend deshalb wenig.
Fühlt sich dein Shop für Käufer langsam an, liegt die Ursache woanders. Arbeiten an der Bestelldatenbank werden das nicht lösen.
Solltest du migrieren?
Ja, irgendwann. HPOS ist der Weg, den WooCommerce einschlägt. Die bisherige Speicherung wird für die Kompatibilität gepflegt, aber nicht mehr ausgebaut. Es geht also um den richtigen Zeitpunkt.
Ab welcher Shop-Größe es sich bemerkbar macht
Ein Shop mit ein paar hundert Bestellungen merkt meist kaum etwas. Solche Abfragen sind klein, unabhängig vom Speicherort. Der Nutzen wächst mit dem Bestellvolumen und damit, wie oft dein Team in der Bestellliste arbeitet. Am deutlichsten spüren ihn Shops mit Zehntausenden Bestellungen, deren Mitarbeitende täglich filtern und suchen.
Kleine Shops haben dafür die einfachste Migration. Es gibt weniger Daten zu synchronisieren und weniger Historie zu prüfen. Klein zu sein ist ein guter Grund, die Umstellung in Ruhe anzugehen, kein Grund, sie auszulassen.
Wann Warten sinnvoll ist
Drei Situationen rechtfertigen Aufschub:
Erweiterungen ohne HPOS-Erklärung und ohne aktuelle Updates. Ein verwaistes Export- oder Fulfillment-Plugin ist ein häufiger Grund für Probleme. Auch sorgfältige Vorbereitung kann keinen Code reparieren, der direkt in postmeta schreibt.
Ein stark angepasster Checkout oder Bestellablauf. Eigene Bestellstatus, individuelle Gebührenlogik und hausgemachte Integrationen greifen alle auf die Bestellspeicherung zu. Sie können problemlos sein, brauchen aber einen Blick in den Code und echte Tests.
Keine Staging-Umgebung. Kannst du die Migration nicht mit einer Kopie der Produktionsdaten durchspielen, testest du in Produktion. Richte zuerst eine Staging-Umgebung ein. Die meisten WordPress-Wartungsdienste enthalten eine Staging-Umgebung. Falls deiner keine anbietet, solltest du das ansprechen.
Saisonale Spitzen sind kein Grund, die Migration aufzuschieben. Sie sind aber ein Grund, sie gut zu planen. Stelle die Bestellspeicherung nicht in der Woche vor deiner umsatzstärksten Phase um.
Hinweis
Warten ist eine vernünftige Entscheidung. Ohne Prüfung der Plugin-Kompatibilität zu migrieren, ist es nicht. Der Fehler zeigt sich oft nicht als kaputte Seite, sondern als unvollständige Bestelldaten, obwohl im Admin alles normal aussieht.
Zuerst die Plugin-Kompatibilität prüfen
Dieser Schritt entscheidet, ob der Rest reibungslos läuft. WooCommerce liefert dir den größten Teil der Antwort direkt mit.
Die Kompatibilitätsliste in den WooCommerce-Einstellungen
Gehe zu WooCommerce > Einstellungen > Erweitert > Funktionen. Erklärt sich ein aktives Plugin als HPOS-inkompatibel, deaktiviert WooCommerce die Option für die Bestelldatenspeicherung und zeigt eine Warnung mit dem Link Anzeigen und verwalten daneben. Der Link öffnet eine gefilterte Plugin-Liste. Du erreichst sie auch direkt:
Ersetze example.com durch deine Domain. Prüfe die Plugin-Liste Plugin für Plugin. Lies anschließend Updates und Changelog-Einträge zu HPOS oder Custom Order Tables. Viele Erweiterungen, die vor zwei Jahren noch inkompatibel waren, funktionieren heute problemlos.
Prüfung der WooCommerce-HPOS-Kompatibilität von Plugins
Was ein inkompatibles Plugin tatsächlich beschädigt
Plugins können drei Zustände haben. Der mittlere wird oft übersehen.
Die drei Kompatibilitätszustände von Plugins
Zustand
Was es bedeutet
Was WooCommerce tut
Kompatibel
Das Plugin erklärt in seiner Hauptdatei die Unterstützung für HPOS
Nichts. Die Migration bleibt freigegeben.
Inkompatibel
Das Plugin deklariert, dass es HPOS nicht unterstützt
Blockiert die HPOS-Einstellung und warnt dich
Unklar
Das Plugin erklärt weder Unterstützung noch Inkompatibilität
Blockiert nicht, wird aber als unbekannt markiert
Ein unklares Plugin ist nicht automatisch defekt. WooCommerce hat dazu schlicht keine Information. Das trifft auf viel individuellen Code und ältere Erweiterungen zu. Genau diese Fälle solltest du manuell testen.
Ist etwas wirklich inkompatibel, bleibt der Schaden oft unbemerkt. Code, der get_post_meta() mit einer Bestell-ID aufruft oder mit update_post_meta() schreibt, wirft unter HPOS keinen Fehler. Er liest nur nichts mehr und schreibt in eine Tabelle, die niemand mehr verwendet. Die Bestellung wird gespeichert und im Admin angezeigt. Doch die Versandreferenz oder das Buchungsfeld des Plugins bleibt leer. Auffallen kann das erst, wenn ein Kunde nach seinem Paket fragt.
Häufige Problemfälle
In der Praxis tauchen immer wieder dieselben Kategorien auf:
Bestellexport- und Rechnungs-Plugins, die für mehr Geschwindigkeit oft eigene SQL-Abfragen gegen postmeta bauen
Fulfillment-, Versandlabel- und Dropshipping-Integrationen die Versanddienstleisterdaten als Bestellmetadaten speichern
Buchhaltungs- und ERP-Anbindungen, besonders selbst gehostete oder von Agenturen entwickelte
Eigene Snippets in der functions.php deines Themes die Bestellungen bearbeiten und nichts erklären, weil sie keine Plugins sind
Alles, was für einen einzelnen Kunden geschrieben und nie aktualisiert wurde, unabhängig von seiner Aufgabe
Für einen Code-Check suche in Plugin- und Theme-Verzeichnissen nach get_post_meta, update_post_meta, WP_Query sowie post_type in Verbindung mit shop_order. Jeder Treffer ist ein Prüfpunkt. Bestellungen solltest du mit wc_get_order() lesen und mit wc_get_orders() abfragen. Beides funktioniert in beiden Speichermodi.
Der Migrationsprozess
Sechs Schritte in dieser Reihenfolge. Vor dem letzten kannst du jederzeit stoppen und zurückwechseln.
1Ein vollständiges Backup erstellen, einschließlich Datenbank. Kein reines Plugin-Backup und kein reines Datei-Backup. Du brauchst direkt vor der Umstellung einen vollständigen Datenbank-Dump, dessen Wiederherstellung geprüft ist. Die Migration ändert, wie Bestelldaten angesprochen werden. Ein unvollständiges Backup ist deshalb kein Rettungsweg. Nutzt dein Hoster automatische Snapshots, prüfe auch deren Aufbewahrungszeit für die Tage nach der Migration.
2Auf Staging mit einer Kopie der Produktionsdaten testen. Klone die Live-Website mit ihren echten Bestelltabellen, nicht nur einen leeren Testshop. HPOS-Probleme hängen oft an realen Bestellformen: Erstattungen, Gutscheinen, Abos, mehreren Artikeln mit unterschiedlichen Steuersätzen oder alten Importen. Eine Staging-Website mit vier Beispielbestellungen besteht jeden Test und sagt wenig aus.
3Kompatibilitätsmodus aktivieren. Auf demselben Funktionsbildschirm „Kompatibilitätsmodus aktivieren (synchronisiert Bestellungen in die Posts-Tabelle)“ ankreuzen und speichern. WooCommerce plant dann Hintergrundaufgaben, die bestehende Bestellungen in die HPOS-Tabellen übertragen. Die bisherige Speicherung bleibt dabei maßgeblich. Bei großen Shops dauert das und läuft über den Action Scheduler. Hängt dessen Verarbeitung, passiert im Hintergrund nichts.
4Integrität der Bestelldaten prüfen. Warte, bis die Synchronisation abgeschlossen ist, bevor du umstellst. Mit WP-CLI prüfst du den Status über wp wc hpos status und wp wc hpos count_unmigrated. wp wc hpos verify_data vergleicht beide Speicher, wp wc hpos diff zeigt eine einzelne abweichende Bestellung. Solange Bestellungen noch auf die Synchronisierung warten, lässt WooCommerce die maßgeblichen Tabellen nicht wechseln. Das ist eine Sicherheitsfunktion, kein Hindernis.
5Auf HPOS umschalten und den Kompatibilitätsmodus noch eine Weile nutzen. „High Performance Order Storage (empfohlen)“ wählen und speichern, den Kompatibilitätsmodus aber aktiviert lassen. Beide Speicher bleiben synchron. HPOS übernimmt Lese- und Schreibvorgänge, die bisherigen Tabellen erhalten eine Kopie. Gib dem mindestens einen vollständigen Geschäftszyklus: lang genug für eine Erstattung, einen monatlichen Export und deine Buchhaltungsroutine.
6Kompatibilitätsmodus deaktivieren. Erst wenn nichts mehr auffällt. Danach werden die bisherigen Tabellen nicht mehr aktualisiert und sind keine Option für einen Rückwechsel mehr. Die redundanten postmeta-Zeilen aufzuräumen ist eine separate spätere Entscheidung. Nutze dafür wp wc hpos cleanup erst, wenn du dir sicher bist.
Hinweis
Der Kompatibilitätsmodus ist deine Versicherung. Mit Schritt 6 kündigst du sie. Es gibt keine technische Frist zum Abschalten. Ihn einige Wochen länger zu nutzen verursacht etwas zusätzlichen Schreibaufwand, gibt dir aber einen direkten Weg zurück. Schalte ihn erst ab, wenn es einen guten Grund dafür gibt.
Hinweis
wp wc hpos cleanup löscht Bestelldaten aus den bisherigen Tabellen. Das ist nicht rückgängig zu machen, setzt HPOS als maßgeblichen Speicher und einen bereits deaktivierten Kompatibilitätsmodus voraus. Es gehört nicht zur Migration. Behandle es als separaten Wartungsschritt mit eigenem Backup.
Was nach der Migration zu testen ist
Teste zuerst auf Staging und wiederhole die Liste nach der Umstellung in Produktion. Arbeite sie im
Eine vollständige Testbestellung. Warenkorb bis Zahlung bis Bestellbestätigungsseite, über jedes aktive Gateway. Prüfe, dass die Bestellung im Admin mit korrekten Summen, Steuern, Versand und Positionen erscheint. Unser Walkthrough zum Durchführen einer vollständigen Testbestellung deckt die manuelle Version Schritt für Schritt ab.
Statuswechsel. Bewege eine Bestellung durch pending, processing, on hold, completed und cancelled. Eigene Status aus Plugins brauchen dieselbe Prüfung, denn sie werden als Bestellstatuswerte gespeichert.
Teil- und Vollerstattungen. Erstattungen sind Untereinträge einer Bestellung und deshalb ein verlässlicher Test für Speicherprobleme. Prüfe, ob die Erstattung an der Bestellung erscheint, die Summen neu berechnet werden und das Zahlungs-Gateway sie bestätigt.
Transaktionale Bestell-E-Mails. Löse Bestellbestätigung, In Bearbeitung, Abgeschlossen und Erstattungsbenachrichtigungen aus. Künftig kannst du prüfen, ob die Vorlagen die richtigen Bestelldetails enthalten und die Zustellung erfolgreich ist. Ein Template mit einem inzwischen leeren Feld fällt dabei sofort auf.
Reports und Exporte. Führe deine Analytics-Ansichten und jeden CSV- oder Buchhaltungs-Export aus, auf den du dich verlässt. Vergleiche einen Export vor der Migration mit demselben Zeitraum danach, Zeile für Zeile.
Drittanbieter-Integrationen. Das betrifft Buchhaltung, Fulfillment, CRM, ERP und Marktplatz-Synchronisierung. Schicke für jede Anbindung eine echte Testbestellung durch und prüfe, ob sie vollständig auf der anderen Seite ankommt. Ein grüner Verbindungsstatus reicht nicht.
Eigene Checkout-Felder. Jedes zusätzliche Feld im Checkout wird als Bestelldaten gespeichert. Felder aus bisherigen update_post_meta()-Aufrufen gehen dabei oft still verloren. Gib eine Bestellung mit allen ausgefüllten Feldern auf und prüfe, ob jeder Wert danach an der Bestellung sichtbar ist.
HPOS-Probleme melden sich selten lautstark. Oft fehlt einfach ein Feld bei einer bestimmten Bestellart. Bemerkt wird das erst Tage später von der Person, die es braucht.
Genau das macht die Sache in der Praxis schwierig. Eine einzelne Testbestellung am Migrationstag kann durchgehen, weil sie einfach und frisch ist. Der Fehler steckt vielleicht in einer erstatteten Bestellung eines wiederkehrenden Kunden mit Gutschein, drei Tage später.
Hier zahlt sich regelmäßiges Testen aus: ShopMonitor prüft deinen Checkout in einem echten Browser nach Zeitplan und warnt, wenn ein Schritt nicht mehr funktioniert. So bleibt ein am Dienstag defekter Pfad nicht bis Freitag unbemerkt. Künftig lassen sich auch transaktionale E-Mails auf erfolgreiche Zustellung prüfen.
Migrationen sind auch ein guter Moment, zu prüfen, was dein Wartungsvertrag wirklich abdeckt. Bestelldaten liegen genau zwischen „Plugin-Update“ und „jemand sollte das testen“.
Zurückrollen
Der Rückwechsel ist unkompliziert, wenn du ihn vorbereitet hast. Ohne Vorbereitung wird er mühsam. Entscheidend ist, ob der Kompatibilitätsmodus noch aktiv ist.
Ist der Kompatibilitätsmodus noch aktiv, enthalten die bisherigen Tabellen eine aktuelle Kopie jeder Bestellung. Dann ist der Rückwechsel nur eine Einstellungsänderung:
1Gehe zu WooCommerce > Einstellungen > Erweitert > Funktionen und prüfe, ob der Kompatibilitätsmodus noch aktiviert ist
2Warte auf die abgeschlossene Synchronisation und prüfe sie bei WP-CLI-Zugang mit wp wc hpos status
3Wähle WordPress-Posts-Speicher (Legacy) und speichere
4Optional kannst du danach den Kompatibilitätsmodus deaktivieren und erneut speichern
Bestellungen, die entstanden sind, während HPOS maßgeblich war, liegen bereits in den bisherigen Tabellen. Es geht nichts verloren.
Ohne Kompatibilitätsmodus entsteht eine Lücke. Jede Bestellung seit dem Abschalten liegt nur in den HPOS-Tabellen. Die bisherigen Tabellen sind ab diesem Zeitpunkt veraltet. Du kannst den Kompatibilitätsmodus erneut aktivieren und WooCommerce die Daten in die andere Richtung übertragen lassen. Das funktioniert meist, braucht aber Zeit und muss vor dem Wechsel mit wp wc hpos verify_data geprüft werden. Die Alternative ist das Backup aus Schritt 1. Dabei gehen alle Bestellungen seitdem verloren. Deshalb kommt Schritt 6 zuletzt und ohne Eile.
Hinweis
HPOS-Fehler hängen oft von der Bestellform ab. Eine einfache Testbestellung kann funktionieren, während erstattete, Gutschein- oder importierte Bestellungen noch Probleme machen. Prüfe mit realistischen Produktionsfällen, bevor du der Umstellung vertraust.
War die Migration nur eine von mehreren Änderungen im selben Zeitraum, isoliere sie, bevor du Schlüsse ziehst. Bestellspeicherung, Plugin-Update und Theme-Wechsel am selben Tag können dieselben Symptome erzeugen. Drehe deshalb eine Änderung nach der anderen zurück, bevor du die Migration als Ursache behandelst.
Häufig gestellte Fragen
HPOS steht für High Performance Order Storage und hieß früher Custom Order Tables. Statt jede Bestellung als shop_order-Post mit Details in vielen wp_postmeta-Zeilen zu speichern, legt WooCommerce Bestellungen in vier eigenen Tabellen ab: wp_wc_orders, wp_wc_order_addresses, wp_wc_order_operational_data und wp_wc_orders_meta. Seit WooCommerce 8.2 im Oktober 2023 ist das der Standard für neue Installationen. Bestehende Shops behalten die bisherige Speicherung, bis jemand umstellt.
Irgendwann ja, denn die bisherige Speicherung wird gepflegt, aber nicht weiterentwickelt. Migriere früher bei hohem Bestellvolumen und wenn dein Team täglich in der Bestellliste im Admin arbeitet. Dort ist der Unterschied spürbar. Warte bei Erweiterungen ohne aktuelle Updates, einem stark angepassten Bestellablauf oder einer fehlenden Staging-Umgebung. Migriere nicht direkt vor einer saisonalen Spitze.
Öffne WooCommerce > Einstellungen > Erweitert > Funktionen. Erklärt sich ein aktives Plugin als inkompatibel, deaktiviert WooCommerce die HPOS-Option und zeigt bei den betroffenen Plugins den Link Anzeigen und verwalten. Du kannst auch plugins.php?plugin_status=incompatible_with_feature&feature_id=custom_order_tables auf deiner Website aufrufen. Plugins ohne Erklärung erscheinen als unklar statt inkompatibel und blockieren den Wechsel nicht. Individueller Code und ältere Erweiterungen brauchen trotzdem manuelle Tests.
Ja, solange der Kompatibilitätsmodus noch aktiv ist. Weil beide Speicher synchron bleiben, kannst du WordPress-Posts-Speicher (Legacy) im Funktionsbildschirm wählen und nach abgeschlossener Synchronisation speichern. Ohne Kompatibilitätsmodus wird es aufwendiger: Bestellungen nach dem Abschalten liegen nur in den HPOS-Tabellen. Du musst die Synchronisierung wieder aktivieren, Daten in die andere Richtung übertragen und das Ergebnis mit wp wc hpos verify_data prüfen. Deshalb solltest du den Kompatibilitätsmodus eine Weile aktiviert lassen.
Ja, wenn der speichernde Code für die bisherige Speicherung geschrieben wurde. Ein Feld, das mit update_post_meta() für eine Bestell-ID gespeichert wird, wirft unter HPOS keinen Fehler. Es wird nur dort abgelegt, wo niemand mehr liest. Das Feld bleibt dann unbemerkt leer. Code mit $order->update_meta_data() und $order->save() funktioniert in beiden Modi. Gib zum Test eine Bestellung mit allen eigenen Feldern auf und prüfe jeden Wert an der gespeicherten Bestellung.
Kaputte Checkouts frühzeitig erkennen
ShopMonitor testet Checkouts und Formulare täglich automatisch und warnt, wenn etwas nicht funktioniert. Keine Code-Änderungen. Keine Plugins.
Verfasst vom Team von Winning Solutions, der Agentur hinter ShopMonitor. Wir helfen WooCommerce-Shops, Bestelldaten sicher zu migrieren und Checkout-Regressionen zu finden, die durch stille HPOS-Inkompatibilitäten verursacht werden können.
