Where Does WooCommerce Subscriptions Store Its Data?

How It Works

WooCommerce Subscriptions doesn't invent a separate storage system — it registers shop_subscription as another WooCommerce order type, reusing the same storage mechanism as regular orders. That means subscription-specific fields (billing period, next payment date, trial end date, and so on) are stored as post meta keys, the same pattern as any other WooCommerce order meta.

// Reading a subscription's next payment date directly, for reference —
// in real code, use the Subscription object's own methods instead
// (get_date( 'next_payment' )) rather than querying meta directly.
$subscription = wcs_get_subscription( $subscription_id );
echo $subscription->get_date( 'next_payment' );

Action Scheduler, which drives the actual renewal timing, keeps its own separate tables (wp_actionscheduler_actions and related) — distinct from the subscription's own order data, since scheduling and the subscription record are two different concerns.

Where This Matters in Practice

• Direct database queries against wp_posts/wp_postmeta written before a store migrates to HPOS will silently stop finding subscription data correctly, since HPOS moves it to different tables entirely.
• Custom reporting or export scripts that query the database directly, rather than going through WooCommerce's own functions and objects, are the most common thing that breaks during an HPOS migration.
• Third-party plugins that haven't been updated for HPOS compatibility can behave inconsistently on a store that's switched over, since they may still assume the legacy table structure.

Working With It Safely

1. Always use WooCommerce's own functions and objects (wcs_get_subscription(), the Subscription object's getter methods) rather than querying wp_posts/wp_postmeta directly — this keeps custom code working correctly regardless of whether the store is on legacy storage or HPOS.
2. Before migrating to HPOS, audit any custom code or plugins that query subscription data directly against the database, since those are exactly what HPOS compatibility issues affect.
3. For reporting needs, build against the REST API or WooCommerce's own query classes instead of raw SQL, for the same forward-compatibility reason.

Need custom reporting or an integration built against subscription data the right way, compatible with HPOS? See custom WooCommerce development.