The Magento price indexer computes a final price for every product across every customer group, website, and currency, writing it all to catalog_product_index_price. On a large catalog with many customer groups, that table explodes into millions of rows and the reindex crawls. Here is why that happens, and how to fix it.
Price indexing is usually the most expensive indexer in a Magento store, and it gets worse as you add the exact things B2B stores need: more customer groups, more websites, tier prices, and catalog rules. This guide explains the multiplication that makes the table so large, the dimension modes that parallelize the reindex, the known performance patch, and what to do when a reindex is stuck. For the wider build, see our Magento development services.
What the price indexer actually computes
The indexer, code catalog_product_price, precalculates the final price a shopper should see so the storefront never has to compute it at render time. “Final price” is not one number. It is the result of applying, per product:
- The base and special prices.
- Tier prices and group prices.
- Catalog price rules.
- Tax, where price display requires it.
And it does this for every combination of customer group, website, and currency. The output lands in catalog_product_index_price. That combinatorial scope is the whole story: the table does not have one row per product, it has roughly one row per product per customer group per website. Our guide to catalog price rules versus cart price rules covers the rules that feed into this calculation.
Why the table explodes
Do the multiplication and the problem is obvious. A store with 190,000 products and a handful of customer groups is fine. A store with 190,000 products and 8,800 customer groups is not: that combination has been reported to write roughly 130 million rows into the final price index table, and the reindex to match. The painful part is that you often cannot just delete the groups, because catalog rules and tier prices are attached to them.
| Products | Customer groups | Websites | Approx. index rows |
|---|---|---|---|
| 50,000 | 4 | 1 | ~200,000 |
| 190,000 | 20 | 2 | ~7.6 million |
| 190,000 | 8,800 | 1 | ~130 million (reported) |
The lesson: customer group count is a first-class performance decision on Magento, not just a merchandising one. B2B stores that assign a group per account are the ones that hit this wall. Before you design per-account groups, understand what they cost the price index. This is the same scaling discipline our guide to Magento attribute set and EAV design for large catalogs applies to attributes.
Dimension modes: parallelize the reindex
Magento can split the price index into multiple tables by dimension, which lets it reindex those partitions in parallel. You set the mode with:
bin/magento indexer:set-dimensions-mode catalog_product_price website_and_customer_group
The valid modes are none (default), website, customer_group, and website_and_customer_group. Check the current mode with bin/magento indexer:show-dimensions-mode. Parallelism is driven by the MAGE_INDEXER_THREADS_COUNT environment variable.
The important nuance, straight from Magento’s own guidance: dimension modes only help if you actually parallelize, and the total dimension count is websites multiplied by customer groups. Five websites and three groups is 15 dimensions. If you cannot give the reindex a thread count that matches the dimension count, adding a dimension mode can do nothing, or even make the Product Price reindex slower. So do not set a dimension mode reflexively. Set it only when you have both a genuinely parallel environment and the threads to feed it. If you do not parallelize, leave the mode at none. Adobe’s manage indexers documentation covers the command and which indexers support dimensions.
Update on Save versus Update on Schedule
How the indexer runs matters as much as how it is partitioned. Magento offers two modes:
- Update on Save reindexes immediately when you save a product or rule. Fine for small catalogs, painful at scale because a single save can trigger a heavy reindex inline.
- Update on Schedule uses materialized-view changelog tables to batch changes and reindex them on cron. This is the right choice for any large or busy catalog, because it decouples the save from the reindex.
For a large store, run the price indexer on schedule, and keep cron healthy so the changelog is actually processed. Our guide to Adobe Commerce cron and indexer health covers the machinery that Update on Schedule depends on, and MGT-Commerce’s index management guide compares the two modes in detail.
Replica tables and batch sizes
Two lower-level details explain a lot of price index behavior. First, the indexer uses a replica table pattern: it builds the new index in a replica table and swaps it in when done, so the live catalog_product_index_price keeps serving prices during a full reindex. That is why a stuck or corrupt index sometimes needs both the main table and its replica cleared, not just one.
Second, the indexer processes rows in batches, and the batch size is configurable. Batches that are too large consume memory and can stall on big catalogs; batches that are too small add round-trip overhead. When a reindex is slow on a large catalog, tuning batch sizes is often part of the fix, alongside the database-level settings that let those batches run efficiently. Capture the slow queries first, then adjust the batch size for the specific indexer rather than changing everything at once. The developer reference on Magento indexing covers the architecture these batches run inside.
Known performance traps
A few specific issues are worth checking before you assume your setup is just big:
- Gradual degradation (ACSD-53347). Adobe documents a price indexing problem where performance degrades over time, tied to temporary tables such as
catalog_product_index_price_opt_agr_tempthat appear with many customer groups, multiple websites, and custom options. If your reindex has gotten slower month over month without the catalog growing much, check whether the Quality Patches Tool has a patch for your version. - Bundle products. A reported Magento issue shows bundle product price reindexing running far longer than expected on some versions, tied to specific bundle price settings. If your slow reindex correlates with bundle-heavy categories, that is a lead.
- Corrupted or stuck index. One site with a reindex running around 23 hours cut it to under an hour by truncating
catalog_product_index_priceand its replica, tuning batch sizes, and reindexing. Truncate-and-reindex is a real recovery move, but test it on staging first, because you are clearing the table the storefront reads prices from.
A practical reindex playbook
When the price reindex is the bottleneck, work through this order:
- Measure. Confirm it is
catalog_product_pricethat is slow, not the whole reindex, and capture the slow queries with database logging. - Reduce the multiplier. Can any customer groups or websites be consolidated? Every one you remove shrinks the index.
- Move to Update on Schedule if you are still on Update on Save.
- Apply the ACSD patch if the degradation pattern matches.
- Parallelize deliberately, with a dimension mode and a matching thread count, only if the environment supports it.
- Run heavy full reindexes off-peak with
bin/magento indexer:reindex catalog_product_price, never during peak traffic. - Re-measure after each change so you know which lever actually moved the needle, rather than stacking changes and guessing.
Keeping the index table lean also helps overall database health, which our guide to Magento database bloat covers alongside the log and quote tables that grow beside it.
How SaaS platforms hide this
Price indexing is a self-hosted concern. On managed platforms the price computation is abstracted and you never see an index table:
- Teams on Shopify development do not manage a price index; pricing and any B2B catalog pricing are handled by the platform.
- BigCommerce development and Shopware development similarly hide the indexing layer, trading control for simplicity.
The trade is familiar: Magento gives you total control over pricing logic and the performance responsibility that comes with it. For a store with complex B2B pricing, that control is the point, as long as you design customer groups with the index cost in mind. The team at Bemeir builds and tunes these large catalogs, and our technology partners include the ERP systems that usually drive the pricing in the first place.
FAQ
Why is the Magento price indexer so slow?
Because it precalculates a final price for every product across every customer group, website, and currency, applying tier prices, group prices, catalog rules, and tax. The output table grows roughly with products multiplied by groups multiplied by websites, so a catalog with many customer groups produces an enormous index that takes a long time to rebuild.
What is catalog_product_index_price?
It is the table the price indexer writes to. It holds the precomputed final price per product per customer group per website, so the storefront can display prices without recalculating them at render time. Its row count, not just your product count, is what determines reindex time.
Should I use dimension modes for the price indexer?
Only if you parallelize the reindex and can provide a thread count that matches the dimension count, which is websites multiplied by customer groups. Setting website_and_customer_group mode without enough threads can do nothing or even slow the reindex. If you do not parallelize, leave the mode at none.
How do I fix a reindex that runs for hours?
Confirm it is the price indexer, move to Update on Schedule, check for the ACSD-53347 degradation patch, and reduce customer groups and websites where possible. For a corrupted index, truncating the price index tables and reindexing can recover it, but test that on staging first since it clears the prices the storefront reads.
Do customer groups affect performance?
Yes, directly. Each customer group multiplies the price index, so a store that assigns a group per B2B account can generate tens or hundreds of millions of index rows. Treat customer group count as a performance decision, and design per-account pricing with the index cost in mind.
Design pricing that scales
Price indexing is where B2B ambition meets Magento’s architecture: the customer groups that power per-account pricing are the same ones that can bring the reindex to its knees. Getting it right means designing groups, dimension modes, and schedules together. Bemeir is the USA’s first Hyva Gold Partner and a B2B-focused Adobe Commerce shop. Learn more about Bemeir and how we build large catalogs that reindex in minutes, not hours. See our Hyva development services for the storefront that renders those prices fast.
