Multi tenant application in django


(Mark) #1

I am working on an application where I will need to backup databases separately for each client and generally separate clients from each other. I was looking for a solution and found the term “Multi tenant applications”. Did anyone deal with this approach to building SaaS? Is this something difficult?
I would ask for an opinion, hint, what approach is good for a young application. I saw three approaches there:

  • Shared database with shared schema
  • Shared database with isolated schema
  • Isolated database with a shared app server

(Cleiton Lima) #2

I have a SaaS application with 500 tenants.
I currently use the library django-tenant-schemas, where I have 1 database with multiple schemas.

My difficulty today is to get information from all tenants, queries become very slow because the navigation in each schemas. Backups and migrations become very slow as well.
My problem is similar to that:

As I need this information quickly, I think I will migrate to 1 database where I will have a tenant table and the other tables with tenant_id (shared tables not have id).

I would like to see other testimonials on this.

Sorry for my english!! :see_no_evil:


(Mark) #3

Hi Cleiton,

Thank you for your post and your experiences.
What do you think it wouldn’t be better if the databases were separate? Then it would be better to manage clients and their content, for example - to make dedicated backups only for a specific client?


(Thomas Lionel Smets) #4

Why use tenant extension instead of sites framework ?
Similar but not identical, what are the pro’s & con’s ?

\T,


(Cleiton Lima) #5

If your clients need to have the same database structure, migrating to each database can be a problem. Imagine a migration fails, some databases are updated and some not. Is a problem to be faced.

If the databases have information that needs to be shared, different database is not a good option.

That is my opinion, depending on need may be good or not. :slight_smile:


(Cory Zue) #6

Personally I like doing it in the application layer (shared database). Basically a single tenant table and then ~every other model foreign keys to that. It means you need to do some extra work to handle permissions and such but it makes deployment a lot simpler, makes it easier and more performant to do cross-tenant operations, and sets you up to much more easily handle edge cases down the line (e.g. what if the same user needs access to two different organizations?).


(Mark) #7

Thank you for your post. Do you mean “shared database with shared schema”?
I want a simple solution to quickly put a new code on live.
In my case, the user will not be able to move between organizations.

Can you tell me if it is possible to backup any organization in this extract?
For example:
Organization 1 - needs yesterday’s backup
Organization 2 - needs a backup from two weeks ago.

Is this possible?


(Cory Zue) #8

Sorry, yes to “shared database with shared schema”.

That said, if one of your requirements is that organizations need access to their own database backups then I would definitely change my answer to either separate databases or using django-tenant-schemas as Cleiton already suggested because managing that with a shared schema and DB would be a disaster. My note was more for general multi-tenant SaaS apps.


(Mark) #9

OK, we are talking all the time about an external solution - a package.
Is it better to use a ready-made package or write this solution yourself?
Then we can be sure that it will not stay with anything when the outer package is no longer being developed…


(Néstor Díaz Valencia) #10

I went down the “shared database” path and I think I will never come back. Except maybe if “split” methods are taken into account from the begining.
You got this small users that pay you little and then you have this big user that pay you a lot and need better performance. Yous should be able to easily split this vip customer to another better isolated system.


(Néstor Díaz Valencia) #11

May be I was not clear: my experience of 6 years with a shared dabase django application for multiple tenants was not good in the last 3 years.


(Cory Zue) #12

Is it better to use a ready-made package or write this solution yourself?

This is almost impossible to answer without more information. Some packages are very well maintained and far more comprehensive than anything you could write yourself. While others might be written by a single person and be unsupported in the long term. I’d recommend you evaluate the package carefully (e.g. # of contributors, how long it has been around, etc.) and make the call based on that.


(Vitor Freitas) #13

That’s a good point. I never really thought about using the sites framework as a multi-tenant option. But I guess it depends on the use case.

I think the sites framework is intended to be used when the tenants are known to the developer (e.g., the Lawrence news sites where Django was developer).

A custom multi-tenant extension/self made solution is for when the tenants are unknown to the developer. New customers/tenants are acquired dynamically. The sites framework rely on setting the SITE_ID and setting a new domain, so that would limit a little bit on what you can do.


(Vitor Freitas) #14

That’s a really good insight. Thanks for sharing your experience. That’s a good thing to keep in mind when choosing multiple schemas.


(Vitor Freitas) #15

In addition to those strategies I would say there is also a mixed approach using shared database with shared schema divided in clusters.

I think that’s what MailChimp does. Their tenants doesn’t really need to share any resource between themselves, so they could be isolated in different schemas. But then the maintenance issues @Cleiton mentioned kicks in, due to their volume.

I’ve seen they use different subdomains, like:

Since the tenants can be isolated, you can break down your tenants in different clusters. 10~ clusters should be easier to manage than thousands of schemas.

So the idea would be having an implementation like @czue mentioned, using a tenant table and adding foreign key to the resources etc. But then you can have multiple isolated databases where you would spread your customers to balance the load.

This would also sort of deal with the issue @n3storm mentioned. You can have some powerful clusters for the big customers and so on. Also balancing the load, and doing the split on sign up, this kind of thing.


(Thomas Lionel Smets) #16

The idea is more to create a Site, says a Social media for Companies. Of course every companies want only its personnel to access it … Once the Contract is signed-off, the site (SITE_ID) is created (and configured).


(Thomas Lionel Smets) #17

@Cleiton
Nothing forbids you to have 2 versions of the app installed Version N & Version N+1. As the schema gets migrated, the tenants are moved from one instance to the other.
Of course when migration goes off-course, you need to restore the schema & see what caused the migration issue.
It is a pitty the multi tenant does not hold its promesses of performances as this is REALLY a nice technical approach … I reckon it deserves further improvement.
I would assume that the slowness comes from the fact that the more tenant, the less likely you are to hit the EXECUTION PLAN Cache and therefore, you lose the performance gain as the Cache gets less & less frequently hits.