I've had some demanding requirements for product variations and I've found huge limitations in Woocommerce and wpcommerce. I'd like to outline how you can handle large numbers of product variations without the limitations of these packages.
Let's define some terms. By a variant I mean a single product characteristic for which the product is available with different values. For example, flavor could be such a variant, available in, say, chocolate or vanilla. A single product may have a number of variants, say, size and color.
A product variation is a specific combination of values of variants for which the product is available, such as large blue. A product variation is described by a single value for each variant.
OK, now let's look at ecommerce problems. Some products have just a few variations, and some have many variations. Your plugin needs to handle all of these reasonably with a reasonable amount of work to set it up.
In any case, the user is usually given a dropdown for the variants, and chooses a combination of them and can then purchase the item. If there are a small number of variations, the complete variations could be listed and the user could choose one of them.
For products that have multiple variants, they fall into two categories. Some I call complete --that is, the product is available with all combinations of all variants. This could be the case, for example, for contact lenses, that have several variants and a large number of values for each of them. I use the term incomplete for products that are not available for all combinations of variants--or may have different prices for some variations.
For a product with incomplete variations, you can have the designer enter all of the values for each variant, then generate all of the combinations, and allow the designer to delete combinations and edit prices. For example, if jeans are available in XXXL size but not all lengths, and if the price of the XXXL is higher, this can be handled by generating all of the variations and allowing the designer to edit the generated variations. In this case, a database row is stored for each variation.
The database approach does not work for products with large numbers of variations. These are typically complete, and all have the same price, so the variations can be generated and they will not have to be edited. Or, better still, instead of generating and storing thousands of variations, store just the variants, and generate the variation that the purchaser chooses. This way you don't have the generation process at all. This approach works only for products with complete variations, but for those it works fine.
An example of complete variations is contact lenses, which may have 5,000 variations for the more complex products. And a company selling contact lenses will have dozens of different products, so setting up and generating the variations for all the products would be a burden, especially compared with simply entering the variants and their values.
I had another case of chocolate assortments; my client wanted to allow their purchaser to choose one of ten flavors six times--a box of 36 chocolates then could have as many as 6 different flavors. Needless to say, this produced 1,000,000 product variations! There was no way to handle it, and the choices had to be reduced. This reduced the sophistication of the product that could be delivered, and my client was not happy.
My own experience with wpcommerce is that above about 2500 variations it becomes very difficult, even if the limits on the Web server are adjusted. Without tuning the Web server, the upper limit is more like 500 variations.
The problem for your developers is how to provide the flexibility required for incomplete product variations, that are common for products with smaller numbers of variations, while still allowing for large numbers of product variations, that are usually complete. I think the best approach is to allow the designer to choose for each product whether product variations are to be generated and stored in advance--which allows them to be edited--or generated at the time of selection, which allows essentially an unlimited number of product variations. This results in an alternative about how the product variation is formed and delivered to the purchase process; but the same form of product variation can be delivered in both cases.
I think that if you built a product variation capability that had the ability to generate variations dynamically from the values of variants selected by a purchaser you would have a unique capability that people are looking for. And it can be done along with a more conventional generate-edit-store approach for product variations.