Custom Ecommerce Website vs Shopify for Large Catalogs: Where Each One Breaks

The short answer: when a large catalog outgrows Shopify

A large catalog is not a product count. It is the shape of your data. A store with 200,000 flat products (one SKU, a handful of attributes) is a very different problem from a store with 5,000 configurable products that each expand into thousands of combinations.

Shopify is the right default for most large catalogs. Custom becomes the better answer only when one of these five constraints bites:

• Variant structure: your products need more than 3 options or more than 2,048 combinations.
• Sync volume: your ERP or PIM pushes huge price and stock changes all day.
• Deep attribute search: buyers filter on dozens of technical attributes, or on compatibility (part fits vehicle, bolt fits thread).
• Pricing logic: prices depend on customer, contract, quantity and rules, not on a price list.
• Data ownership: the catalog already lives in your own system and the store should read it, not copy it.

If none of the five applies, stay on Shopify. If two or more apply, keep reading, because this is where custom or a hybrid starts to pay for itself.

What Shopify's hard limits actually are

Shopify documents its product structure limits plainly. These are the numbers that matter for catalog design:

These figures come from Shopify's variant documentation, which also says that going beyond 2,048 variants or three options requires third-party apps or custom theme code for line item properties.

The math that catches teams out

Three options sounds like plenty until you multiply. A product with 20 sizes, 15 finishes and 10 lengths is 3,000 combinations, already past the 2,048 cap. The usual workaround is to split one logical product into several Shopify products, which then breaks the single product page, the shared reviews, and the clean URL you wanted.

Compatibility is not a variant

The most common modeling mistake on large technical catalogs is forcing a many-to-many relationship into the variant system. An auto part that fits 400 vehicles, or a filter that fits 60 machines, is a compatibility table, not 400 variants. Shopify has no native many-to-many fitment model, so you either store it in metafields and build search around it, or you hold it in your own database. That is often the real reason a large technical catalog ends up custom or headless.

Shopify API limits and bulk catalog syncs

Large catalogs live and die by sync. Prices, stock and attributes flow in from an ERP, a PIM or supplier feeds, and the store must keep up. Shopify's GraphQL Admin API meters this with a points budget, and the restore rate depends on your plan:

Per Shopify's rate limit documentation, a single query cannot exceed 1,000 points on any plan, and input arrays are capped at 250 items. Bulk operations are exempt from those per-query limits, which makes them the right tool for full catalog loads and large exports.

The cap that hits stores above 500,000 variants

The same documentation describes a resource-based limit: once a store passes 500,000 variants, no more than 10,000 new variants can be created per day on any API. Shopify Plus is exempt. The arithmetic is blunt: adding 100,000 new variants to a store already past that threshold takes at least 10 days on a non-Plus plan.

What this means in practice

• Design for deltas. Push only what changed, not the whole catalog every night.
• Use bulk operations for initial loads and full reconciliations; use targeted mutations for live price and stock changes.
• Treat the rate limit as an architecture input, not an error to retry around. A sync design that needs the full budget just to stand still has no headroom for a sale day.

Where a custom ecommerce website wins on large catalogs

Custom is not better in general. It is better at specific things, and you should be able to name which of them you need:

The pattern is consistent: custom wins where your catalog is more structured than a retail product list, and loses where your catalog is a normal retail list at large volume.

What custom costs that Shopify does not

Shopify's real product is everything around the catalog: checkout, payments, fraud handling, tax, hosting, security patches and uptime. When you go custom you own all of that. Be honest about the list before you commit:

• Checkout and payments. This is the piece you should be most reluctant to build. Use a payment provider's hosted or embedded components rather than touching card data yourself.
• Security and compliance. Patching, dependency updates, backups and incident response become your job, or your agency's.
• Admin tooling. Order management, refunds, returns and staff permissions do not come for free; each one is scope.
• Developer dependency. Merchandising changes that are a click in Shopify admin can become tickets unless the admin is built well.
• Ecosystem. No app store means every integration (marketplaces, feeds, shipping, accounting) is built or bought separately.

Cost shape differs too. Shopify is mostly recurring (plan, apps, transaction costs). Custom is mostly up-front build plus ongoing maintenance. Which is cheaper depends on how many apps you would otherwise stack to approximate your catalog model, so compare against that stack, not against the base plan.

The middle path: Shopify checkout with a custom catalog layer

You do not have to choose all or nothing. A common architecture for large, structured catalogs keeps Shopify for what it does best (cart, checkout, orders, payments) and moves the catalog experience into your own service: product data, compatibility, search and the product pages themselves, served through Shopify's Storefront API.

This removes the biggest pain (modeling and searching a complex catalog) without taking on checkout and compliance. It adds real complexity: two systems to keep consistent, and your own front end to host and maintain. It also does not lift Shopify's variant ceiling on the Shopify side, so the product model you push there still has to fit within it. If you are weighing this route, our eCommerce platform and API integration service covers Shopify development including headless builds and custom apps.

Which one fits your catalog: a decision guide

These are rules of thumb from how the limits above interact, not thresholds published by Shopify:

Migrating a large catalog without losing rankings

Whichever direction you move, the catalog migration is where rankings are lost. Four rules cover most of the risk:

1. Export every live product, collection and content URL first, and build a one-to-one 301 redirect map before launch.
2. Keep URL structure and product slugs stable where you can. Buyers searching part numbers or SKUs land directly on product pages, and a changed slug loses that ranking.
3. Carry over titles, descriptions, canonical tags and structured data, then verify them on staging with a crawl.
4. Re-submit your product feeds and sitemaps the day you cut over, and watch Search Console coverage for the first two weeks.

How to decide in a week

Before you talk to any agency, answer five questions with your own data:

1. What is the largest number of option combinations any single product needs?
2. Does any product need a compatibility or fitment relationship rather than variants?
3. How many price or stock changes arrive per hour at peak, and from which system?
4. Is pricing a list, or is it rules that depend on who is buying?
5. Which system will be the source of truth for the catalog in two years?

If every answer fits inside Shopify's documented limits, build on Shopify and spend the saved budget on search, content and conversion. If two or more answers do not fit, a hybrid or custom build is worth scoping properly. If you want a second opinion on your own catalog, Netalith's custom eCommerce website service is priced to scope and starts from your catalog structure, not from a template.