Multiple databases vs partitioning in PostgreSQL

Consider following database schema for *PostgreSQL* (I'm using 13.x.x) **Users table** - just place to store users and do authentication **Projects** - projects which are created by specific user **Driver/Event/Vehicle types** - "handbook" tables defined in specific project (e.g. project#1 could have only 10 vehicle types, but project#2 - 1000) **Really big table** - 30 up to 70 million rows **per specific project** **Event reactions** - abstraction around "really big table" (the number of rows could as big) I do want to partition driver/event/vehicle/really_big_data/event_reactions by *project_id* field which could give me something like this:

driver_types_some_uuid1
driver_types_some_uuid2
...
event_types_some_uuid1
event_types_some_uuid2
...
really_big_data_some_uuid1
really_big_data_some_uuid2
...
and etc.

The reason why I do want to make partitions is to make faster search per project in my API, easier way to locate data visually and users want have to "backup" theirs projects as some kind of dump. But I have some feelings that this is a bad way, since I'll face foreign keys between partitioned tables and this is not easy as I know so far. So I came up with next idea: * Create database "A" for users and their projects lists * Create databases named *database_project_id" per project and etc. As I see now, I could easily select data per project, do dumps, visually locate data without headache. But this leads me to creating some abstractions in my API code though: open 1 DB connection for users/projects and manage N-amount of DB connections for each "project", which are requested (if project is not requested for certain amount of time - close connection). **So the question is**: Is my idea about creating databases instead of partitions any good? Are there better options to do it in such case? **UPD** I do not need any relations between different users/projects.