Glad to help. I hear you, we'd love to put out more benchmarks, but honestly we just don't have enough peopletime to do as much benchmarking as the software de

Glad to help. I hear you, we'd love to put out more benchmarks, but honestly we just don't have enough peopletime to do as much benchmarking as the software deserves, and if you can only put out k benchmarks/month, you'd better be putting out your best k benchmarks. Tim, our VP of Engineering, does most of our official benchmarking, in between project management, support, and testing (and a million other things). Just today (after we posted the TokuMX vs. MongoDB iibench blog), he said something about how he can't do many more of them, it just takes too long for MongoDB to finish the whole benchmark. That's time our servers can't spend testing the new software we're trying to ship. My hope is that now that the code is open, more users will start pounding on it and publishing benchmarks. Justin Swanhart recently posted some great benchmark results where he showed us in a less-than-flattering light: http://shardquery.com/2013/05/25/tokudb-vs-percona-xtradb-using-tokuteks-mariadb-distribution/ http://shardquery.com/2013/05/25/tokudb-vs-percona-xtradb-us.... I haven't studied the workload he ran, but it looked like he may be pointing out some bad query planning behavior and slow cache warmup properties that we should probably address at some point. And that's good for the product and good for the ecosystem, so I am thrilled* that he posted it. I just hope we get 50 more just like it. Anyway, I'm glad you've got a better understanding. Hope you can find a use case for it!