Stop stock integrations triggering full Magento reindexing
Frequent ERP or stock-feed updates that call a full reindex create heavy CPU and database load. Process only changed SKUs and let Magento’s scheduled indexing do the rest.
Frequent ERP or stock-feed updates that call a full reindex create heavy CPU and database load. Process only changed SKUs and let Magento’s scheduled indexing do the rest.
An external stock integration was updating inventory every few minutes and calling a full reindex each time. We changed it to detect differences first and let Magento’s scheduled indexing process only the changed records — removing a constant source of CPU and database load.
Why full reindexing hurts
A full reindex rebuilds index tables for the whole catalogue. Running it every few minutes competes with shoppers for CPU and database capacity — slowing category pages, search and checkout.
RELATED GUIDEGoogle Merchant Center feed optimisation: fix disapprovals and win more Shopping clicks → Need reliable ecommerce support?Patches, upgrades and fixes from certified developers.Get a free store health check →The better pattern
- Compare incoming stock with current values before writing
- Update only SKUs whose quantity or status changed
- Set indexers to “Update by Schedule” so Magento processes changelogs
- Let cron and the mview queue apply partial reindexing
- Log how many rows changed per run
What to measure
Track rows received vs rows changed, indexing time and database load before and after. The difference is usually dramatic.
Common mistakes to avoid
How we help with ecommerce
Frequently asked questions
Is “Update on Save” wrong?
Not always, but for frequent bulk updates “Update by Schedule” is usually far more efficient.
Will partial indexing delay stock updates?
Only by the cron interval — typically a minute or two when cron is healthy.
Can you fix our integration?
Yes — this is a common optimisation in our ecommerce support work.