> People wanted RethinkDB to be fast on workloads they actually tried, rather than "real world" workloads we suggested. > For example, they'd write quick s

> People wanted RethinkDB to be fast on workloads they actually tried, rather than "real world" workloads we suggested. > For example, they'd write quick scripts to measure how long it takes to insert ten thousand documents without ever reading them back. > MongoDB mastered these workloads brilliantly, while we fought the losing battle of educating the market. I was one of the people who did this and I'd like to provide you another take away: Don't tell people what "real world" workloads are. They know better than you do. When I presented my performance testing scripts to you guys it was a replication of our real world workload. Trying to explain to someone that their workload isn't "real world" hurts the confidence in the system. Its better to either say that isn't a workload you are optimized for or that you are working on it. That being said, I'm now building a start-up and using RethinkDB because it is the best system out there! My performance requirements for a start-up are significantly different than the billion dollar survey company I used to work for ;) But I'd also like to commend you on the performance you've achieved with RethinkDB in general, it has come a long way and any company would be happy to hit the scale that RethinkDB has issues with!