I thought there were 25 options for each of 25 products. Not sure why.

As for the rest, I still don't grasp the options, I guess. You say "10 possible primary options" but by using the word "possible" I can't tell what's required - all 10 or some of the 10. If there are 10 base options that have to be chosen, then that is one item/possibility/record. If some but not all can be chosen, then it is some other number, based on Combinations, Permutations or it's factorial (which is what I was getting at although it wouldn't start at 25) or it's some other number. If each one of those possibilities has 10 more possibilities, it is one thing if it applies to that 'one' record previously mentioned . I think it's an entirely different matter if

__each one__ of 10 base options has anywhere from 0 to 10 options and they're not dependent on each other.

Using your example with 3 products, 3 primary and 3 secondary options it should be 3x3x3 = 27. Consider the following

Prod |
Popt |
Sopt |

A |
1 |
X |

B |
2 |
Y |

C |
3 |
Z |

If I've done the relationships correct (matches your situation) I get 36 possibilites

A1 |

A2 |

A3 |

A1X |

A2X |

A3X |

A1Y |

A2Y |

A3Y |

A1Z |

A2Z |

A3Z |

B1 |

B2 |

B3 |

B1X |

B2X |

B3X |

B1Y |

B2Y |

B3Y |

B1Z |

B2Z |

B3Z |

C1 |

C2 |

C3 |

C1X |

C2X |

C3X |

C1Y |

C2Y |

C3Y |

C1Z |

C2Z |

C3Z |

Imagine the extra combinations when dealing with 25, 10 and 10. Ok, so if my understanding of the combinations isn't correct, then it doesn't really matter. May not matter even if I do. The important thing is whether or not your design question was answered since it's unlikely that every possible combination would ever be ordered. People are not likely to order every possible combination under the sun.

As for the other db size, there are factors which can influence the file size between different db's with the same number of records so it might give you some idea of what you'll end up with, but it doesn't mean that 700,000 records will be 500Mb.