Take the 2-minute tour ×

We are evaluating Meteor for our new generation of enterprise-scale system. One of the amazing built-in features is that every data model in the client is bound to the model in the database and is updated once the server updates. but I'm concerned about the scalability.

What would be the architecture needed to invalidate millions of connected users?

I guess the basic question is how the database is bound to the model on the server and client. Extrapolating more, let's say we have multiple webservers running, and one database. Is it supported? If so, how? If anyone could describe the underlying technology that made it happen, it would help a lot.

I guess this could be a general question for scaling of any web app that uses a reactive model. First, that's true - and any discussion on that is great, too (what's the best design to implement that?).

Second, specifically with Meteor, as it seems more monolithic (in the sense that "everything is done for you"), we are looking for some more visibility to help us see inside (without reading the whole code base) and help us decide.

many thanks, Lior

share|improve this question
Anybody has a new answer of this question now in 2014??? thanx –  ncubica Jun 5 at 9:22

3 Answers 3


Yes, in order to provide convenience for the freshman(this is important for a new project), meteor embed a MongoDB server inside it, when you use "meteor" command to start the web server, it also start a MongoDB server, and its port is two adding the web server's port...it's easy to start. Also, it provide a way to change this behavior, see this question

So, you can share one database between multiple web servers.

As to the second question, as you see, meteor is cool and it is like magic, but there is a price, all magic things have a price, it do a lot for you internally and it's like a black box, in some situation, this will drive you crazy if you don't known what's going on inside it! so if you are thinking use it in a big formal project, be careful! Especially it's too young, even the document is not comprehensive and detailed enough and it's changing quickly and its developers maybe too busy to develop new functionality that they don't have time to answer you question...I'm using meteor in a internal project which don't have restrict requirement, that's fine, a real project for millions user? I don't think it's a good idea right now.

share|improve this answer
thanks @Aaron. That's indeed goes in the same direction I was thinking about. –  Lior Nov 5 '12 at 22:04

David Glasser's answer from the google group:

The short answer is that: if Meteor doesn't scale, any other work we do on the platform will be wasted. The current implementation of the database connector is essentially the original draft of database connector code. It works great for development now, and we're going to make sure that it works great for large scale improvements soon.

share|improve this answer
Smart Collections is the so called improved version. You can use it today. (This is a community contribution, not something in the core) –  Arunoda Susiripala Aug 1 '13 at 16:03

I've working on the Scaling Issues with Meteor and I could able to add some great improvements.

Smart Collections is the core of this. It is a whole new mongodb driver implementation for Meteor.

And Smart Collection does MongoDB Oplog based scaling support. Which is the perfect way to scale meteor apps.

share|improve this answer

Your Answer


