Meteor multitenancy solution


#1

Hey guys. I’m fairly new to multi tenancy and I have following solution for my app. Would like to hear your thoughts if it sounds right and scalable.

Right, so each tenant would have its own instance of database. My client app and admin app would have a connection to master database which then would have a databases collection. On user login appropriate database would be selected according to user ‘company-id’ field or something like that. The app is set up so its only accessible on login, so straight after login appropriate database should be selected.

Question: is it possible to start a new instance of database from the app, or would I have to do it manually?

I’ve read quite a few topics on meteor multi tenancy but couldnt find a clear solution… Any thoughts and ideas are highly appreciated!

Thank you


#2

Why would you have a separate database per client? In general that should not be needed. You can just filter the data in the publications and secure inserts in methods. See the guide one security for more details.


#3

I need database per client because I expect up to a 1000 clients and each client might have up to 5000 records in a db, that is about 5,000,000 records. If I load some 50,000 test records and limit it to 25 per page it slows down the whole app quite noticeably… I expect that separate databases would reduce the load


#4

5,000,000 records is a small database. The most likely reason for poor performance is not having good indexes.


#5
  • it’s not really multi tenancy if each client has it’s own database. If that’s your approach, you’re probably better of running a separate instance of the entire app for each client.

#6

hm, so better solution would be to use collection per user? If I run a separate instance of entire app, I would have 1000 instances of apps and what if I need to push an update to all of them?


#7

And regarding indexes, yes I’m indexing whole main collection with settings like that:

Collection._ensureIndex({
	'$**': 'text'
});

otherwise if I limit to certain fields it only allows 6 or 7 fields to index?


#8

I’d use a tenant identifier per document (e.g. a companyId field on each doc) rather than a collection per user.


#9

The official words are here.

The wildcard index policy you are using is for ad-hoc searching of text fields, it does not mean you have correctly indexed your collection(s).


#10

Thanks for the link, will read on that! What would you guys call a big database if 5mln records is a small database? I actually meant 5mln documents, each document has more or less 22 fields and 4 of those fields are arrays and might have up to 20 objects each… Is it still a small database?


#11

I’d call these pretty big!


#12

millions of operations per second on over 100 billion documents. Right, then I might just fit into one database lol. Thank you all for pointing me to the right direction!