Building High-Performance Product Catalogs in SitecoreAI (XM Cloud) Without Creating Millions of Items

Model a real commerce catalog as Sitecore items and you already know how it ends: 50,000 SKUs become 50,000 items, each with variants, each needing to publish, each one stretching your build, your publish queue, and limits Experience Edge was never built to carry. The instinct is understandable Sitecore is where content lives. But a product catalog is not content, and treating it like content is the most expensive mistake teams make on SitecoreAI.

The fix is a hybrid architecture: product data stays in a system built for it, Sitecore owns presentation and marketing, and a dedicated search service powers discovery. This post lays out that pattern — then answers the question that decides your search engine: which is fastest, and which reflects changes immediately after a sync.

Why a catalog can't live as Sitecore items

SitecoreAI serves content through Experience Edge which is a globally cached, read-only GraphQL layer that's excellent at its job but has hard limits a large catalog hits immediately:

• A single query returns at most 1,000 entities, beyond that you paginate with cursors.
• Every query is scored against a complexity budget of 250, spent on the number of items and the fields and nesting. "Fetch all products in one call" is off the table.
• The delivery API enforces roughly 80 uncached requests per second. On a catalog site firing several queries per page, that ceiling is easy to breach under load or right after a publish clears the cache — and visitors start seeing 429s.

Publishing compounds it. A single item publishes to Edge in tens of seconds, not the few a web database takes, multiply by a large catalog and a few busy authors and the queue becomes a bottleneck. Builds balloon too, since pre-generating a page per product means generating tens of thousands of pages from Edge.

The deeper issue: Edge's GraphQL search filters content by field value it isn't full-text or faceted site search, and Sitecore's own docs point you to a dedicated service for anything more. The embedded Solr inside the platform powers only the authoring UI, not your front end. So even if you forced the catalog into items, you still wouldn't have real search.

The catalog doesn't belong in Sitecore, and search doesn't come from Sitecore. Both need a different home.

Separate the catalog from the content

Stop asking "how do I get products into Sitecore" and ask "what is Sitecore actually responsible for here?"

Product data like SKUs, prices, inventory, specs, variants… has a natural home. your commerce platform, PIM, or ERP behind an API. That system already owns and updates it. Sitecore owns the experience around the product like the page template, layout, merchandising blocks, editorial copy, campaign banners, SEO fields. That's content, and it's a small, manageable set of items.

So you model the shape of a product page once, and fetch the data for any product at request or build time. The catalog can hold ten million SKUs while your item tree barely grows.

The hybrid architecture

Three layers do the work.

Source of truth: your commerce/PIM/ERP API, plus a Redis cache for hot data. It owns the data, catalog size never touches Sitecore's item count.

Search and discovery a dedicated service (Coveo, Sitecore Search, or Algolia) that ingests the catalog and powers listings, facets, type-ahead, and keyword search. This is what users query, and it exists because Edge can't do this job.

Presentation SitecoreAI plus your headless frontend, where you model one product-detail template and a few merchandising components, and let a single dynamic route serve every product.

That route is the keystone. Instead of an item per product, a wildcard "Product Detail" route reuses one layout for every product URL. Every product page resolves to the same layout item, so requests share one cached Edge response that doesn't count against the rate limit. The route reads the SKU from the URL, fetches that product's data from the API or index, and renders unlimited product URLs, full design control, almost no Edge load.

# One cached layout query for the shared Product Detail route
query ProductDetailLayout($site: String!, $routePath: String!, $language: String!) {
  layout(site: $site, routePath: $routePath, language: $language) {
    item {
      rendered
    }
  }
}

// getStaticProps / getServerSideProps for /products/[sku]
export async function getProduct({ params }) {
  // 1. Sitecore (Edge) gives you the page chrome — cached, cheap, rate-limit-friendly
  const layout = await edgeClient.getLayoutData('/products/_wildcard');

  // 2. Your commerce/PIM API gives you the live product data — the source of truth
  const product = await fetch(`${PRODUCT_API}/products/${params.sku}`).then(r => r.json());

  // 3. Your search service backs listing/category pages and search itself
  return { props: { layout, product } };
}

For listings and category pages you don't hit the product API per item. you query the search index, which returns paginated, faceted results in milliseconds. The detail route handles the deep single-item view. Nothing here grows with catalog size except records in a search index, which is exactly what indexes are for.

Coveo vs. Sitecore Search vs. Algolia

All three work on SitecoreAI, none is the embedded Solr. They differ in how they ingest data, how fast they answer, and how quickly changes appear after a sync. First, one distinction that most "which is faster" debates blur:

• Query latency keystroke to results on screen. "How fast is search" for the user.
• Index-freshness latency content change to "queryable in the index." "How fast it reflects after a sync."

A service can be great at one and mediocre at the other.

How each ingests data.

Coveo the old Coveo for Sitecore package isn't supported on SitecoreAI, you can use generic connectors instead: a Sitemap or Web source that crawls on a schedule, or a Push / REST API source you feed with custom code for near-real-time updates or non-crawlable data.

Sitecore Search crawlers (web, advanced web, API) pull on a schedule and rebuild a source as a unit, with no single-page update, the Ingestion API pushes targeted updates, usually wired to publish webhooks.

