
Real-Time Databases Explained: Why Meteor, Rethink, Parse and Firebase Don’t Scale - DivineTraube
https://medium.com/baqend-blog/real-time-databases-explained-why-meteor-rethinkdb-parse-and-firebase-dont-scale-822ff87d2f87
======
dkarapetyan
If the problem you are solving doesn't map to being embarrassingly parallel
then you will indeed have problems. This is not restricted to just "real-
time", or more technically streaming DBs. Coordination has high overhead no
matter what DB you are using.

Also, I don't see how their design avoids hot keyspace issues. Traditionally
this is the main problem with partitioned designs because you move the problem
one level up to properly designing the key that will be used to distribute the
load across partitions.

------
voidmain
This approach is "scalable" in the sense of partitionable, but it's still
O(N^2)! Needing 9x the servers for 3x the users is not really "scalable" in
the colloquial sense.

An often more attractive approach is to partition over the keys of each
database index.

