Django multi tenancy (for SaaS-app)

[daviddep]

How would you achieve multi-tenancy using Django? I really wanna stick with Python/Django, but Rails seems way more mature when it comes to building a SaaS-app. Any help would be deeply appreciated.

[limedaring]

Why do you say Rails is more mature? I would argue that they are functionally similar. What does Rails give that Django doesn’t?

(Not trying to be argumentative, I’m really just curious!)

[daviddep]

Haha, that’s okay. I find Rails more mature in the SaaS space. Try doing a couple of quick google searches and compare the results. Tons of tutorials show up for Rails. But what about Django? Not a single one. (I googled SaaS and then the framework)

But do you know a smart and pythonic way to achieve multi-tenancy for a Django SaaS app? I’d love to hear it! Thank you for taking the time to reply.

[limedaring]

SaaS apps are essentially any online app and I think lack of tutorials specifically about the acronym doesn’t mean that you can’t do it. :) My startup, WeddingLovely (http://weddinglovely.com) for example is built on Django and it’s a SaaS app. Pretty much what you’d need (login, services, etc) should all be able to be built using Django/Python just as well as Rails/Ruby. :)

So, all that said — I don’t have experience mixing languages so I don’t know the answer to your questions, but I’ll share this thread and hopefully someone can pop in with ideas. :)

[shazow]

@daviddep Don’t be afraid to try out Rails if you feel you relate to that platform better. Many of my best friends are avid Ruby lovers and just don’t relate to Python the way I can’t relate to Ruby. :)

Regarding multi-tenancy, it’s a matter of how you design your models. There are a few middlewares which help you manage multiple domains if that’s what you have in mind: https://stackoverflow.com/questions/21771345/multi-tenant-saas-in-django

[daviddep]

I see… My biggest headache right now is just that I can’t figure out how to give users their own “space”. You know, letting them have their own dashboards that only they can access.

Love this community, thanks @limedaring for building it.

[shazow]

So let’s say you have a Dashboard model object, right? If you add a user relation to it (which points to a Profile model, for example), you can treat that user as the “owner” of the Dashboard. Now you can have many dashboards, each owned by a different user.

[daviddep]

I love Python. I just thought Rails would be a better choice for this particular case. I see now, that I was wrong ;)

[daviddep]

Should I create that relation using a ForeignKey e.g?

[limedaring]

I basically do that with WeddingLovely — to build upon what @shazow said, all the “interior” views are logged-in-user only and I check to make sure that they’re the owner of whatever they’re looking at. It’s pretty easy with Django to restrict views like that.

Glad this helped! I do agree that Rails has a LOT more tutorials, one of the reasons why I wrote Hello Web App. But you can definitely do in Django/Python what you can do in Rails. :)

[shazow]

Should I create that relation using a ForeignKey e.g?

Yup, you’re on the right track!

[willgriggs]

Hi, this is my first post here. I found your site when I was searching for how to create a multi tenant app with Django.

If creating the site with one database and separating tenants using the foreign key method, what would be the limitations in terms of number of tenants before the app starts to become slow or unmanageable. I mean when would it make sense to separate tenants using the foreign key method as opposed to implementing separate schemas or separate databases?

My app would allow companies to:
Upload and share documents
Maintain company information in predefined tables
Collaborate with users (about 1 - 5 users per tenants)
Send emails/messages to eachother
CMS functionality to publish simple company webpage

The app im about to create will be considered successful if I can get 100 - 200 paying users, and max potensial users would be around 1000.

[shazow]

Hi @willgriggs,

Each approach has advantages and disadvantages, but I would default to doing things in a single database and segmenting users by foreign key.

The way to keep your queries fast is to have appropriate indexes on your tables. This can be its own craft and will take some learning.

If you go with separate schemas or databases:

• You’ll still need good indexes on your tables, that’s not avoidable.
• Doing queries that span multiple databases is trickier. (For example, if you want to have an admin panel that gives you an overview of your business.)
• By separating databases, you move complexity from your application layer to your deployment setup. You could setup separate credentials for separate app instances and reduce the risk of the wrong account accessing the wrong data, but it’s a fair bit more devops-type work.
• It’s somewhat easier to migrate one account to a different machine, if that’s something you might need to do often.

In general, for beginners, I’d say it’s safer to go the foreign key approach just because you’ll need to learn a small subset of things and run into fewer confusing challenges along the way.

Also, regarding your scale, databases are built to handle many millions of records. Don’t worry about that too much. :)

Also there are always managed database options like Amazon RDS or Google Cloud SQL. You’ll still be responsible for choosing good indexes, but they’ll take care of provisioning and making sure it doesn’t run out of memory, backups and such.

Good luck!

[willgriggs]

Thanks for your advise shazow. After reading your reply I’ve decided to go the foreign key route.
I’ll do some reading on indexing as I have no experience with it at all :)