[arvidkahl]

I have been looking into this (and pgpool2 and pgbouncer) and what I found most suprising was both the lack of workable Docker images and any hint of a SaaS solution for this problem.

Connection Pooling as a Service, why does this not exist? What factors could cause this to be a bad idea? Need for proximity? Network speeds? Security?

[mmt]

> What factors could cause this to be a bad idea? Need for proximity? Network speeds? Security?

In short, yes to all.

Specifically, fallacy [1] numbers 1, 2, 3, 4, and 7. Maybe number 5.

None of those are necessarily insurmountable. However, given how relatively lightweight a connection pooler is to operate, especially compared with Postgres itself, it doesn't seem like an attractive target to "outsource".

[1] https://en.wikipedia.org/wiki/Fallacies_of_distributed_compu...

[graystevens]

Latency would be the big issue here. You’d likely have to spin up instances in lots of key data centres to try and combat this...

Each AWS location, each Google Cloud location.. and that’s not considering those that are colocating their own kit.

Interesting idea though, but you’d end up having to bundle it with DBaaS, at which point you’ve got the pressure and stress of having to look after everyone else’s data.

[foobarbazetc]

It’s really not worth doing this because the back and forth latency of SQL is much worse than proxying a HTTP/RPC request to the app server sitting next to the DB and getting the final result back.

[zrail]

Heroku sort of offers this, in so far as they will manage a pgbouncer instance in front of your Heroku Postgres database. It’s not generalized.