All possible ways to Scale a Database

I recently began studying **Database Scaling** and have a few questions. Please correct me if I’m mistaken on the following points: 1. A *database (db)* is a collection of *tables* (in relational databases) or *collections* (in non-relational databases). 2. A software system that manages databases (and performs various other tasks) is called a *Database Management System*. 3. A *database server* is a machine that stores the actual data (the "database") and runs an instance of a DBMS. 4. Types of database include: relational, document-based, graph-based, etc. Types of dbms includes: MySQL, Postgres, MongoDB, DynamoDB, etc Assuming the above are correct, I believe the following are the primary ways to scale a database server horizontally: A. **Monolithic Architecture** One MySQL (or Postgres, MongoDB, etc.) instance managing 5 databases. Each of these 5 databases contains 3 tables of its own. All 5 databases are part of the same application (for example, Uber). B. **Database Replication** 5 MySQL instances on 5 different servers. Each instance contains all 5 databases, and each database has 3 tables. This can involve either master-slave or master-master replication setups. C. **Microservices Architecture** 5 MySQL instances on 5 servers, with each instance managing only one of the 5 databases. Each database contains its own 3 tables, and each instance serves a specific microservice. D. **Sharding** 5 MySQL instances on 5 servers. Each instance has all 5 databases, and each database contains 3 tables. However, each instance’s user.db's "user" table only holds a subset of the total user data. E. **Sharding + Partitioning** In the scenario described above, each "user.db" (spread across different instances) implements database partitioning (for example, based on user IDs). F. **Sharding + Replication** Each MySQL instance has a master-slave or master-master replication setup while also handling its own shard of the overall data. G. **Sharding + Partitioning + Replication** **Questions:** 1. What are your thoughts on the scalability methods described above? 2. In a monolithic application (such as Uber on its first day), would it make sense to "avoid" placing all tables in a single database? Instead, should separate databases be created (e.g., "user.db" for user-related tables and "vehicle.db" for vehicle-related tables) while still storing them on the same database server under a single DBMS instance? 3. Can a single DBMS instance manage two databases located on different servers? 4. Is it possible to run two DBMS instances on the same server?