· 2 min read
The Storefront API at 300,000 products
Cursor pagination is fine at 500 products and painful at 300,000. What changes when your catalogue outgrows the happy path.
Most Shopify advice is written for stores with a few hundred products. Almost none of it survives contact with a publishing catalogue.
At 300,000 products, things that were never a decision become the main decision.
Pagination stops being a list
The Storefront API gives you cursor-based pagination, which is the right primitive. The mistake is treating it like an array you can walk on demand.
query CollectionPage($handle: String!, $cursor: String) {
collection(handle: $handle) {
products(first: 24, after: $cursor) {
pageInfo { hasNextPage endCursor }
nodes { id handle title }
}
}
}
That query is correct. What breaks is the assumption around it — that to render page 400, you can walk to page 400. You can't, not within a request budget anyone will tolerate.
The shift is to treat pagination as a streaming problem with cached boundaries: you persist the cursors at known offsets, so deep pages resolve from a cached boundary rather than from a walk. Deep pagination becomes a lookup instead of a traversal.
Sitemaps become an engineering problem
A sitemap with 300,000 URLs isn't a file, it's a pipeline. It has to be generated incrementally, split across index files, and regenerated on catalogue change without regenerating everything. This is genuinely one of the larger pieces of work in a large-catalogue headless build, and it is never in the estimate.
Over-fetching costs more than you think
At small scale, requesting a few extra fields is invisible. At large scale it shows up in three places at once: query cost against the rate limit, payload size over the wire, and cache memory. Query shape becomes something you review, not something you write once.
What I'd tell someone starting this
Decide early whether your catalogue is large or very large, because they're different projects. Under roughly 10,000 products, the happy path works and you should take it. Above about 100,000, assume that every list surface — collections, search, sitemaps, feeds — needs its own strategy.
The trap is building for the first case and discovering you're in the second after launch.
Hiring for work like this?
I'm Thang Viet To — a senior backend & platform engineer with 9+ years on event pipelines, multi-tenant commerce systems and the platforms behind them.
Get in touch