This is an extremely complicated topic, what’s more important than either the number of companies (which will likely grow predicatably), or the number of users (which will likely stay fixed per company), is the number of other entities being stored, and how evenly distributed they are across the companies - this piece is important for scaling/sharding mongo.
Meteor doesn’t play nice with multiple databases - particularly at the user level (i.e., you simply cannot do it at the user level, and still use the accounts packages). You can use multiple DB’s everywhere else, though you’d find the overhead high I think (consider maintaining 1000 DB connections per server because you have 1000 companies). It also makes any type of analytics at your “superuser” level hard - e.g., “how many users do I have” would require querying across many DBs.
The approach we’ve taken is to put everyones data into one DB - every entity has a teamId field. Users have a teamIds field (as they can belong to multiple teams). Then all our indexes include the teamId field. Every method call and publication takes a teamId argument and we check that the logged in user has access to that team, and limit the dataset to that teams data. This means we have one database (+ a separate one for logging) and a fixed number of collections.
Once your data is setup like this, you can shard your database, using teamId as part of the shard key (to ensure all of one teams data exists on the same set of shards). However, at this point you can’t use mongo’s oplog to observe the DB (as oplog doesn’t work with sharded clusters) - so you’ll need redis oplog. Maintaining a sharded database is hard - but migrating from an unsharded database to a sharded one is extremely hard - so I’d advise eating the cost (you need a minimum of 6 servers instead of 3). Also, think hard about your shard key - companyId “works” but as you scale the number of companies, the number of shard sets will also drastically increase. So it may be worth assigning a specific shard (e.g., “us-west” to companies on the west coast). However you’d need to track this + your companyId on every entity.
@paulishca’s point about compliance is also a really big concern - it’s difficult for small non-eu based companies to comply with all the requirements of GDPR - but thats no reason not to comply with the ones where it is possible. Using a sharded DB allows you to store user data in “zones” (e.g., an EU zone).
A good option in terms of “ease” is Mongo Atlas - but it is also exceptionally expensive. Technically it’s only about double the price of AWS direct, but in reality it’s much more, because you have to pay for way higher specs than you need to have the sharding option.
It’s worth noting that my assumption here is you’re going to want to run this as SaaS as opposed to running a single app per company. If your goal is the latter, that would change my advice somewhat - but would also come with its own challenges.