4 ms·
I like Postgres but still turn to MySQL for production use most of the time for a few reasons: * Permission management on Postgres is much more painful. * The
by pyrophane 5y ago
I like Postgres but still turn to MySQL for production use most of the time for a few reasons:
* Permission management on Postgres is much more painful.
* The need for an external connection pooler makes postgres more annoying to set up.
* Better quality docs on performance tuning MySQL.
- brianwawok 5y agoDo you really need a connection pooler for most PG installs? I run a SaaS company with a lot going on, and haven’t had to touch a pooler. Average about 500 open connections. That’s a few, but on a DB server with 200GB of memory it’s nots really breaking anything.
- hans_castorp 5y ago> * Permission management on Postgres is much more painful. but way more flexible and powerful I only work in the Java world where all application servers have the connection pooling built in, so I never had the need for an external connection pooler.
- skeletal88 5y agoI joined a company where most stuff is done in Java and tried to explain to colleagues that sn external connection pool would ne good. They didn't know such things existed at all, and then refused because in their mind the application-specific intetnal pools were all they needed. Which was and is totally wrong - the application server internal pools, like HikariCP only share connections between threads inside the server. What if now we have 4 instances of the same server running (because of a deployment, where 2 new ones are spawned, started and the 2 old ones aren't taken down until the loadbalancer determines that the new o es are running ok. Now you need 2x the number of connections available than you would ususlly need. Once we had run out of connections when for some reason aws went crazy and started deploying too many instances of the application.