loading...

Multi or single-tenancy?

grantholle profile image Grant ・1 min read

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?

Posted on Apr 29 by:

grantholle profile

Grant

@grantholle

Currently living in Tianjin, PRC.

Discussion

markdown guide
 

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
 

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

 

:) 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 ......

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