The limit moved. The wall didn't.

A story about a number that got twenty times bigger and changed less than anyone expected.

For years, the most expensive number in Shopify commerce was 100. One hundred variants per product, three options, no court of appeal.

Apparel people know the math by heart. Eight sizes and twelve colors is already 96 variants, so the moment you wanted a third dimension you weren't modeling your products anymore. You were reshaping them to fit the platform.

Then, in April 2024, Shopify killed the number. New GraphQL Admin APIs lifted the per-product cap from 100 to 2,048, a change that reached all the way down into Shopify's data layer and schema. When a platform rebuilds its foundations to move a limit, you know how deep that limit ran.

Almost everyone we talked to assumed the variant problem was over. So did we, briefly.

The footnotes start talking

The first thing we noticed was what didn't move. The new limit is GraphQL-only. The REST Admin API and the legacy product editor stayed at 100, and Shopify had already deprecated the REST product and variant endpoints as of 2024-04. New public apps had until February 1, 2025 to migrate; custom apps got until April 1.

Here is what that deadline looks like from inside a store: nothing. An app still on REST reads your products just fine. It simply can't create past 100 variants or manage variants at scale, so it caps you quietly, like it's 2019. No error, no warning light. A limit that fails silently is the worst kind of limit.

The second footnote was the storefront. Theme code historically loaded the entire product.variants object at page render, and a browser parsing 1,200 variant objects, each dragging its inventory and pricing payload behind it, was never part of anyone's plan. So Shopify capped theme rendering at 250 variants. The Liquid object returns at most 250 even when the product holds 2,048; past that, the theme has to pull variant data on demand through the option_values API. Sound architecture. Also a breaking change for every theme built on the comfortable old assumption that all variants are just sitting there at render time.

Even then, our theory was still "migration pain." Update the apps, refactor the themes, enjoy the headroom. The theory was wrong.

The wall behind the wall

The variant ceiling was never the only ceiling. A Shopify product supports a maximum of three options. Size, color, material. Any three dimensions you like, but three. That's a hard limit in the product model itself, not a performance quirk that gets tuned away in some future release.

A furniture maker who needs size, material, finish, and leg option gets nothing from 2,048. Four dimensions, three slots. The split still happens, at any variant count.

The math explains the enforcement. Three options with roughly 8-16 values each already lands between 512 and 4,096 combinations, and a fourth independent option makes the numbers explode. Shopify's model assumes three and holds the line there.

Then we counted

We logged the new ceiling across 28 client catalogs, expecting a queue of consolidation work. The data was almost insulting.

Eighteen of the 28 were already optimized under the old 100-variant model and got nothing from the increase. Seven could merge 2-3 previously split products back into one, real wins for SKU architecture and on-site search, worth taking. And three sat pressed against the three-option wall, needing restructuring no matter where the per-product cap goes, now or ever.

So the higher limit widened the window before a restructure, and that's worth something. But for a catalog with four or more dimensions, no future cap increase will ever close the question. The full rollout to all merchants didn't even finish until October 15, 2025, and the three catalogs that needed restructuring still needed it the day after.

SKU soup

Once a split is unavoidable, it happens in one of three modes. Backend: mint child products and hand each a subset of variants. Display: a storefront app fakes the division on top of one real product. Organizational: model separate products from day one. Each mode charges you somewhere.

Most merchants meet this moment with a keyboard and good intentions. They break a 300-variant product into 3 products by hand and inherit 300 new SKUs with nothing coordinating them. SKU soup.

That's why we built SPLIT, our variant splitting engine. You declare which dimensions are independent and which products should merge; it orchestrates the backend split with full propagation of metafields, inventory, images, and SEO metadata. The split becomes an architecture decision instead of a cleanup job.

Three lines and a clock

Our internal checklist for the new ceiling has three lines: products with more than 3 independent variant dimensions, products past 250 variants, integrations still on REST. Fix the REST one first, because that wall has dates on it. The other two you weigh against your storefront and inventory model.

For most merchants, 2,048 really is the end of the story. For complex catalogs, it solved the temporary problem and exposed the permanent one: the real constraint was never the variant count, it was the three options.

One hundred is gone. Three is forever. Still no court of appeal.

If you'd rather have someone run that checklist against your catalog before the next wall finds you, that's part of what our Infrastructure Stress-Test covers.

Sources

1. New GraphQL product APIs that support up to 2048 variants now available in 2024-04. Shopify Developer Changelog. Details on the April 2024 GraphQL API release with 2,048-variant support.

2. The product variant limit is now 2048 for all merchants. Shopify Developer Changelog. October 2025 rollout announcement to all merchants.

3. Support high-variant products. Shopify Developer Documentation. Guidance on theme rendering, the 250-variant limit, and deferred-loading patterns.

4. Shopify API limits. Shopify Developer Documentation. Official API rate limits and product data constraints.

5. Product Variant (REST API). Shopify Developer Documentation. REST endpoint documentation and deprecation notice for variant management.