Algolia no first-party connector, so you build it, which gives you the most control: either the Algolia Crawler, or better for catalogs. a serverless function triggered by a publish webhook or, ideally, by changes in your commerce/PIM/Redis layer, writing records straight to Algolia.

Fastest queries: Algolia, by design single-to-low-double-digit millisecond processing, built for instant search-as-you-type. Coveo and Sitecore Search are both fast enough for almost any requirement but aren't built around that obsession.

Most immediate after a sync: Algolia again. Its engine turns a write into a queryable record in seconds, and waitTask confirms it. Coveo's Push API is also near-real-time. Sitecore Search is where expectations and reality diverge: teams report webhook-to-ingestion updates "within seconds," and in good conditions they happen but Sitecore documents ingestion as asynchronous, with no SLA, often around 20 minutes, and a full republish can flood it. If "publish and it's instantly searchable, guaranteed" is the requirement, its crawler is scheduled and its ingestion is best-effort.

Worked example: 50K SKUs, search-driven listings, 5-minute price updates

Here's the concrete case the architecture has to handle:

A 50,000+ SKU catalog. Listing pages come from search, with sort and filter. Product data syncs from an ERP and a Redis cache over an API. And a hard rule is when a discount campaign goes live at 12:00 and someone updates price in the ERP/Redis, the new prices must appear on the frontend within 5 minutes.

This scenario pulls in two directions at once, and that tension is the whole test. Because you sort and filter by price, price has to live inside the search index and sorting and faceting happen in the engine, not at render time, so a stale index means wrong ordering. But price is also your most volatile field, and it has to be fresh within five minutes.

That combination rules one engine out. Sitecore Search's ingestion is asynchronous with no SLA and often takes around 20 minutes it can't promise a 5-minute price update, and its crawler rebuilds the entire source, which is impractical to run every few minutes across 50K records.

Algolia is the right choice here. Coveo's Push API is a viable second.

The architecture:

1. ERP/Redis stays the source of truth for price. Nothing about price is authored in Sitecore.
2. The search index stores each product with its price, so listings can sort and filter on it.
3. On a price change, push a partial update to Algolia just the price attribute in a batch. Algolia indexes it in seconds, so listings reflect new prices well inside the 5-minute window. Real-time pricing is a use case Algolia is built for, and partial, batched updates are exactly the recommended pattern.
4. The product-detail page reads the live price from Redis at render. Redis is sub-millisecond, so the detail view is always exact even in the seconds between a change and the index catching up.

For the 12:00 campaign, the trigger fits your stack: the ERP fires an event, or your "update price" action calls a sync endpoint → a serverless function → a batched Algolia partial update. If you'd rather not wire events, a job polling Redis for changed prices every minute or two still clears the 5-minute bar comfortably. Either way, listings update through the index in seconds-to-a-minute, and the detail page reads live from Redis regardless. (Sitecore's own guidance on integrating Sitecore Search with XM Cloud flags the same webhook-pipeline considerations if you go that route.)

The split is the point: the index handles discovery and price-based sorting; Redis serves the exact, live number. Sort and filter stay correct, the displayed price is never wrong, and you hit the 5-minute SLA without forcing the search engine to act as a real-time database.

Choosing between them

Match the tool to the job, not to a benchmark:

• Algolia — when speed, simple real-time updates (price, stock), and developer experience matter most, and catalog data is best pushed straight from a PIM/ERP/Redis. You build and own the Sitecore integration.
• Coveo — when relevance, ML ranking, recommendations, and enterprise-scale personalization drive conversion. Its Push API covers near-real-time needs.
• Sitecore Search — when staying inside the Sitecore ecosystem matters most: one vendor, native fit, AI relevance out of the box — provided you don't need guaranteed sub-5-minute freshness.

Conclusion

You don't scale a catalog in Sitecore by making more items, you scale it by keeping the catalog out of Sitecore. Let the ERP/PIM own product data, a dedicated search service own discovery, and SitecoreAI own the experience through one reusable product-detail route. The search choice then comes down to what you optimize for: Algolia for the fastest queries and the most immediate, predictable freshness after a sync; Coveo for the deepest relevance; Sitecore Search for the tightest native fit. For a 50K-SKU catalog with search-driven listings and a 5-minute price SLA, the answer is clear Algolia for the index, Redis for the live price.

References (official documentation)

Sitecore — Experience Edge

• Limitations and restrictions of Experience Edge
• The Experience Edge schema (search, complexity, pagination)
• Experience Edge rate limits and caching

Sitecore Search

• Configure indexing (sources and crawlers)
• Using the Ingestion API to add content to an index
• Keep indexes up to date (ingestion timing and SLA)
• Integrating Sitecore Search with XM Cloud

Coveo

• Sitecore XM Cloud migration guide
• Index Sitecore XM Cloud content

Algolia

• How fast is Algolia? (query latency)
• How fast is the indexing?
• Optimizing indexing for real-time use cases, including pricing

Roshan Ravaliya

Software Developer – Sitecore & .NET

Roshan is a Sitecore and .NET developer at Addact, specializing in Sitecore XM Cloud, Sitecore XP, and SitecoreAI-driven implementations. He works with .NET Core, C#, Azure Functions, and Next.js to deliver scalable, cloud-enabled, and performance-focused digital solutions.