Multitenancy solutions

#1

Hi,
What a cool forum I found. :+1:

When we building a SaaS app, we need to make them multitenancy. I want to know which solution you prefer and why for your project.

  1. Separated database for each tenant
  2. One database for all tenants and use on each table ‘tenant_id’

I prefer one database for all tenants, because is easy to support.

1 Like
#2

I remember I was researching this question and it’s not that trivial.
For example, if it’s okay to have one domain for all companies, if it’s not a big database like CRM, I’d say it’s okay to have one database

But when you need something like “mycompany.site.com”, when it’s a CRM with sensitive data, I’d stick to separate database. Don’t have experience in this, but I think this is how it’s done.

I have bookmarks related to this, maybe it’d be infromative for you:

https://discuss.emberjs.com/t/multi-tenant-app/9438/3
https://hackernoon.com/simple-multi-tenancy-with-laravel-b3f84fc13c39
https://hackernoon.com/exploring-single-tenant-architectures-57c64e99eece
https://stackoverflow.com/questions/44550814/laravel-5-4-multi-tenant-migrations-switching-connections-for-migrations
https://hackernoon.com/abstract-upgrade-command-for-multi-tenant-71089b9a838f

https://craig.sans.am/2017/09/02/multi-tenancy-in-laravel-5-5/ (looks like it’s dead)

2 Likes
#3

Thanks for the info Victor.

#4

Several days ago I found this video: https://www.youtube.com/watch?v=fuDZq-EspNA
it is very AWS specific but generally provides some ideas.

Now regarding multitenancy, in general, there are couple options:

  • tenant_id
  • separately launched apps with their resources
  • I’ve seen people use PostgreSQL schemas or something to separate everyone in a single DB.

There can also be mixed solutions when you have pools of users in single apps, it is a mix of tenant_id based approach and separate apps. It is useful from an economic point of view. By putting multiple small projects to run on a single set of resources you optimize costs.

Same approach can be useful when you allow customers to select the region. You can have tenant_id based separation in NYC, SFO, Asia, Europe.

https://frontapp.com/ on their podcast said they use separate S3 buckets for every customer.
https://softwareengineeringdaily.com/2018/09/24/front-engineering-with-laurent-perrin/ Very insightful, I totally recommend to listen to this.

With https://appliku.com/ I use a tenant_id approach but only on main entities – application and servers. The rest of the data is tied to one of these objects anyway.

It all depends on the app, the usage pattern, amount of data stored, and processed.
in some cases, you just obligated to run each tenant separately by contract or regulation of some kind.
Also business model/pricing model dictates certain approach. If you make self-service solution for low cost of each tenant – you need to minimize costs of running the app.
If you have enterprise sales approach and have huge ARPU then at least you can afford having totally separate set of resources(read: run a separate instance of the app).
Keep in mind that managing fleet of separate apps is a whole different story from a single app with many tenants.

Hope this helps.

3 Likes
#5

Thanks Konstantin. Very useful info.