Written format: <a href="https://medium.baqend.com/real-time-databases-explained-why-meteor-rethinkdb-parse-and-firebase-dont-scale-822ff87d2f87" rel="nofollow">https://medium.baqend.com/real-time-databases-explained-why-...</a><p>And the paper for their more scalable alternative: <a href="https://www.cl.cam.ac.uk/~mks40/pubs/vldb_2017.pdf" rel="nofollow">https://www.cl.cam.ac.uk/~mks40/pubs/vldb_2017.pdf</a><p>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.
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.