How to achieve multi-tenancy?

If you'll plan to have a large number of clients, database level tenancy will be hard to maintain, the migrations will be very slow and messy(it will require full attention), logging might also cause issues... at least that's my experience on Rails.

Now we're using row level tenancy for 1.5 years and works much better.

db level for sure is the exception , most saas solutions will implement it on a per row level.
customer.yourapp.com does not impact above

I do this at the database level and use a wildcard subdomain where the database name is the subdomain part

db.domain.com

Advantages:

client's data is isolated and performs as well as possible as tables don't grow larger based on other customers

can upgrade clients in increments

Disadvantages:
Migrations have to be scripted and it generally more invovled

Over a decade I have worked on multi-tenant applications. I have implemented applications using on all the methods

• One DB per tenant
• One schema (Check out SQLServer and Postgres) per tenant on a single DB
• One DB with row level controls

I would suggest you to go with row level as it is easy and quick to implement. You can do it with any DB.

Doing with multiple DB's will require more human and server resources to develop, maintain and monitor applications.

Hope this helps.

A good question, was on my table 3-4 months ago (side project wise, handle it day job wise a bit different, other story ;-))
I wrote an article about that back then:

https://dev.to/golangch/confession-how-i-got-my-piece-of-saas-multi-tenant-2m7p

You should strongly consider Postgres Schemas for this. It's like having db-level tenancy for your customers, but a single-db for your backup strategy. Postgres pretty much allows you having multiple schemas into one database. Each schema, is a layer on top of a set of tables, so it pretty much functions as a separate DB, kind of.
They way you work with it, is that you have the SAME consistent commands for accessing the db, but before you do so, you 'activate' one schema. Hence, your code does not even have to consider the tenant. You use each schema as a standalone DB, and you only need a layer prior any db access to enable the proper schema based on the user logged in.

If you are on Django by any chance, all these can happen pretty automatically, by using django-tenant-schemas

There are a few I was looking to use as starters few months back...sharing the repo's here. My 2 cents, choice of db level or schema level depends on your business model and what kind of clients you wish to target(large enterprises do tend to ask for db level isolation, security and redundancy) so going for a lean schema(row-level) level isolation when you don't have paying customers makes sense cause its cheap, but do cater for migration possibilities once you have a mid-large enterprise ;)

1. https://github.com/Shyam-Chen/Express-Starter
2. https://github.com/aloysius-tim/saas-react-starter-kit-boilerplate
3. https://github.com/aloysius-tim/saas-react-starter-kit-boilerplate

I've built large CRM/ERP systems (several hundred database tables) for franchises where each franchisee needs to only see their own data. Over the years I've done both database-level and row-level with different systems, but personally I feel strongly that row-level has significant advantages regarding ease of schema updates and verification and regression testing. For these systems we're only talking about 60 or so tenants. I would imagine even more complexity and headache if thousands of tenants were involved.

And while there is conceptually more potential security in a database-level setup, I've found row-level to be quite secure as well especially with core level permission safeguards so that a tenant can only see data linked to that tenant.

I'm rolling with row level for my app right now, it feels much easier to develop for and easier to maintain. It requires some thoughtfulness while developing as there will always be the possibility of allowing access to the wrong things, but authorization is a less complex problem than multi-tenancy in general.

If you develop using Rails there is apartment (https://github.com/influitive/apartment) as the go-to multi-tenancy solution, it uses databases though.