3 ms·
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 sol
by arvidkahl 8y ago
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?
- zrail 8y agoHeroku 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.
- graystevens 8y agoLatency 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 8y agoIt’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.
- deleted 8y ago[deleted]
- mmt 8y ago> 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_computing https://en.wikipedia.org/wiki/Fallacies_of_distributed_compu...