Jon James in an article looking at the scalability of the Meteor framework, which uses MongoDB as its database:
Meteor is all real-time, which it currently achieves by fetching and
comparing documents after every database write operation. Meteor also polls
the database for changes every 10 seconds. These are the main bottlenecks
when scaling Meteor, and they introduce two main issues:
- The polling and comparing logic takes a lot of CPU power and network I/O.
- After a write operation, there is no way to propagate changes to other
Meteor instances in real-time. Changes will only be noticed the next time
Meteor polls (~10 seconds).
While from a developer’s perspective getting automatic updates is probably a pretty cool feature, polling a database is not going to get them very far. The author suggests using MongoDB’s opslog as a source of changes. That could work.
Original title and link: Does Meteor scale? Polling for changes in MongoDB