Slava @ RethinkDB here.

We're working hard on fixing every bug and performance issue in the system, so the explanation below isn't meant to shirk responsibility. That being said...

Every large system (including the Linux kernel, MySQL, Postgres, etc.) has a large number of bugs lurking under the hood. These bugs are often edge case scenarios that are specific to a given workload, hardware/software configuration, or some other aspects of a given user's system. I'd be careful about looking at the tracker and drawing conclusions -- in my experience bugs like these aren't representative of the overall experience of using the product. (That's not to say that RethinkDB is as stable the Linux kernel, I'm just using that to illustrate that bugs are unavoidable and don't necessarily color the experience of the average user).

Again I wanted to give a different perspective from the POV of a maintain of a large project. We're always working on fixing all important issues that prevent people from using Rethink, so I don't mean to imply in any way that we aren't responsible for these.

Of course. :)

I don't mean to imply you weren't working hard or that these bugs were unusual for any complex project. I'm just getting the impression that the current version of RethinkDB you end up scaling like this if you were attempting to be safe:

1) Get to 5-9 Nodes

2) Vertically scale this cluster.

3) Shard via adding additional clusters [e.g. 5 Clusters of 7 Nodes] since ~30 nodes for certain workloads you run into performance issues.

Not quite true -- there are many deployments with >30 nodes in the wild. Some deployments with >30 nodes did run into issues, but I think a lot of that is extremely user-specific (and if you get to that level, RethinkDB engineers will help with all the custom issues you might run into).

Fair enough, thanks. :)