[joecarpenter]

> Started using the SmartCollections package which ditches polling altogether and goes with the MongoDB OPLOG for synchonization.

Yes, I'm aware about this package. However, in my case, I had to reactively count number of items in collection. SmartCollections does not have `observe` for server-side cursors and core Collection implementation is slow, so I decided to use `setTimeout` to check collection size every few seconds, which turned out to be much faster than generic collection implementation.

> The key thing is you really shouldn't expect to do many MB's of client data storage in your app.

True, it just contradicts point 003 on http://www.meteor.com/

Plus, I was also referring server-side. Application does not work with node.js MongoDB driver, it still goes through thin minimongo layer, which hides most of the driver API. And it is not fast either (due to reactivity) - see insert performance example.

Overall, I don't say it is not possible to run Meteor app in production (I have one). It is just there are alot of different quirks and gotchas in Meteor that should be worked out manually or with help of community-created packages. And all this information is mostly scattered around StackOverflow, Meteor bugtracker or in Meteor source code itself.

It is quite unpleasant to stumble upon collection synchronization performance when you have most of the application in place.