If this has been asked before I apologize but could not find it / don’t know what to search for exactly.
When deploying a meteor (cordova) app to the App Store or Play store, how do you handle configuring a database for each app downloaded by a user? In other words, each app relies on a mongo database. So everytime a user downloads an app, his/her instance of the app will need its own db. There must be an automatic /easy way to do this no?
Apps work just the same as the web, and connect to the database on your meteor server. All users share the same database. You can restrict access using methods or allow/deny-rules.
Or do you want an offline database on the client?
The ground:db package can do that.
Ok thank you. That makes sense. And I guess as more people download the app, you just have to keep increasing your database size?
What if I have a collection “Inventory” that each user stores their inventory in. And maybe each user has 1000 items in the inventory collection. Is there any performance hit lets say if I have 4000 users each with 1000 items in the Inventory collection? Would it be performant to have a 4 million item collection with 4000 different users subscribing to and making changes to their own specific chunk of data?
Sorry for all the questions, I’m a bit of a noob to deploying apps.
I don’t have any experience with large userbases. Lucky for me my app is a business app that will never have more than a hundred or so users on each instance 
My server is mostly idling.
If it’s not 4000 concurrent users it shouldn’t be a problem. Just make sure to add indexes so you can do fast queries for owner ID and such. Also, each user might not have to subscribe to their entire inventory at once (using pagination for example).
As to how many concurrent users you can have, I don’t know actually (and it’ll depend heavily on what you’re doing of course). Does anyone have a link to some load testing results?
Ok. Those numbers were purely hypothetical. I would only have a few users at first (although they would each have several very large collections on the order of 1000 documents). I just want to make sure I’m building it in a way that is scalable.
I’d just like to double check this - do you mean they would each have ~1000 documents in a collection, or they would each have their own collections?
The latter is going to very difficult to sustain in terms of support and maintenance. If you are planning for multi-tenancy it’s much simpler to allow user documents to “mingle” in collections and ensure that only relevant ones are published/made available.
If you’re concerned that MongoDB may struggle with large collections, you should read this:
OK, these are very different data architectures from yours (I’m assuming 
), but they do indicate that it’s very scaleable.
I meant there would be 5 or 6 collections containing 1000’s of documents. And these 5 or 6 collections would be accessed by 1000’s of people.
That article definitely helps answer my question too. That’s pretty amazing.
Awesome. Sounds like a good plan. 