TL;DR:
HPOS moves WooCommerce order data into four dedicated tables, making order creation roughly 5x faster and customer filtering up to 40x faster on stores with real order volume. It covers order-related database work only. If your Orders screen crawls while your storefront behaves, enable HPOS and leave compatibility mode on until testing passes. If the storefront is the slow part, that’s a frontend job with frontend tools.
You’re trying to work, but your Orders screen crawls when you filter by customer, bulk actions spin, and order reports time out. Meanwhile, shoppers move through your storefront at a normal pace and buy without noticing a thing.
The fact that it’s not slow all around is your clue to the root issue: how WooCommerce stores and queries your orders. Thankfully, there’s a built-in feature designed to address that.
High-Performance Order Storage (HPOS) is a WooCommerce feature that moves order data out of the shared wp_posts and wp_postmeta tables into four dedicated database tables designed for order queries.
Its purpose is specific: order-related database work. General wp-admin sluggishness and storefront loading speed are separate problems with separate fixes. If you want to understand the difference between the three, you need to investigate why your orders slowed down in the first place.
Test Nitropack yourself
By submitting, you agree to our Privacy Policy.
Why did your order operations get slow?
Before HPOS, WooCommerce stored every order as a custom post type, dropped into wp_posts alongside your blog posts, pages, and media attachments. Every detail attached to that order went into wp_postmeta as its own row: billing address, shipping address, payment method, customer email, order totals, and dozens more. Placing one order meant a single insert into wp_posts plus almost 40 inserts into wp_postmeta.
Those writes make checkout expensive, but the act of reading them is what makes the Orders screen slow.
Customer ID, billing email, address fields, order totals: the exact things you filter and sort by lived in wp_postmeta as generic key-value rows. Retrieving them means joining two of the largest tables in your database, which gets significantly harder as your order history and catalog grow and as every plugin that touches orders adds meta rows of its own.
This was a reasonable design. wp_posts was built for blog posts, and it does that job well. Orders are transactional data with a different shape and a different query pattern, which is the whole argument for giving them tables of their own—so it’s worth looking at what those tables actually change.
What HPOS changes in your database
HPOS gives orders four tables of their own:
- wp_wc_orders: Core order data (status, customer ID, totals, payment method) in dedicated, indexed columns.
- wp_wc_order_addresses: Billing and shipping addresses.
- wp_wc_order_operational_data: Internal state WooCommerce tracks as an order progresses: cart hash, order key, paid and completed dates, shipping and discount totals.
- wp_wc_orders_meta: Everything without a dedicated HPOS column, which in practice means most custom fields your extensions write.
The write cost falls with it. A single order now takes at most five inserts, down from roughly 41 across two tables shared with the rest of your site. Reads change character too: filtering by customer becomes a lookup on an indexed column.
WooCommerce benchmarked the difference, operation by operation, under the following test conditions: a test database of roughly 400,000 orders and 30,000 products, with HPOS-to-posts synchronization switched off.
| Operation | Legacy posts storage | HPOS | Difference |
| Creating 1,000 orders | 78.12s | 15.18s | ~5x faster |
| 10 checkouts | 1.51s | 0.99s | ~1.5x faster |
| Filtering orders by customer | 0.599s | 0.016s | ~40x faster |
| Searching orders by metadata | 0.639s | 0.053s | ~10x faster |
Keep in mind that these are synthetic, isolated measurements, and the gains scale with your order history. At 500 orders, the difference is academic. At 400,000, it decides whether your Orders screen is usable.
HPOS has been the default for new installs since WooCommerce 8.2 (October 2023), and established stores stay on legacy storage until someone switches them over. Whether switching helps you comes down to which of your slowdowns HPOS actually touches.
What HPOS fixes, and what it doesn’t
What HPOS fixes
Everything here is order-related database work:
- The Orders screen: Filtering, searching, sorting, and pagination all hit the new indexed columns.
- Order creation, loading, and update: Fewer writes per order, which matters most when volume spikes—Black Friday, a flash sale, a newsletter that lands better than expected.
- Checkout and bulk order actions, especially on stores carrying years of order history.
- Reports and integrations that read orders directly, since they query real columns.
What HPOS doesn’t fix
First is general wp-admin slowness. When wp-admin drags on pages that have nothing to do with orders, the cause lies elsewhere. The usual suspects:
- A plugin running slow queries, external API calls, or unnecessary work on the page you’re loading. Measure what your plugins actually do—plugin count on its own tells you nothing.
- A bloated wp_options table carrying expired transients and autoloaded data.
- A PHP version that’s fallen out of active support; 8.3 or newer keeps you current.
- A missing object caching layer, whether Redis or Memcached.
- Shared hosting where MySQL is starved of resources.
This is why you need to diagnose before you change anything. Check server monitoring, PHP errors, slow queries, external calls, scheduled actions, autoloaded options, and resource limits, then fix the bottleneck you measured—with a current backup in place. Where hosting is the constraint, managed WooCommerce hosting with dedicated database resources and server-level caching addresses that piece.
The other thing HPOS doesn’t fix is your storefront. Image delivery, CSS, JavaScript, and ordinary product and category queries sit outside HPOS entirely. Checkout and account pages are the only small exception because they do real backend work, so faster server processing can improve their loading metrics, where backend latency is genuinely part of the problem. However, past that, storefront speed is its own problem with its own tools—page caching, a CDN, image optimization, and JavaScript deferral.
It’s also where most stores are struggling. 39% of WooCommerce origins pass Core Web Vitals as of June 2026, and that figure measures the frontend, so an HPOS migration leaves it exactly where it was. That layer needs tooling of its own: an all-in-one frontend optimization service like NitroPack for WooCommerce handles caching, CDN delivery, image optimization, and JavaScript execution in one place, and our WooCommerce speed guide walks the manual route in priority order.
Match the fix to the symptom. A slow Orders screen with a healthy storefront points at HPOS. Slowness across all of wp-admin points to hosting, PHP, or a plugin. A slow storefront points to frontend delivery.
Once you know HPOS is the right fix for what you’re seeing, switching it on takes about a minute.
How to enable HPOS on your store
Four steps, and the toggle works in both directions—take a database backup first anyway.
- Open WooCommerce > Settings > Advanced > Features, and under Order data storage, select High-performance order storage (recommended).
- Leave Enable compatibility mode (synchronizes orders to the posts table) checked.
- Save changes.
Your existing orders stay in the legacy tables while WooCommerce copies them across. That work runs in the background through scheduled actions, 25 orders at a time, and your store keeps taking orders throughout. How long it runs depends entirely on volume: WooCommerce’s large-store guide clocks a 9-million-order test store at about a week.
Waiting on the scheduler is optional. wp wc hpos sync runs the migration immediately, which is what WooCommerce recommends for large stores because it makes the duration predictable, and wp wc hpos count_unmigrated gives you a live count of what’s still pending.
Turning HPOS off later happens on the same screen: select WordPress posts storage (legacy) and save, but you do need to make sure to do that safely. We’ll explain what that means in a little bit.
When the HPOS toggle is grayed out
If the setting is right there but completely unclickable, that means that an active plugin has explicitly declared itself incompatible with the custom order tables feature, and the toggle stays locked until that clears.
Find the plugins responsible on your own site:
/wp-admin/plugins.php?plugin_status=incompatible_with_feature&feature_id=custom_order_tablesRead “incompatible” precisely: The plugin’s author declared it, which is a different claim from WooCommerce testing your store and finding a fault. Plugins that have declared nothing either way leave the toggle available, with a warning on the Plugins screen.
If that is the case, you can either wait for the developer to ship an HPOS-compatible update, swap the plugin for a compatible alternative, or stay on legacy storage until the blocker resolves.
If the blocker is code you own—a custom snippet, or a plugin a developer built for you—it takes three steps to clear:
- Change how the code reads order data. Replace get_post_meta() and update_post_meta() with wc_get_order() and the order object’s own meta methods. Once HPOS is authoritative, the old post APIs can hand back a legacy copy that’s out of date.
- Test it on a staging copy with HPOS enabled. Place an order, edit it, refund it—whatever that code touches.
- Declare the code compatible using FeaturesUtil::declare_compatibility() on the before_woocommerce_init hook. That’s what unlocks the toggle.
Important! Fixing the code doesn’t lift the block on its own; the declaration does. You also need to make sure that the staging copy has HPOS enabled; otherwise, there’s no point.
What compatibility mode actually does
Compatibility mode keeps a copy of your order data in the old wp_posts and wp_postmeta tables, updated from HPOS every time an order changes. Anything on your site that still reads orders the old way carries on working.
That copy costs you the speed you came for. WooCommerce ran those benchmark figures with compatibility mode switched off, so while it’s on, your store does the new work and the old work on every order.
Leave it on to start with. Then check that every plugin, custom snippet, and external integration handles orders correctly—on a staging copy first, then on the live store.
Turn it off once those checks pass. WooCommerce stops writing the legacy copy, and you get the performance the benchmarks describe.
To go back to legacy storage, do it while compatibility mode is still on and both sets of tables agree:
- Run wp wc hpos status and confirm no orders are waiting to sync.
- Run wp wc hpos verify_data if you want the two datastores compared directly.
- Take a database backup.
- Select WordPress posts storage (legacy) and save.
Fix the other half of WooCommerce speed
WooCommerce speed splits into three layers, and seeing them side by side shows which tool belongs where:
| Layer | What it covers | What handles it |
| Backend order operations | Order creation, Orders screen queries, bulk actions | HPOS |
| General admin performance | wp-admin responsiveness outside orders | Hosting, PHP version, object caching, plugin hygiene |
| Storefront delivery | What visitors load: pages, images, CSS, JavaScript | Page caching, CDN, image optimization, JavaScript deferral |
HPOS owns the first row outright and stops at that boundary. The second comes down to your hosting and configuration choices. The third is the layer your customers actually experience, and the one most stores leave unattended.
NitroPack for WooCommerce works on that third row. It brings page caching, a built-in CDN powered by Cloudflare, image optimization, and JavaScript deferral into one subscription, with the processing running on our cloud infrastructure so that work stays off your server. Cart Cache, on Plus plans and above, keeps cached delivery in place while a shopper has items in their cart.
The division of labor, plainly: we speed up what a visitor’s browser downloads and renders; HPOS speeds up order creation, admin queries, and database writes. A store slow in both places needs both. To see where your storefront stands before spending anything, our free plan takes no credit card.
FAQ
Will HPOS make my storefront faster?
On its own, no. HPOS changes how order data is stored and queried, which your customers never touch directly. Storefront speed comes from caching, a CDN, image optimization, and JavaScript handling.
Do I need HPOS if my store has fewer than 100 orders?
You won’t feel much. The gains scale with order history, so a small store sees little difference either way. Enabling it still keeps you aligned with the storage model every new WooCommerce install has used since 8.2.
What happens to my postmeta data when compatibility mode is off?
WooCommerce stops maintaining the legacy copy, and the rows already written stay in place until you remove them—wp wc hpos cleanup clears legacy data for migrated orders. A lightweight placeholder row per order remains in wp_posts either way, which preserves order IDs and keeps comment-based order notes working.
Will HPOS break custom code that uses get_post_meta() for order data?
It can. Once HPOS is authoritative, the post APIs may read a legacy copy that’s out of date. Move that code to wc_get_order() and the order object’s own meta methods.
