How to Fix Medusa v2 Checkout Performance with 1000+ Variants

The performance cliff is not linear — it is quadratic. Doubling your variant count does not double your response time; it quadruples it. A store with 1000 variants might be tolerable at 800ms. At 5000 variants, the same query takes 8+ seconds because the pricing module joins every variant against every price set without a covering index. I am Manoj, commerce and ERP implementation lead at Mith Tech in Bengaluru, and diagnosing performance bottlenecks in headless commerce stacks is what keeps our clients' conversion rates intact.

Why checkout gets slow — the quadratic scan

When Medusa v2 resolves prices for product variants, it joins the product_variant table against product_variant_price_set, then against price_set_money_amount, and optionally against price_rule for region-specific pricing. Without indexes on these joins, PostgreSQL falls back to sequential scans.

For a single variant, this is invisible — scanning a few hundred rows is fast. But when the storefront requests a product listing with 100 variants, each variant triggers its own join cascade. The total work is proportional to variants × price_sets × money_amounts — effectively O(n²). With 1000 variants and 3 price sets per variant, that is 3000 sequential scans.

The Variant Scale Simulator shows this degradation:

Diagnosing your store

Not every Medusa store hits this bottleneck. Stores with under 500 variants and simple pricing (one price per variant, no price lists, no region overrides) may never notice. The Checkout Profiler walks through the five risk factors:

The fix — indexes, cache, pagination

The fix is three layers, each addressing a different access pattern:

1. Database indexes fix the root cause — the sequential scans in the pricing joins. This is the highest-impact change and should be applied first.
2. Variant cache eliminates redundant lookups within a single request. When a cart calculation resolves the same variant's price multiple times (e.g., for tax calculation, discount calculation, and total calculation), the cache serves it from memory.
3. Pagination guard prevents the worst case — a storefront request that fetches all variants without a limit (GitHub #12481).

-- Migration: add indexes for variant pricing lookup
-- Addresses the O(n²) scan in GET /store/products/:id/variants
-- See: GitHub #10751, #16232

CREATE INDEX CONCURRENTLY IF NOT EXISTS
  idx_product_variant_price_set
  ON product_variant_price_set (variant_id);

CREATE INDEX CONCURRENTLY IF NOT EXISTS
  idx_price_set_money_amount
  ON price_set_money_amount (price_set_id, currency_code);

CREATE INDEX CONCURRENTLY IF NOT EXISTS
  idx_money_amount_price_list
  ON money_amount (price_list_id)
  WHERE price_list_id IS NOT NULL;

-- For region-specific pricing
CREATE INDEX CONCURRENTLY IF NOT EXISTS
  idx_price_rule_price_set
  ON price_rule (price_set_id, rule_attribute);

Before vs after

The benchmark below shows typical response times for a Medusa v2 store with 1000 product variants, measured on a Hetzner CAX21 (4 ARM cores, 8GB RAM):

What to know before you commit

Index maintenance. Indexes speed up reads but slow down writes. Each INSERT or UPDATE to the price tables must also update four indexes. For most Medusa stores, price updates are infrequent (admin operations) while reads are constant (every storefront request), so the trade-off is heavily in favour of indexes. If you bulk-import prices frequently, run REINDEX CONCURRENTLY monthly.

Cache invalidation. The 30-second TTL means a price change in the admin takes up to 30 seconds to reflect on the storefront. For stores where real-time pricing matters (flash sales, dynamic pricing), reduce the TTL to 5 seconds or implement event-driven invalidation via Medusa's subscriber system.

PostgreSQL version. CREATE INDEX CONCURRENTLY requires PostgreSQL 11+. If you are on an older version (unlikely with Medusa v2, which requires PostgreSQL 14+), remove the CONCURRENTLY keyword — but expect table locks during index creation.

The medusa db:migrate ARM64 hang (GitHub #16011) can affect the migration on ARM-based servers. If the migration hangs, apply the indexes directly via psql instead of through the Medusa migration system.

Checkout performance is a conversion problem, not a DevOps problem. The quadratic variant pricing lookup is the single biggest performance bottleneck in Medusa v2 stores that grow past 500 variants. Four SQL indexes fix the root cause. The cache and pagination guard handle the edge cases. If you run EXPLAIN ANALYZE before and after, you will see sequential scans disappear and response times drop from seconds to milliseconds.