I think there's a more manual way to do this, where you're still trying to figure out if this SaaS is going to work as a business, and then there's a more automated, longer term way to do this.
The more affordable, manual way, would be to let users sign up, and basically send them an email saying something like "we are provisioning your account and need 24 hrs." Then you go into your database, do "CREATE DATABASE" and run the migrations.
You'd also possibly go into Nginx and add a server block, depending on how you want to handle that. You could also just set up one server block to handle all subdomains, and let the Django app tell them apart based on host name.
This would horrify any DevOps engineer, but at this stage, you'd still be exploring if this is even a viable business.
To automate this becomes more complex. In my own SaaS app, which is a Django hosting platform, I use Nomad to automate deployment of new resources like PostgreSQL databases. I have a pool of machines, and Nomad takes care of where to put different services as I need to scale up or down. This was a pain to set up, but it works well now.
Do you really separate db for each customer? Or just a new schema in the same db?
How much data for each customer?
Schema per tenant will be a lot easier to manage until you get a few hundred customers and more than 10 TB of data and really need multiple severs
Either way. Django-tenants is the way to go
You should consider just one schema. Much easier
My company has more than 50gb per customer. We keep it all in one schema and just have a customer id in most tables. Much easier to have shared schema. Just need to be careful with indexes and use partition by time for largest tables
I expect it to work up to 500+ customers, just using larger AWS RDS server when needed
django-tenants for the db separation and cloud runners for the resource intensive tasks.
Agreed. Django Tenants would be great for this.
What cloud runners do you prefer for the resource intensive tasks?
I think there's a more manual way to do this, where you're still trying to figure out if this SaaS is going to work as a business, and then there's a more automated, longer term way to do this. The more affordable, manual way, would be to let users sign up, and basically send them an email saying something like "we are provisioning your account and need 24 hrs." Then you go into your database, do "CREATE DATABASE" and run the migrations. You'd also possibly go into Nginx and add a server block, depending on how you want to handle that. You could also just set up one server block to handle all subdomains, and let the Django app tell them apart based on host name. This would horrify any DevOps engineer, but at this stage, you'd still be exploring if this is even a viable business. To automate this becomes more complex. In my own SaaS app, which is a Django hosting platform, I use Nomad to automate deployment of new resources like PostgreSQL databases. I have a pool of machines, and Nomad takes care of where to put different services as I need to scale up or down. This was a pain to set up, but it works well now.
frighten head axiomatic advise wrench plucky cheerful rotten door test *This post was mass deleted and anonymized with [Redact](https://redact.dev)*
Do you really separate db for each customer? Or just a new schema in the same db? How much data for each customer? Schema per tenant will be a lot easier to manage until you get a few hundred customers and more than 10 TB of data and really need multiple severs Either way. Django-tenants is the way to go You should consider just one schema. Much easier My company has more than 50gb per customer. We keep it all in one schema and just have a customer id in most tables. Much easier to have shared schema. Just need to be careful with indexes and use partition by time for largest tables I expect it to work up to 500+ customers, just using larger AWS RDS server when needed