10đź‘Ť
Using the sites framework goes a long way towards providing a security guarantee to the “tenants”, assuming you give each site instance a unique table.
On the other hand, it’ll be a big hassle if you have a small number of tenants and you’ll waste a huge amount of server resources since you’ll need at least one server process per customer even if they aren’t using the system. If you have a large number of tenants it won’t be quite as much hassle because you’ll be forced to automate the solution regardless of your approach.
Putting a tenant foreign key in almost all your models will work just fine and Django’s ORM makes it easy (easier?) to enforce security using custom managers. The drawback is performance if you start getting hammered with lots of users, because there’s no easy way to scale up.
If you do need to scale, I think the best solution could be a combination of both approaches. Every model has a tenant foreignkey so databases can be shared but then you develop some mechanism at a higher level than Django to route customers into a site instance. This lets you put really big tenants on their own databases with resources properly tuned just for them (e.g. the proper number of mod_wsgi daemons, number of database connections, memcache pool properly sized, etc.) and smaller tenants share common resources.
7đź‘Ť
Take a look at https://github.com/bcarneiro/django-tenant-schemas
You’ll only have one project instance and won’t have to do many modifications in your code.