
Real-Time Databases Explained: Why Meteor, Rethink, Parse and Firebase Don't Scale - DivineTraube
https://m.youtube.com/watch?v=HiQgQ88AdYo
======
btown
Written format: [https://medium.baqend.com/real-time-databases-explained-
why-...](https://medium.baqend.com/real-time-databases-explained-why-meteor-
rethinkdb-parse-and-firebase-dont-scale-822ff87d2f87)

And the paper for their more scalable alternative:
[https://www.cl.cam.ac.uk/~mks40/pubs/vldb_2017.pdf](https://www.cl.cam.ac.uk/~mks40/pubs/vldb_2017.pdf)

The devil will absolutely be in the details, but the speaker/author identifies
a real pain point that bolting on a replication-log tailing system to provide
realtime capabilities results in numerous write bottlenecks unless the system
is architected from scratch to avoid them.

------
code-is-code
Meteor has the op-log-driver which calculates query-result for changes instead
of running the wohle query again. Same comes with rxdb where it's called
query-change-detection.

~~~
wolle
That's true, but monitoring the stream of change events in a single machine
(be it server or client) makes this machine your bottleneck for overall system
throughput.

