DEV Community

Grant
Grant

Posted on

Multi or single-tenancy?

I have an idea I'm excited about for a Human Resources (HRIS/HRM) SaaS project. I'm doing some light planning and prepping.

The question I can't quite answer is how should I manage the tenants. I'm leaning single-tenancy. In my mind here's how it would go...

When someone signs up, it would automate creating a server instance and install/configure/deploy the application. They are isolated from other tenants in every sense, given a server geographically beneficial to them, [insert other benefits of being single tenant]. They get their own subdomain (also possible with multi-tenancy) or could point their own domain to that server (branding to an extent is also possible with multi-tenancy).

There would be a central server to manage the subscriptions/accounts, but it could also be managed from their own server talking to the said "central" server.

Does anyone have anecdotes of doing single vs multi-tenancy? Is this too much work? A silly idea? Too ambitious?

Top comments (4)

Collapse
 
zspine profile image
M#3

Interesting... with either of them there are pros and cons, and I would recommend you to read this discussion.

I have implemented 'A shared database, shared schema' with the flexibility to isolate on demand based on selected plan.

DATABASE_1

tenants
  1. id
  2. db_name
  3. db_user
  4. db_pass
  5. db_server
  6. db_shared [bool]
  7. db_region [eu, us..]
  8. domain
  9. plan
tenant_users
  1. id
  2. email
  3. password
  • (user will be copied to the app_users table during the sign-up process with ROLE_OWNER)

DATABASE_2 (just an example)

app_users
  1. id
  2. tenant_id
  3. email
  4. password
  5. roles
app_countries
  1. id
  2. tenant_id
  3. name
Collapse
 
grantholle profile image
Grant

Thanks for this example and link. I feel like there's a lot of sides and each has their merit... probably not a "wrong" answer

Collapse
 
zspine profile image
M#3

:) haa haaa SORRY I forgot to mention the whole server instance part and my answer seems out of sync with the question! I think it's not much different from one database for one tenant. But maintenance would be a big headache (again it depends on your resources and requirement). You have to consider things like:

  1. Log Handling
  2. Up time monitoring
  3. Application updates
  4. Server specif errors etc ......
Thread Thread
 
grantholle profile image
Grant

Yeah that's the kind of stuff I was thinking about as well: the peripheral things for the application. Great point