Product Variant limit external database

Armen_A323
Visitor
3 0 0

Hello

I am new to Shopify. I have read in many forms on your replies so I decided to contact you with an issue that I am facing.

I have a web site called www.mydressline.com and I have many products with variants. Currently I have over 11,500 products with total of over 250,000 variant combination of colors and sizes (only 2 options) most products have less than 100 but around 160 have over. The issue is Shopify limits on variants won’t be possible to move to and Shopify plus is just to expensive for me at $2000 per month. A workaround which I thought about might work so I wanted to hire an expert and see if he or she can do it this and if it is allowed on Shopify to pull or request data from out side source.

Below I have some description as to how I am thinking of doing and solving this variant issue that I have.

We will move all our product information to Shopify but without variations so this will leave us under 50k limit. I am using theme 2.0
On the product page I want to implement a code to call or pull or request (how ever it works) the options for those products and post them on that specific product. We can use Amazon cloud database to call and post on the specific product page using the product title or Handel. It would work similar to how BOLD app options are but with this method we will be able to control our inventory levels and we will not have this limit.

How it will work would be something like this. We would have all of the product information in the Shopify and option will be stored in Amazon cloud database we will then connect that product to this database to pull options for that specific product and post it for the customer to select.

If this is something that can be done please let me know

Thanks

Armen

 

@Jason 

Replies 2 (2)

PaulNewton
Shopify Partner
6275 574 1324

If your a merchant who needs to MVP what I outline below contact me.

 That includes customizations for relating standalone products(flat product model) as if they were still variants of each other.

 

What is the goal here ,why move to shopify if it cannot smoothly mesh with the businesses current product information architecture.

For example if you only care about checkout, this entire problem could be inverted by using the buy-button sdk on existing business websites wherein you only generate products in shopify on demand when customers access them, JIT products; in a way bypassing the 50k+ variant creation behavior or needing to modify shopify themes. And only needing $9/mth for the shopify part.

 

 

Big caveat: the below is ONLY in the context of single channel with the online sales channel(website) having a heavily customized theme.

If you need to be multichannel serious thought needs to be given before implementing a flat product information architecture (i.e. no variant-options just the single default variant that is a product)

If multichannel ,through shopify , dictates variant-options get Shopify Plus for massive inventories.

 

Currently I have over 11,500 products with total of over 250,000 variant combi....  and Shopify plus is just to expensive for me at $2000 per month

Business wise that's a lot of inventory to have that's not capable of generating enough revenue to justify enterprise level conveniences like checkout-discounts, flow automation, increased api limits, etc. If your automatic dropshipping sure why not /shrug ; If not dropshipping you should examine that as a scalability bottleneck first. Before doing any ETL or migration try to streamline things at least even with simple ABC analysis. Large inventories require good investment in marketing, UX, and navigation otherwise your managing a lot of noise.

 

 

@Armen_A323 wrote:

How it will work would be something like this. We would have all of the product information in the Shopify and option will be stored in Amazon cloud database we will then connect that product to this database to pull options for that specific product and post it for the customer to select.

Store the external-options on the product-variants themselves as metafields, or metafield definitions. Then the only left is maintaining sync if for some reason there is a database or store hosted on another platform. Having to make customers-browser fetch external-options for every variant for a 250k inventory is massive perf hit in aggregate.  If your switching to shopify you don't want your legacy factors to be a bottleneck on a platform that can scale. There's also using app-proxies so instead of ajax fetching the options your serving the product render itself, but again performance matters here.

Regardless when supplanting variant-options with some other data any theme you use on shopify will need to be heavily customized and maintained. There are also some themes with features specifically reliant on things like the variant options object, automatically losing theme features.

Technical -  It can be as simple as replacing variant.option with variant.metafield.option1 in templates liquid but alot of themes are over entangled with heavy javascript complicating this. 

 

