Most Hyvä migration case studies feature stores with three to fifteen thousand SKUs. The performance gains are dramatic, the migration is bounded, and the patterns documented in conference talks all hold. The picture changes when the catalog runs to a hundred thousand active SKUs or more. The default Hyvä configuration still works, but specific architectural choices that did not matter at lower scale start to matter a great deal. Stores running this kind of catalog need to think about indexing, caching, product listing rendering, and search infrastructure together rather than as separate concerns.
This piece walks through the patterns that hold up at scale on Hyvä-powered Adobe Commerce stores. It is written for engineering leaders at distributors, parts and accessories merchants, B2B catalogs, and large DTC brands whose catalog complexity sits in the upper third of mid-market. Bemeir’s high-SKU practice has worked on catalogs in the millions of SKUs, and the patterns below are the ones that have generalized across categories.
What Goes Wrong at Scale
The default Adobe Commerce + Hyvä configuration is tuned for catalogs in the low tens of thousands. As the catalog grows, several pressure points develop. Product listing pages slow down because the queries against `catalog_product_index_price` and `catalog_category_product_index` get larger. Layered navigation gets slower because the aggregation queries against attribute indexes have more data to traverse. Search response times grow because OpenSearch or Elasticsearch needs more memory and more thoughtful index configuration. And the cache hit rate drops because the long tail of category and search pages means a lot of cache misses on uncached variants.
Each of these is solvable, but none of them are solved by default. The team has to make explicit choices.
Indexer Strategy: Schedule Mode by Default
Adobe Commerce ships with indexers configurable per-index between “update on save” and “update by schedule” modes. On a low-SKU catalog, “update on save” is fine, the work is small and immediate consistency is convenient. On a high-SKU catalog, “update on save” becomes punishing. Saving a single product can trigger reindexing across multiple indexes, each touching a slice of the catalog, with admin response times measured in seconds.
The correct pattern for catalogs over 100k SKUs is to put all indexers into “update by schedule” mode and run them via cron at intervals appropriate to the business. Inventory updates that need to be visible in minutes get a five-minute schedule. Catalog updates that can wait an hour get an hourly schedule. The savings on admin responsiveness and on bulk-import performance are substantial.
The Adobe Commerce indexer documentation is the reference for the modes and the indexer dependencies. Choose the schedule per indexer rather than uniformly, because the freshness requirements differ.
Search Architecture: OpenSearch with Tuned Indexes
Adobe Commerce moved to OpenSearch as the default search engine. At catalog sizes over 100k, default OpenSearch configuration is rarely sufficient. The team needs to tune index settings, shard counts, replica counts, and the analyzer pipeline.
For most high-SKU stores, the right starting point is a single primary shard per index (because the catalog typically fits in a single shard at this size) and one or two replicas for query throughput. The analyzer pipeline should be tuned to the catalog: storefronts that sell technical parts need different tokenization than fashion or B2B catalogs. Adobe’s OpenSearch integration documentation covers the configuration surface, and AWS’s OpenSearch sizing guide is useful for capacity planning.
Bemeir’s high-SKU engagements typically include a search audit as part of the Adobe Commerce performance practice, and that audit covers analyzer configuration, query patterns, and the impact of stop words and synonyms on relevance.
Product Listing Page Strategy
The product listing page is the single page type that suffers most at scale. Hyvä renders PLPs with server-side HTML by default, which is fast, but the underlying query and the rendered DOM both grow with catalog size.
Patterns that hold up:
- Smaller page sizes: default page sizes on Adobe Commerce are often 12, 24, or 36. At high catalog sizes, smaller page sizes (12 to 24) keep the DOM size manageable and reduce the work per request.
- Infinite scroll versus pagination: infinite scroll is convenient but creates DOM accumulation. Pagination is less ergonomic but predictable. Stores with very long tail browsing patterns often benefit from pagination with a “load more” pattern that controls DOM accumulation.
- Skeleton states: while the PLP is rendering, a skeleton state can be served from cache and progressively replaced with the real content. This is a Hyvä-friendly pattern using Alpine for the progressive enhancement.
- Layered navigation aggregations: the aggregation queries that power facets can be the most expensive part of a PLP request. Cache aggregation results aggressively and consider precomputing them for high-traffic categories.
| Catalog size | Default Hyvä pattern | High-SKU pattern |
|---|---|---|
| < 10k SKUs | Update-on-save indexers | Update-by-schedule indexers |
| < 10k SKUs | Default OpenSearch shards | Default OpenSearch shards |
| < 10k SKUs | Page size 24-36 | Page size 12-24 |
| < 10k SKUs | Default Varnish TTL | Tuned TTL per page type |
| < 10k SKUs | Default Redis cache | Tuned Redis with cache warming |
| < 10k SKUs | Default category cache | Pre-rendered category pages |
| < 10k SKUs | Real-time stock display | Cached stock with TTL |
Caching Strategy: Three Layers
Caching at scale needs three layers, each tuned independently.
The first layer is Varnish (or Adobe Commerce Cloud’s Fastly equivalent). Varnish caches full HTML pages and serves them in milliseconds. The TTL strategy needs to account for cache invalidation triggers, product updates, price updates, inventory changes, without causing cache stampedes when those events occur. Adobe’s full page cache documentation covers the integration patterns.
The second layer is Redis. Redis caches session data, configuration, and block-level rendered HTML. Tuning Redis at scale means thinking about memory sizing, eviction policy, and the separation of cache databases per purpose. A single Redis instance handling sessions, config cache, and full-page cache fragments will eventually hit pressure that affects all three. Separating into dedicated instances is the cleanest path.
The third layer is application-level cache: the Magento config cache, the layout cache, the block HTML cache. These should be properly warmed in the deployment pipeline so that the first request after a deploy is not a cache miss across every layer simultaneously.
Inventory and Stock Display
High-SKU catalogs almost always have inventory complexity that drives a lot of database load. Showing live stock levels on every product listing is expensive at scale. A common pattern is to cache stock levels with a short TTL (one to five minutes) and accept that the display is slightly stale rather than hitting the inventory table on every page render.
For stores using Multi-Source Inventory (MSI), the source resolution logic itself can be expensive when there are many sources. Configure source selection algorithms appropriately for the business, most stores can use a simple priority-based selection rather than the more expensive distance-based or rules-based options. The Adobe Commerce MSI documentation covers the source selection configuration.
Bulk Operations: Asynchronous Patterns
Bulk operations on high-SKU catalogs, price updates, stock updates, category assignments, should never run synchronously in the admin or in API requests. The pattern is to accept the work, queue it, and process it asynchronously. Adobe Commerce ships with the message queue framework (using RabbitMQ or MySQL queues) that supports this pattern out of the box.
For PIM-driven catalogs, the import process is the highest-leverage place to apply asynchronous patterns. A nightly PIM sync that processes 50,000 product updates should run as queued work, not as a single long-running script that locks tables and blocks customer-facing requests.
Bemeir’s Adobe Commerce + PIM integration work, documented across the Adobe Commerce practice, uses these patterns by default for high-SKU clients. The same patterns apply to integrations with BigCommerce and Shopware at scale.
Frontend Patterns That Matter at Scale
On Hyvä specifically, a few frontend patterns become important at high catalog size:
- Image strategy: every catalog page is heavy on images. Use modern formats (AVIF, WebP), responsive image sizing, and lazy loading by default. Consider an image optimization service like Cloudflare Images or imgix if the catalog has many high-resolution source images.
- Alpine component lazy hydration: defer hydration of components below the fold. On a PLP with 24 products, the user only interacts with the products they can see initially.
- PLP grid virtualization: for infinite-scroll PLPs, virtualize the rendered grid so that products scrolled past are removed from the DOM. The Intersection Observer API supports this pattern natively.
Measuring at Scale
Core Web Vitals on high-SKU stores should be measured per page type, not as a single aggregate. The PLP, the PDP, the cart, and the checkout have different performance profiles and different optimization techniques. CrUX data segmented by URL pattern is the right starting point.
Stores measured at scale by Digital Commerce 360’s annual surveys consistently show that the gap between top-quartile and bottom-quartile performers in the same category is enormous. Closing that gap on a high-SKU catalog is exactly the work the patterns above support.
The Discipline That Scales
The thread connecting all of these patterns is that high-SKU stores cannot run on defaults. Every layer, indexing, search, cache, frontend, inventory, needs explicit configuration tuned to the catalog. The good news is that the tools are mature, the documentation is good, and the patterns are well-understood. Stores that invest the engineering effort to apply them produce experiences that scale gracefully. Stores that try to ride defaults end up with mysterious performance regressions that resist easy fixes. The choice between those outcomes is made on the configuration side, not on the platform side.
