Why We Built PgDog to Fix Postgres Connection Pooling Leaks
Why we built yet another Postgres connection pooler
I built PgDog to solve the leaky abstractions found in existing Postgres connection poolers like PgBouncer and RDS Proxy. Unlike traditional tools that force you to abandon session control features such as SET commands and LISTEN/NOTIFY, PgDog handles these internally using a built-in SQL parser and multithreaded Rust architecture. This approach allows applications to scale to millions of queries per second without rewriting production code or sacrificing critical database functionality.
If you’re not allowed to use a database feature, you are making a trade-off and have to change how you write your apps.
- AdieuToLogic
The fact that PgDog supports prepared statements[0] is a compelling feature in and of itself. This was a limitation of older versions of pgpool-II[1] thus disqualifying it in efforts where it otherwise could have been beneficial.
0 - https://docs.pgdog.dev/features/connection-pooler/prepared-s...
- 27183
It's awesome to see AGPL instead of the horrible BSL variants that have been going around.
- abrookewood
Quick note to say that the article describing WHY you are different and why it matters was very well written. Congrats on the launch!
- petters
> Since connection poolers reuse connections between clients, the connection state of one client “leaks” into the connection state of another.
Wow this is very bad. This actually happens in typical Postgres setups?
- dwedge
The SET implementation reads like a cleaner version of how ProxySQL does the same thing, which is nice to see