> In a database like PostgreSQL or MySQL, each client connection to the database is handled by a separate unix process<p>This isn't correct. They're often handled by threads, but not necessarily 1:1.<p>> Every connection adds overhead, so the entire database slows down, even if those connections aren’t actively processing queries.<p>I've never known this to be true, even in large production systems. Can anyone cite?<p>> 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<p>Sharding and read replicas are two very different ways of handling data; the issues cited as problems only affect sharing and not read slaves.<p>> 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.<p>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.<p>> 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)<p><pre><code> mysqldump --single-transaction --master-data
</code></pre>
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.