Ah I see. Yes it can become a big issue to have 1 database per customer and just 1 application for all customers. Its because of how Meteor (and other platforms that use sockets and in memory collections / caches) deal with collections. This can however easily be overcome by putting namespaces. My recommendation is always to use a slug form client abbreviation. For example: If Google would be your customer, its going to be
google. You might want to abbreviate long names to prevent database limitations regarding character limit: Facebook becomes
1 Database per customer is perfectly fine. The time spent is then usually on the DevOps side. For example if you want a customer to register itself it has to automatically generate that database and connection etc etc.
For as far as the bottleneck counts. Keep in mind that it should be possible to horizontally scale your Meteor app. If 1 customer requires a lot of resources, it might cause other customers to experience delays.
I think that you might want to stick to the 1 database and meteor app per customer approach. Just spent your time on continuous integration workflows! Automate the build and deployment steps of your app so that each application will be updated automatically after a commit / push to your repository. This will remove all complexity from the app side, because they become dedicated to 1 customer. That is unless you want to have some sort of global admin login functionality. However, that's still possible.