In a traditional MySQL environment, the application only needs a single connection string to connect to the primary database. If read replicas are created, this becomes more complex as there may be several servers to connect to, but still a relatively small number.
In sharded configurations, there might be hundreds or thousands of individual database servers making up the sharded cluster that need to be considered when querying for data. Somehow, your application or other infrastructure needs to understand how to accept queries and then route those queries to the appropriate server.
One option is to have all of the shards set up and leave the coordination and connection management logic to the application code. Managing connection strings within application code can be done without setting up extra infrastructure specifically for connection management. However, it also adds complexity to the app layer.
Another option would be to use a directory service. A directory service can store information about which servers store what data, and keep track of connection strings for each. Your applications can then use this directory service to determine which database server to connect to.
An even better solution would be to use a proxy routing layer. In this setup, a separate component is placed between the application and the sharded database infrastructure, perhaps on its own server or set of servers. Typically, the proxy router understands the database protocol so your application would connect to it, and it would be smart enough to figure out where the data lives and dispatch your queries to the proper shards before returning results. This is the most scalable option, and acts as a good abstraction for the database.
Another important thing to consider with a sharded database is how your system handles large numbers of connections. Large-scale apps may need to make thousands or even tens of thousands of simultaneous connections to a database.
Connection pooling helps application performance by creating a predefined pool of connections to your database. Instead of creating a new connection every time your code needs to query the database, a connection is borrowed from the pool to do its work. This reduces the CPU overhead of repeatedly creating and destroying connections.
PlanetScale has a built-in, sophisticated connection management mechanisms that allow for theoretically unlimited connection capacity. In fact, we proved that PlanetScale can handle one million simultaneous connections.