HPOS hosting for stores whose orders outgrew the posts table.
For fifteen years a WooCommerce order was a post. High-Performance Order Storage moves it to its own tables, and the move itself is the risky part.
Moving a decade of orders.
The destination is straightforwardly better. Getting there, with a live store, is where the care goes.
A conversion that reaches the last order
Migrating years of orders out of posts and postmeta is far more work than any request allows. It runs as a resumable batch, so a store with a long history finishes rather than stalling mid-decade.
Compatibility mode watched, not assumed
During the transition WooCommerce writes to both the old and new storage. That doubles write cost and drifts if a run fails, so it is monitored rather than left on indefinitely.
Order queries that use the new indexes
The point of HPOS is that order lookups stop being meta queries. Those tables get indexes for status, customer and date, which is what admin order search actually filters on.
Extensions that have not caught up
Plugins written against the posts table break quietly under HPOS. We will check your extension list before the switch rather than after somebody cannot find an order.
A restore point before the switch
Converting order storage is not a setting you toggle back casually. A backup is taken before the run, because that is the only clean way out.
The dangerous window is the middle.
Before HPOS the store works. After HPOS the store works. The risk lives in the period where both storages exist and one of them is quietly falling behind.
- Conversion run as a resumable batch
- Dual-write mode monitored for drift
- Order tables indexed for admin queries
- Extension compatibility checked before the switch
Admin order search stops being slow.
The reason HPOS exists is that finding an order used to mean querying postmeta. The gain shows up first in the admin, where staff work all day.
What we change for HPOS
Most of this is about the migration rather than the destination, because the destination is the easy half.
| Setting | What we do | Why |
|---|---|---|
| Order conversion | Resumable batches with progress preserved | Moving years of orders out of posts and postmeta cannot complete in one pass, and a run that dies leaves the store split between two storage models. |
| Compatibility mode | Monitored for drift and time-boxed | Dual writing doubles the cost of every order and silently diverges when a sync fails, so leaving it on permanently is the worst of both designs. |
| Order table indexes | Set for status, customer and date together | Admin order search filters on exactly that combination all day, and it is the workload HPOS was introduced to fix. |
| Extension audit | Checked against the plugin list before switching | Plugins written against the posts table fail quietly under HPOS, and the failure surfaces as an order somebody cannot find rather than as an error. |
| Pre-migration backup | Taken immediately before the conversion run | Changing where orders live is not a toggle you reverse casually, and a restore point is the only clean exit if the run goes wrong. |
Simple, transparent pricing.
Every plan includes free migration, daily backups, SSL and 24/7 support.
- 1 WordPress site
- 10 GB NVMe disk
- Free SSL
- Daily backups
- One-click deployment
- Support tickets
- 5 WordPress sites
- 50 GB NVMe disk
- Free SSL
- Daily backups
- One-click deployment
- Priority support tickets
- 20 WordPress sites
- 200 GB NVMe disk
- Free SSL
- Daily backups
- One-click deployment
- Dedicated support
Questions, answered.
Is HPOS safe to enable on a large store?
Should I leave compatibility mode on?
Will my extensions still work?
What actually gets faster?
Move the orders without losing any.
Move the store across. Migration is free, conversion handled.