High-Traffic WooCommerce Scaling: Bypassing Database Session Bottlenecks

WooCommerce stores session and cart data in the wp_woocommerce_sessions table by default, and every visitor browsing the store, not just ones who’ve added something to cart, gets a session row written. On a store with real traffic, that’s a write-heavy table under constant load, which is a different problem than the read-heavy load most caching solutions are built for.

Where this actually shows up

During a traffic spike — a sale launch, a mention somewhere that sends a burst of visitors — the session table can become a genuine bottleneck even when every other part of the site is cached and fast. Full-page caching doesn’t help here because sessions are inherently per-visitor and can’t be cached across users.

Moving sessions to Redis

If you’re already running Redis for object caching, WooCommerce sessions can move there too, taking the write load off MySQL entirely:

// Requires a session handler class - several well-maintained ones exist as small plugins,
// or a custom implementation extending WC_Session_Handler
add_filter('woocommerce_session_handler', function() {
    return 'WC_Redis_Session_Handler';
});

This is genuinely worth doing before a known high-traffic event, not during one — testing a new session handler under live load during your biggest sale of the year is not the moment to discover an edge case.

Cleaning up expired sessions regularly

Even without moving sessions to Redis, making sure expired session rows are actually being cleaned up helps:

SELECT COUNT(*) FROM wp_woocommerce_sessions WHERE session_expiry < UNIX_TIMESTAMP();

WooCommerce runs its own cleanup via a scheduled event, but if that event has been failing silently (worth checking via Action Scheduler’s log), this table can grow to millions of rows on a busy store, and every session lookup gets slower as it grows.

The bigger picture

Sessions are only one piece. On genuinely high-traffic stores, the same read/write split applies to product stock updates and order creation — both need to hit the primary database directly, no caching layer available, which is why database server sizing matters more for WooCommerce than for a comparable-traffic content site.