What is the best way to organize a database for a Django / Flask web service in order to prepare for heavy loads?

Question

Database design

Good time of the year!
The question is more theoretical than practical .. but it's better to ask once than expressively keep silent and "sit in a puddle" (to cool the flaming ass :D ) in the future. The input data will be more like a "spherical horse in a vacuum" than reality. But this is done in order to better (and more clearly) describe the question. So we have:

1. Web service (we take the topic for example - food recipes)
   
2. Users from different parts of the Earth (USA, RF, Europe, CIS)
   
3. Expected load, for example, +1500 active uniques per month
   
4. VDS on Debian/Ubuntu x64 in the cloud (e.g. DO plan for $20/mo)
   
5. Python 3.5+
   
6. PostgreSQL 9.6+
   
7. We take Django or Flask as a web framework (others can also be considered, but I have little experience in them)
   

Bottom line: what is the best way to organize a database for a Django / Flask web service in order to be ready for an ever-increasing (but not uniform) load on the database, as a result of constant CRUD actions?
I met on the open spaces of Google advice on dividing each of the database tables into different servers. That is, a table ingredientson vds1.digitalocean.com, a table recipeson vds2.digitalocean.com, a table userson vds3.digitalocean.com, and so on. Thus, we can see where the load is growing (whether the number of registrations is growing or adding recipes or searching by ingredients or ...) and scale this particular server, and not touch the rest at all.
So, is this a working option? If “working”, then how to organize such a database operation scheme on Django / Flask (modules)? Maybe there are better and more elegant solutions to this problem?
I will be glad to sensible comments and links on this topic! Thank you.

Answer 1

Expected load, for example, +1500 active uniques per month

these are not heavy loads,
and don’t forget for optimization.guide
do everything on one, just don’t forget to replicate the database (+ backups of course)