When you launch a new application, you usually run the database on a single server. As your traffic grows, the database starts running out of CPU, memory, or disk space.
You have two choices: scale Vertically (buy a bigger machine) or scale Horizontally (buy more machines).
Scaling vertically is incredibly easy. You just shut down the server, move the hard drive to a more expensive machine with 64 cores and 512GB of RAM, and boot it back up. The application code doesn't need to change at all. The problem is that hardware has hard physical limits, and the price grows exponentially. A server with 2x the CPU cores might cost 4x as much.
Increase the traffic to the single server. When it melts, try upgrading it (Vertical). When that hits the limit, try adding more servers (Horizontal).
Eventually, you can't buy a bigger server. Amazon doesn't sell one. The only way forward is to scale horizontally: adding more standard, cheap servers to share the load.
In databases, this is called Partitioning or Sharding. You break your data into chunks (partitions) and put different chunks on different nodes. If you have 4 nodes, each node only has to handle 25% of the data and 25% of the queries.
However, horizontal scaling introduces massive complexity. When a user asks for user ID 1052, which of the 4 nodes has it? How do you route the request? And what happens when you add a 5th node? We'll explore these routing challenges next.