How to design a database for a Django project?

Question

PostgreSQL

The task is this: to think over a database for a CRM site (backend - Dzhanga, DBMS - Postgres), on which each user has his own table of services, a table of clients (and everyone knows that a person can have several numbers, etc., which generates additional tables), etc., but it can also have several, say, companies or branches of companies
. There is little experience in creating a database, so the question arose: how to organize it correctly?
I have such options, but I can’t decide:
1) Create a new database for each user, write all the companies of one user there
2) Create a new database for each company (to avoid the situation with huge connecting tables even for simple tasks).
3) Merge everything into one database, but in this case, I am afraid that these tables will eventually reach huge sizes, all this will work slowly, etc., and the structure is much more complicated this way, a huge number of link tables and and so on, which, it seems, can be avoided by the second option
. Perhaps it should be implemented in a completely different way, any ideas? Maybe there are recommendations what to read to understand the issue?
And now the essence of the question regarding Django, in Django, the databases used are registered in the config right away, how then to implement such an approach? Is it possible in Dzhanga to organize the creation of a new database for each user during registration? Or is it worth using a completely different approach, or even a different backend in general?

Answer 1

blog.antidasoftware.com/2017/07/saas-django-python... I
traditionally warn against premature optimization. if the project is just starting, you can probably do without all this. then, when it grows, scatter it over the bases.

Answer 2

> each user has his own table of services
is completely redundant. for all users, one table of services, in which belonging to a specific user through the user's id column.
> there may be several numbers, etc., which gives rise to additional. tables
are the same.
> 3) To merge everything into one database
is the most normal option.