A flat product-model also means also means any apps based on an assumption of variants will not work off-the-shelf and maybe never will.

 

  1. .. over 11,500 products .. over 250,000 variant combination of colors and sizes (only 2 options)
  2. ..most products have less than 100 but around 160 have over.
  3. ...Shopify limits on variants .
  4. ..move all our product information to Shopify but without variations so this will leave us under 50k limit.
  5. ..I am using theme 2.0 ... product page I want to implement a code to call or pull or request..the options for those products
  6. .. can use Amazon cloud database to call and post on the specific product page using the product title or Handel.
  7. ...similar to how BOLD app options are but with this method we will be able to control our inventory levels and we will not have this limit.

#1 & 2 If an option does not affect an intrinsic property like the price, or sku use line-item properties to get customers option choices.

#3 & 4 Current limit is 100 variants per product, once 50k variants exist on a store there is a daily creation limit of 1k(without shopify Plus) over the api. Note here how every product is 1 variant at minimum.

https://help.shopify.com/en/manual/products/variants/add-variants#:~:text=Stores%20with%2050%2C000%2...

#4 If you have 250K variant combinations (#1) that does equate to being able to be under 50k variants if there is only 1 option per product.

 #5 Crudely https://community.shopify.com/c/shopify-design/product-pages-get-customization-information-for-produ... though that will need to be modified for any themes specific structure.

#6 with the apis you would be using the variant ids under the hood, though really just store the info on shopify and only use something like an amazon DB for sync'ing on a schedule. (I think both parts of this could even be done with an app like usemechanic to skip having to manage your own app infrastructure)

#7 use one app for handling product options and another to sync inventory, or a scriptable app like usemechanic. Doing both in a custom built app is possible but it can be saner to exhaust off-the-shelf solutions by making an MVP with existing apps/services to better crystalize what's needed and why; i.e. build the req's for a custom app.

 

Save time & money ,Ask Questions The Smart Way


Confused? Busy? Get the solution you need paull.newton+shopifyforum@gmail.com


Problem Solved? ✔Accept and Like solutions to help future merchants

Answers powered by coffee Buy Paul a Coffee for more answers or donate to eff.org


parajis
Visitor
2 0 0

Hello Paul, 

I have an art project that I've been doing for years. I wanted to launch my own production on kickstarter in 2019 (website outdated) https://alto.city won't waste your time on the whole story here, the project took a side turn and we ended up building our own metaverse. The metaverse project is still going and it is pretty tough on the budget, and I've noticed that I am getting a ton of native traffic from google (didn't do anything since 2019) so I am revisiting physical product concept now to get some extra income to keep building the metaverse smoothly.

The concept of the project from start is that every city is beautiful to some, therefore all cities must be represented equally. We won't be launching all colours for sure, but if some colors are available for NYC it should also be for some unknown city. So with Shopify or most of the PODs internal product structure if I count 1060 * 10 colours * 10 product types I am not that good already, but often it gets worse, like phone case will have lots of extra variants, or even the paper print with different size options.

Even before learning about 50k Shopify variants limit I didn't like that for my case I would have to upload same designs all over again to different PODs for different products, so potentially taking hundreds of GB per product variant, a total waste of ressources.
For now I see 3 potential options:
1. Create a custom app in Shopify to call my backend to fetch product data, images etc, add some logic on cart and checkout to create products when added to cart only, use shopify checkout and other features. Not sure how much time a product creation will take, not sure about customer experience, not sure about rate limits
2. Create my own website that will be the front office to Shopify - it will handle everything, including checkout and only send valid and paid orders to my Shopify website through api or whatever, this can be enhanced with a solution where I send orders directly to PODs, but I would prefer to make a single API with my Shopify website and let it handle different PODs.
3. Get Shopify plus - we don't really have a budget now (not sure if I can apply with 0 sales neither), but I'am sure it won't be an issue as soon as we start selling. What about overall Shopify performance with a huge collection say of 1 million variants. Sure it will handle it, but probably if I structure my own DB as it makes sense for my project, it will be much faster anyway + it will avoid the unneeded products creation for PODs.

I don't quite like any of these options, right now probably leaning towards 2 or 3. Is there any better solutions today, what would you do ? 

Thanks a lot,
Alex