Defining "X has too many options"

This is another post in my Well, actually series. Sadly, I didn't think of naming that series until now so the previous posts might take a while to identify.

This post is inspired by the claims I read that RocksDB has too many options. I agree that it does, but the claim is true for every database that I have used.

This claim is too vague. I can make it less vague via multiple levels:

• level 0 - X has too many options and they all matter
• level 1 - X has too many options and the ones that matter change based the workload. Figuring out which options matter per workload can be expensive.
• level 2 - X has too many options but only a small subset matters regardless of workload. Figuring out which options matter here can be expensive but is usually a one time cost. I have done some option sensitivity analysis benchmarks for MyRocks and RocksDB.
• level 3 - X has too many options but none of them matter

Any system in level 0 is going to be a problem. RocksDB is between levels 1 and level 2. For me it is closest to level 2. A few blog posts that cover basic configuration are here and here.