> In a database like PostgreSQL or MySQL, each client connection to the database is handled by a separate unix process This isn't correct. They're often handle

> In a database like PostgreSQL or MySQL, each client connection to the database is handled by a separate unix process This isn't correct. They're often handled by threads, but not necessarily 1:1. > Every connection adds overhead, so the entire database slows down, even if those connections aren’t actively processing queries. I've never known this to be true, even in large production systems. Can anyone cite? > Partitioning (sharding) and read replicas probably won’t help you with your connection limit, unless you can somehow load-balance requests so that all the requests for a particular partition are handled by a particular server instance Sharding and read replicas are two very different ways of handling data; the issues cited as problems only affect sharing and not read slaves. > That’s all doable, but it doesn’t seem a particularly valuable use of your time when you’re also trying to iterate on product features. If you can't scale you database, then adding more functionality is a bad thing. Software engineering doesn't stop once you make an API call to someone else's software. > in order to set up a new replica, you have to first lock the leader to stop all writes and take a consistent snapshot (which may take hours on a large database) mysqldump --single-transaction --master-data You can even gzip this on-the-fly and stream it via SSH to the new server to avoid disk I/O on the local machine competing, or even connect remotely from another server via mysqldump to avoid the SSH overhead.