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?

Comments

[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

[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

[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 ......

[Grant]

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