WooCommerce stores data in the WordPress database, combining standard WordPress tables with its own. Products are saved as a custom post type in wp_posts, with their attributes in wp_postmeta. Orders in modern installations go to dedicated wp_wc_orders tables rather than to wp_posts, which is where older stores kept them. Customer data sits in the WordPress users tables for registered accounts, or alongside the order for guest checkouts. Files, including product images, never enter the database. They live in a directory on the server.
Quick answer WooCommerce data lives in: wp_posts and wp_postmeta (products), wp_wc_orders and related tables (orders under HPOS) or wp_posts (orders under the legacy model), wp_users and wp_usermeta (registered customers), wp_options (store configuration), and /wp-content/uploads/ (files).
How is WooCommerce data structured?
WooCommerce runs on WordPress, so it uses the existing database structure and adds its own tables on top. A WordPress database consists of twelve core tables. A WooCommerce installation adds several dozen more, covering order line items, tax rates, shipping zones, download permissions, and lookup tables that speed up reporting.
The basic model looks like this:
| Data type | Storage location | Contents |
|---|---|---|
| Products | wp_posts + wp_postmeta | Name, description, price, stock, SKU |
| Orders (HPOS) | wp_wc_orders + related tables | Status, totals, addresses, metadata |
| Orders (legacy) | wp_posts + wp_postmeta | The same data, as key-value pairs |
| Order line items | wp_woocommerce_order_items + _itemmeta | Products in the order, quantities, prices |
| Registered customers | wp_users + wp_usermeta | Account data, addresses, preferences |
| Guest customers | Stored with the order | Address, email, shipping details |
| Configuration | wp_options | Store settings |
| Files | /wp-content/uploads/ | Images, downloadable products |
This design has one clear advantage and one clear limitation. Both matter before you decide how to scale a store.
The advantage is ecosystem compatibility. Because a product is a post, standard WordPress mechanisms apply: taxonomies, search, permissions, revisions. Thousands of plugins work with WooCommerce without additional development.
The limitation is the key-value structure in wp_postmeta. A table designed for blog posts ends up holding prices, stock levels and product attributes. With a large catalog and high order volume, it grows to a size where queries stop being efficient. This is a known constraint of the architecture and the starting point for most optimization work on larger stores.
Where does WooCommerce store product data?
Product data is spread across several tables, with the product itself stored as a custom post type.
wp_postsholds the product name, description, excerpt, publication status and ID. The post type isproduct, orproduct_variationfor variations.wp_postmetaholds product attributes as key-value pairs: prices, stock levels, SKUs, dimensions, visibility settings.wp_terms,wp_term_taxonomyandwp_term_relationshipshandle categories, tags and product attributes.wp_wc_product_meta_lookupis a lookup table that duplicates frequently queried product attributes in column form to speed up filtering and sorting.
Variable products work through a parent-child relationship. A shirt available in three sizes and two colors is one parent entry plus six product_variation entries linked through the post_parent column. Each variation carries its own set of metadata.
This mechanism explains why catalogs with heavy variation load the database out of proportion to the number of products a customer actually sees. A thousand products with eight variations each means nine thousand entries and tens of thousands of metadata rows.
How does WooCommerce store orders?
This requires a distinction, because the answer depends on when the store was built and whether anyone has changed its configuration since.
The current model (HPOS). High-Performance Order Storage has been the default for new installations since version 8.2, released in October 2023. Orders go into dedicated, normalized tables:
wp_wc_orders– core order data: status, currency, totals, customer IDwp_wc_order_addresses– billing and shipping addresseswp_wc_order_operational_data– operational data: payment method, shipping details, timestampswp_wc_orders_meta– order metadata, including fields added by plugins
The legacy model. An order is a wp_posts entry with post type shop_order, and all details go into wp_postmeta. This model still runs on stores built before 2023 that never migrated.
Common to both. Order line items, meaning the specific products with quantities and prices, always live in wp_woocommerce_order_items and wp_woocommerce_order_itemmeta. These tables predate HPOS and were not changed by it.
How to check which model your store uses
In the admin panel, go to WooCommerce → Settings → Advanced → Features. You will see a choice between storing orders in WooCommerce tables and storing them in WordPress posts tables. The selected option is the authoritative one.
The faster check for a technical user: look for a wp_wc_orders table in the database and see whether it holds records. The presence of the table alone proves nothing, since it may have been created during synchronization.
If your store still runs the legacy model and processes meaningful volume, migrating to HPOS is one of the better returns available on a WooCommerce database. It does require checking compatibility across every plugin and integration first. Some tools write order data directly to wp_postmeta, bypassing the WooCommerce data layer. Those integrations will stop working correctly after the switch.
Where is customer data saved?
The answer depends on whether the customer created an account.
Registered customers. Core details, meaning username, email address and registration date, go to wp_users. Extended details, meaning billing and shipping addresses and preferences, go to wp_usermeta.
Guest customers. Data is stored with the order, so in wp_wc_orders and wp_wc_order_addresses under HPOS, or in wp_postmeta under the legacy model. The email address allows the customer to track the order and receive notifications.
Regardless of the model, WooCommerce maintains a wp_wc_customer_lookup table that aggregates customer data for reports and analytics. It is not the source of truth, only a layer that speeds up queries.
This split has consequences for GDPR handling. Fulfilling a deletion request or preparing a data export means covering both locations. Plugins that handle data subject requests usually account for this, but it is worth verifying, particularly if the store has custom extensions writing customer data into non-standard fields.
Does WooCommerce store anything outside the database?
Yes. A significant part of the store lives in the server file system rather than the database.
- Product images go to
/wp-content/uploads/, organized by year and month - Downloadable product files go to a protected directory at
/wp-content/uploads/woocommerce_uploads/, secured against direct access - Exports and reports are generated as temporary files
- Plugin and theme files form a separate layer, including any custom modifications
Separating the database from the file system has practical benefits. The database stays smaller, backups can be scheduled differently for each part, and static files can be served from a CDN.
It also carries one consequence that is easy to overlook. A database backup alone will not restore a store. You will recover the structure and the content, but without product images and without the files your customers paid for.
How do you access WooCommerce database tables?
Several methods exist, and they differ in risk.
| Method | Use case | Risk | Skills required |
|---|---|---|---|
| WooCommerce API and WordPress functions | Feature development, integrations | Low | PHP, WordPress development |
| WP-CLI | Bulk operations, automation | Medium | Command line, WP-CLI |
| phpMyAdmin or Adminer | Diagnostics, inspecting data | Medium | SQL |
| Direct SQL queries | Bulk operations on large datasets | High | Advanced SQL, database architecture |
One rule applies regardless of method, and it is worth stating to anyone with access to a production database: back up before every change, and test the change on staging first.
A second rule applies specifically to orders and follows directly from HPOS. Do not access order data through post and post meta functions. Code calling get_post_meta() for orders may work in compatibility mode and break the moment that mode is turned off. The correct route is the WC_Order object and its methods. This is the single most common cause of integrations failing after an HPOS migration.
How does the data structure affect integrations?
The way orders are stored has direct consequences for integrations with external systems, and that is usually where the most fragile part of any WooCommerce implementation sits.
A typical store exchanges order data with several systems at once: multichannel sales platforms, warehouse management, ERP, accounting software, shipping carriers. Each of these reads or writes order data. Some do it through the WooCommerce API, some through their own database queries.
The distinction matters in practice. An integration built on the WooCommerce REST API or the WC_Order layer works regardless of where the data physically sits. An integration reaching directly into wp_postmeta works only under the legacy model or in compatibility mode. Once that mode is disabled, it starts returning incomplete data, often without raising any error.
Before connecting a multichannel platform such as BaseLinker, verify three things ahead of go-live rather than after the first inventory mismatch:
- Whether the integration declares HPOS compatibility. Vendors usually state this in their documentation, and WooCommerce flags incompatible plugins in the settings panel.
- How historical order syncing is handled. Importing an archive can mean processing tens of thousands of records and can load the database for hours. Schedule it outside peak hours and rehearse it on staging.
- Where custom fields are written. Tracking numbers, external system IDs and additional statuses usually go into order metadata. Under HPOS that means
wp_wc_orders_meta, notwp_postmeta. Reports and exports pointing at the old location will stop working.
What belongs in a WooCommerce backup?
A complete WooCommerce backup covers both the database and the file system. Omitting either one means the store cannot be restored.
Database tables:
- WordPress tables:
wp_posts,wp_postmeta,wp_users,wp_usermeta,wp_options,wp_terms,wp_term_taxonomy,wp_term_relationships - HPOS order tables:
wp_wc_orders,wp_wc_order_addresses,wp_wc_order_operational_data,wp_wc_orders_meta - Order line items:
wp_woocommerce_order_items,wp_woocommerce_order_itemmeta - Lookup and configuration tables:
wp_wc_customer_lookup,wp_wc_product_meta_lookup,wp_wc_order_stats,wp_wc_download_log,wp_wc_webhooks,wp_woocommerce_tax_rates,wp_woocommerce_shipping_zones
The simplest and safest rule is to back up the entire database. Selective table lists have one weakness: they miss tables added by plugins, and those are exactly the tables holding your integration data.
Server directories:
/wp-content/uploads/– product images and all media/wp-content/uploads/woocommerce_uploads/– downloadable product files/wp-content/plugins/and/wp-content/themes/– plugins, theme and custom modificationswp-config.php– database credentials and security keys
Frequency. The data structure tells you how to differentiate it. Orders and customer data change daily, so the database needs a daily backup, or more frequent at high volume. Product images change rarely, so a weekly full file backup is usually enough. That approach is cheaper and faster than backing up the entire site every day.
Restore testing. A backup you have never restored is an assumption, not a safeguard. Restore the store to a staging environment once a quarter and confirm that products display, orders are complete and customers can log in.
Where does this architecture stop being enough?
The default WooCommerce data structure serves most stores well. Past a certain scale it starts to constrain them, and it helps to recognize the point where that happens.
Signals we see in audits:
- The orders screen takes ten seconds or more to load, and filtering by status takes longer
wp_postmetaexceeds several gigabytes- Importing or updating the catalog blocks the store for the duration of the operation
- Sales reports stop generating or exceed execution time limits
- A traffic spike from a campaign ends in database errors
Directions that resolve it:
- Migrate to HPOS if the store still runs the legacy model. This is usually the first step and often sufficient on its own.
- Custom tables for high-write data, such as stock levels synchronized with an external system every few minutes.
- Object caching with Redis to take repeated queries off the database.
- Indexes matched to the store’s actual queries rather than to the default configuration.
- Headless or hybrid architecture for catalogs above a hundred thousand items, where the presentation layer stops being the bottleneck and database querying becomes one. A dedicated search layer is often part of that infrastructure shift — see how the leading WooCommerce search plugins perform at 180,000 products.
None of these is universal. The right choice depends on what the actual bottleneck is, and that can only be established by measurement, not assumption.
Key takeaways
- WooCommerce combines WordPress tables with its own. Products are a custom post type. Orders in modern installations have dedicated tables.
- HPOS has been the default since October 2023. Before working with order data, confirm which model your store runs.
- Access orders through the
WC_Orderlayer, not through post meta functions. This is the most common cause of integrations breaking. That’s exactly the pattern to follow when building a custom API endpoint in WooCommerce. - Files live outside the database. A database backup alone will not restore a store.
- The default structure works to a point. Beyond it, the answer is architectural decisions rather than more optimization plugins.
FAQ: WooCommerce data storage
Does WooCommerce store data in MySQL?
Yes. WooCommerce uses the same MySQL or MariaDB database as WordPress, drawing on both WordPress tables and its own tables added by the plugin.
Where exactly are WooCommerce orders stored?
In installations running HPOS, in wp_wc_orders, wp_wc_order_addresses, wp_wc_order_operational_data and wp_wc_orders_meta. In stores on the legacy model, in wp_posts as post type shop_order plus wp_postmeta. Order line items sit in wp_woocommerce_order_items and wp_woocommerce_order_itemmeta under both models.
Do I have to migrate my store to HPOS?
There is no obligation, but the direction of WooCommerce development is clear. Migration makes most sense at high order volume and where the admin panel has become noticeably slow. It requires checking compatibility across every plugin and integration first.
Can WooCommerce handle a large database?
Yes, with the right preparation. Stores with hundreds of thousands of products and high order volume run on this platform, but they need optimization: HPOS, object caching, appropriate indexes, and sometimes custom tables for specific data types.
Where does WooCommerce keep product images?
In /wp-content/uploads/ on the server, organized by year and month. The database holds only the file reference and its metadata.
How do I check the size of WooCommerce tables?
Through phpMyAdmin, in the table list view with the size column, or with the WP-CLI command wp db size --tables. The tables worth looking at first are wp_postmeta, wp_options, and wp_actionscheduler_actions and wp_actionscheduler_logs, which can grow without bound on high-traffic stores.
