Why would anyone run hundreds of connections? A server can only process number_of_processor_cores connections at once. Sure, few connections might wait for I/O, but not hundreds, unless database is very untypical.
Opening and closing connections is very slow and expensive, so almost always better to keep these 300 connections open than to try to be fancy.
You COULD try to say give each server only 3 connections and make them share, which cuts you to 90 connections.. but then you have to try to share state between different python processes (not easy), and will often end up with deadlocks and sync overhead.
Its a little outdated but I've found it largely holds. That is, you'd want a mighty box for 1000 concurrent connections.
That said, connection queuing works really well with postgres such that throughput is frequently better at lower connection counts than at higher ones.
I have no experience with mysql that is less than 15 years out of date.
Unfortuantely, MySQL has no good replacement for Postgresql's PGBouncer which greatly mitigates the issue of cross-process connection pooling. (I'm actually working on one, but for Uber to use it they'd have to switch back to SQLAlchemy >:) )
Numbers vary, but that's the principal that uses more connections than cores.