Should I split one database into several?

Question

Database design

A large web project is planned with a bunch of data and, accordingly, tables. There was an idea to allocate logically some separate databases. For example, store users in the "Users" database, statistics in the "Statistics" database, etc. How will this affect performance? Will the interaction between databases become too complicated? Will it give any advantage in terms of architecture (will it become easier to maintain such a database, etc.). Or is it still better when one project is one database?

Answer 1

There must be serious reasons for sharing.
For example, in 1 of the projects in which I participate, logs were allocated to a separate database. This was done because there are a lot of them and the ability to backup the main base quickly was needed.
The main database is about 30GB. Logs - 300+ GB.
Performance has been added only for the specified scenario, everything else has become a little more complicated :)
So if you don’t see much benefit, then I don’t recommend

Answer 2

How many users are planned? How many entries does each have? What are your monthly hosting costs? Yes, you can, of course, separate it, but it is necessary that all servers stand in the same rack nearby then.

Answer 3

The main problem you will have is to make sure that the user database version matches everything else in the system.
In other words, you are going to break the foundations of relational databases once again - namely, break connectivity. Within the same database, this is monitored by foreign keys - in a broken database, the programmer must monitor this. Foreign keys practically do not make mistakes (if this happens, the database is terribly crooked), but the programmer - alas.
To distribute the load, there are technologies for clustering one database into several parts. But the base, I repeat, while the base is one .