When a software project backed by a database is in its infancy, the demand on the database layer is minimal. Often, in these scenarios, there only needs to be a small number of simultaneous connections to the DB, and the total data size and query volume are relatively low.
Over time, these applications' feature sets and user base may grow! Adding new features to an app often involves changing the schema of the DB or adding new tables, which increases its footprint. A growing user base also generally means that the size of the DB and the number of queries it needs to process on any given day will rise. As this happens, the existing database server will start encountering issues keeping up with the demand, which is where database scaling comes into play.
To help keep things organized, we can think about our scaling challenges in three main buckets. Each of these buckets represents a particular pain point that a developer or DBA will start to see as the database is strained.
The first scaling pain point is hitting storage limitations. If you are working in an environment with a single primary database server, you may reach a point where your database fills your entire hard drive on that server. What do you do when the hard drive fills up?
The second pain point is hitting compute capacity limits. In practice, you can only have so many CPUs on one server, and with large-scale applications, this can become a bottleneck, even with top-of-the-line hardware!
The third pain point is network limitations. This could be general network bandwidth limits or software-based limitations if your DBMS can only handle a limited number of simultaneous connections, which is the case for systems like MySQL and Postgres.
Of course, you may encounter more than one of these in tandem.
Two general options here are vertical scaling (sometimes called "scaling up") and horizontal scaling (sometimes called "scaling out").
Vertical scaling refers to scaling up the resources of an individual server. This could be something like buying a larger hard drive to replace one that is nearing its capacity so that the database can fit and continue to grow.
On the other hand, horizontal scaling is the idea of distributing the load of your database across multiple servers. Implementing replication is the most commonly known version of this. However, your database can be scaled across more than one server in other ways, such as vertical or horizontal sharding. This approach is advantageous because it allows for near-infinite scalability and changes the architecture of the database so that there is no longer a single point of failure.
It's essential to keep in mind that all databases are different, and as such, there is no one right way or approach that fits all database environments. The best thing to do is to understand your data's structure and access patterns, understand the options for scaling, and then find the best combination of approaches to implement in your environment and your situation.