Multi-Tenancy for a SaaS – Best Approach?

[bronze raft]

I'm building a Django-based SaaS that handles sensitive business data, so strict data isolation is crucial. I need an approach that prevents data leaks, scales efficiently, and keeps costs manageable. I'm debating single-tenant (separate DBs), multi-tenant (shared schema with tenant_id), or hybrid (shared DB with separate schemas). I’m leaning toward multi tenet for its scalbality, low cost, and simplicity which i think is key, but worry about query safety, compliance, and performance at scale when handline lots of requests coming to the RDS. For those with experience building multi-tenant Django apps, what approach worked best for you and why?

[prime pawn]

I have some experience building this with your multi-tenant approach, basically everything in one database and with a shared schema, making sure all data somehow is attached to a tenant_id (unless considered "common" or "shared" between tenants). It is definitely doable and not as daunting as you may think as long as you carefully design the schema and support your crucial queries etc. with tests to make sure things don't get mixed up.

I had to work with a system before that used separate databases per tenant before, and making changes to the db schema was so complicated because of that it really hindered development. I think I'd always go for an approach that makes sure schema changes and migrations are somewhat easy to do, with the downside of having to be a bit more careful about separating datasets between tenants on my own instead of having some hard technical barrier between them.

I remember this being an interesting insight into SaaS architecture involving a multi-tenant approach:

• https://blog.sentry.io/how-to-build-saas-application/
• https://www.youtube.com/watch?v=W1fkGyIcePA

[bronze raft]

Thanks for the advice 😁

[icy valley]

mildly curious (I've never done anything like this): why was making changes to the db schema was so complicated? I guess you'd need to, in effect, do a separate deployment for each tenant, whenever the schema changes?

[bronze raft]

I watched the video and its very helpful!

[prime pawn]

Oh it was a little worse, "databases" where basically dumped .sql files scattered around network folders, so there was no centralized way to update them to a current schema, it would happen on loading a file based on migration scripts within the database client software, a Qt desktop app.

That would have been better with one server that had all the databases on it side by side, but you could still end up with some of them updated and some not, I don't really like that concept. You also often want to share some data between tenants and in that case that would have had to go to an extra special case database that the tenant's client would have to connect to in addition. This is all simpler when within the same single database.