Other users have answered these pretty well by now, I'd just like to add to the discussion of this question:
>Likewise, I'm confused about how to get around the limitations of mongodb. Say you run a store with a finite inventory, how do you handle concurrent purchases? How about a website to enroll into classes? How about a webforum which can have exactly 5 administrators?
A quick&easy for me has been to just set up a separate REST API to handle critical data like payments and just have a two-server app. Doesn't really add to development time vs a unified server. Meteor doesn't preclude SQL use, it just doesn't support reactive SQL off the shelf like it does Mongo.
It's not cheap and I can't even find a table of content for it. I've also read excerpts that dealt with autopublish etc, and they didn't really address the point I'm making.
Is there a benefit to using meteor beyond the fast prototyping? I'm not saying that's not potentially a huge benefit, but once you're done with your prototype, I still feel like you have to rewrite the whole thing.
Removing autopublish and writing methods is not the same thing as rewriting the whole thing. But if you want to skip autopublish, you can do so from the beginning. As mentioned elsewhere the ability to perform a database action initially on the client allows for latency compensation, which is a significant user benefit beyond fast prototyping.