How We Helped a Legacy Book Retailer Streamline Multi-Million Product Catalog Operations

A Large Catalog Use Case for Enterprise Magento Merchants

Managing a large product catalog is a major growth milestone for any eCommerce business. More products can mean more search visibility, more customer choice, and more revenue opportunities.

But when a Magento catalog grows into millions of SKUs, the challenge changes.

It is no longer just about adding products to the store. It becomes about how efficiently the platform can process product data, inventory changes, pricing updates, and backend operations without slowing down the customer experience.

This was the exact challenge we solved for Strand Books, a legendary independent bookstore managing an enormous catalog of approximately 4.7 million products, including 2.1 million configurable products and 2.6 million simple products. The issue wasn’t traffic alone. The real challenge was the sheer volume of product and inventory data being continuously processed behind the scenes, creating increasing strain on the Magento backend infrastructure.

The development documentation also highlights that routine inventory updates were triggering heavily overloaded database queries, creating prolonged indexing times, database deadlocks during order placement, and significant server strain.

This use case explains how we helped stabilize the backend, reduce unnecessary processing, and improve Magento’s ability to support a large catalog more efficiently.

The Hidden Problem With Massive Magento Catalogs

For merchants, catalog growth usually sounds like a good problem to have.

But at enterprise scale, every product update adds more work behind the scenes.

A single inventory update may seem small, but when thousands of updates happen across millions of products, the platform can quickly become overloaded. In the Strand Books environment, routine operations like inventory updates were creating heavy database activity and contributing to slow indexing, order-related deadlocks, and server strain.

What This Meant for the Business

For merchants, these issues are not always obvious at first. The store may simply feel slower, updates may take longer, or teams may avoid running imports during business hours.

But over time, backend inefficiency can become a real business risk.

The Core Problem: Magento Was Doing Too Much Work Too Often

The main issue was not that Magento could not support a large catalog.

The issue was that too many backend operations were being processed in ways that created unnecessary system load.

For example, not every inventory quantity change needs a full reindex. If a product quantity changes from 200 to 180, the customer still sees the product as available. But if a product changes from 1 to 0, that affects stock visibility and does need special handling.

The goal was to help Magento work smarter, not harder.

Instead of forcing the platform to process every update with the same level of intensity, we focused on reducing unnecessary backend workload and improving how data was processed, queued, and stored.

The technical documentation notes that the solution included smarter indexing, memory optimization, pricing indexer adjustments, query simplification, and asynchronous processing.

The Optimization Approach

1. Smarter Indexing for Large Catalogs

One of the first areas we optimized was indexing.

In large Magento catalogs, indexing can become one of the biggest performance bottlenecks. The development documentation explains that multi-threaded indexing strategies were used to accelerate scoped indexes while isolating processes to reduce deadlock risks. It also notes that batch sizes were adjusted to better match the server environment and prevent memory exhaustion.

For merchants, the benefit is simple:

Magento can process large catalog updates more efficiently without overwhelming the system.

Merchant Impact

2. Reducing Unnecessary Reindexing

A major improvement came from introducing smarter “skip” logic for routine inventory changes.

Instead of triggering heavy reindexing for every inventory quantity update, the system was adjusted to trigger major reindexing only when stock status actually changed, such as when a product moved from in stock to out of stock or back again.

Simple Example

This helped reduce unnecessary backend activity across millions of products.

For merchants, this is one of the most important lessons from the use case: large catalog performance often improves when the platform stops doing work that does not directly impact the customer experience.

3. Simplifying Pricing Architecture

During the system audit, it was identified that Strand Books was not using customer-group-specific pricing or tier pricing. However, Magento was still maintaining pricing structures connected to those features.

The solution was to adjust the pricing indexer dimension from customer_group to none, consolidating pricing data into a simpler structure instead of maintaining separate pricing tables for multiple groups.

For merchants, this means unused complexity can quietly slow the system down.

Over time, Magento stores often accumulate:

• Old configurations
• Unused pricing rules
• Legacy integrations
• Excessive backend processes

Removing or simplifying what is no longer needed can improve scalability and performance.

4. Moving Heavy Tasks Into Background Queues

Another major part of the solution was moving heavy backend operations away from the live storefront experience.

The documentation notes that complex inventory updates and Mailchimp data syncing were offloaded to custom RabbitMQ background message queues to help prevent frontend timeouts.

This is especially important for large merchants.

When backend tasks run directly during customer activity, they can slow down the storefront or interfere with checkout. But when those tasks are processed in the background, customers can continue browsing and purchasing while the system handles heavy operations separately.

Before vs After

The Result: A More Stable Magento Operation

By improving how Magento processed, queued, and stored data, the system became more stable and better suited for large catalog operations.

The development documentation states that the optimization work helped eradicate database deadlocks, reduce index processing times, and support real-time inventory accuracy across millions of SKUs without overwhelming the server architecture or disrupting checkout.

Most importantly, the platform could support large-scale product and inventory operations without creating unnecessary risk for the customer experience.

What Merchants Can Learn From This Use Case

Large Magento catalogs do not automatically mean slow stores.

But they do require marter backend planning.

As catalog size grows, merchants need to think beyond frontend page speed and focus on how Magento handles:

At enterprise scale, small inefficiencies can multiply quickly.

A slow indexer, an unnecessary pricing configuration, or a poorly timed inventory sync may seem minor in isolation. But across millions of products, those issues can create serious operational pressure.

The biggest takeaway from this use case is simple:

Magento scalability is not just about stronger infrastructure. It is about smarter processing.

Scaling Magento Successfully Requires More Than Just Infrastructure

If your Magento store is experiencing:

• Slow indexing
• Inventory sync delays
• Heavy backend operations
• Checkout instability
• Database deadlocks
• Large catalog performance issues

It may be time to review how your Magento environment is processing data behind the scenes.

At Rave Digital, we help enterprise merchants improve Magento scalability, backend performance, inventory processing, and operational stability for high-volume commerce environments.

Ready to Improve Large Catalog Performance?

Discuss your catalog scalability challenges and explore optimization opportunities for your store.