I’m from Brazil, So I apologize in advance for any English mistakes.
Someone that uses django in production as an SaaS can explain to me how you are doing your multitenancy?
I’m a pleno dev and I doesn’t have any idea of the ideal way of do this. In the company where I work, we have one database per client, which every JWT token has the database name, so we get this in the middleware and change the DATABASE_NAME in every request.
I’m also developing a lib called django-islands that implements a tenant_id column and in every database query an WHERE clause is added in the end of the query.
This options above are good? I’m creating this card more because I don’t know of any library that implements the multitenancy process, even though it is an extremely common and necessary process.
Data that is unique per customer has a foreign key so you can know which customer it belongs to. Then you filter on that fk everywhere.
I think the reason there aren’t many libraries is that it’s a common pattern, but the details will depend on the business rules. In other words: general systems will not work for most businesses as they have specific needs.
Hello there!
Greetings from Brazil as well!
There are a lot of known approaches for multi-tenancy. I’ve never used this separated-database approach before, but it makes sense in some scenarios.
So this seems to be working already?
I’m just curious about this sentence.
I just digged into the source code of the django-islands repository, and it looks a lot like the code from django-multitenant package (their approach is to use the same database with tenant_id column). Just remember to follow the MIT license if you’re copying the source code.
You can also take notes from other approaches from packages like django-tenants that uses schema-based tenancy.
I’ve used django-tenants in the past, and I don’t like it because it’s hard to get into “migration hell”, where migrations takes minutes to process on all schemas.
Since past year I’ve been working with django-multitenant and having good results with almost 1000 tenants.
Feel free to reach out if you any further questions.
I understand that it is more a question of the business than the software, but the separation of tenant data is almost as essential as the database itself, since there is no SaaS without tenant separation.
I wanted to know if I am out of touch with what the market is using or if this type of approach/solution really does not exist.
Hi @leandrodesouzadev, how you doing?
I’m speaking from Belo Horizonte - MG, what about you?
This approach of tenants by banks has been around for a few years now! We like the idea of physical isolation mainly because of the LGPD.
I am following the same license. I created a separate repository and not a fork because I wanted something focused on multi-tenancy and not on citus compatibility, apart from other features that I am developing such as “tenant levels”, where there is a main tenant, but there are other entities that behave as a data access limiter.
We had some issues with the django-multitenant code and we missed proactiveness from the dev team fixing some bugs. That’s why i created django-islands.
I already knew django-tenants, but the “migration hell” is what we live today, sometimes we have 20 migrations to all tenants. Sometimes one specific migrations goes wrong in one specific database and we have to stop and discovery what goes wrong. Sometimes it’s very chaotic, but works well, even the cost of this is very high.
What specific issues are you facing? We have a few helper functions and custom models that does most of the work we need, and to support a few things that the built-in functions “kinda” support like setting more than one tenant.
I love the South! I’ve visited Gramado once, a beautiful city!
The errors weren’t serious at all, they were related to a configuration error in our code with the tool. For example: linking a tenantforegeinkey to a model that didn’t inherit from tenantmodel. Some silly configuration errors on our part, plus the lack of clear documentation, made us feel insecure and doubtful about the library.
All of this, combined with the fact that they hadn’t released a version in over a year, made it seem like the project was broken and abandoned. That’s why I created django-islands, to fix what was wrong and have confidence that if something broke, I could fix it.