PgBouncer works. That’s undeniable. But anyone who has migrated an existing application to a PostgreSQL connection pooler knows the cost: code to rewrite, features to drop, painful trade-offs. That’s exactly the observation that pushed the PgDog team to build a new tool rather than adopt what already existed.
The Problem with Classic PostgreSQL Connection Poolers
Poolers like PgBouncer or RDS Proxy follow the UNIX philosophy: do one thing, and do it well. That’s a strength, but also a limitation. By reusing connections between clients, these tools introduce what’s known as an abstraction leak: you’re adding an infrastructure layer that changes how your application talks to the database.
In practice, this creates two major constraints.
SET Commands Become Dangerous
When a pooler reuses a connection, one client’s session state can bleed into another’s. If you use SET to define a timeout or configure Row Level Security (RLS), that parameter can leak to a different client.
The benign scenario: a slow query runs too long. The serious scenario: your RLS policy stops working and rows silently disappear. The standard recommendation is therefore to stop using SET altogether. In other words, to give up a native PostgreSQL feature.
LISTEN/NOTIFY Is Incompatible with Transaction Mode
The LISTEN and NOTIFY commands implement a pub/sub system directly inside PostgreSQL. It’s convenient, it avoids adding Redis or SQS to your stack. But in transaction mode, classic poolers can’t handle them. The result: most teams drop this feature the moment they add a pooler.
What PgDog Does Differently
An Embedded SQL Parser for SET Commands
PgDog includes an SQL parser capable of detecting SET statements, extracting variables and their values, and storing them on the client side within the proxy. Before executing a query, PgDog checks that the server connection state matches the client’s. If it doesn’t, it synchronizes the missing variables via query pipelining, in a single network round trip.
The performance impact is limited, and you keep access to a PostgreSQL feature without modifying your application code.
LISTEN/NOTIFY Handled Natively and Across Multiple Processes
This is PgDog’s most original architectural choice. The tool handles LISTEN and NOTIFY internally, moving messages between different proxy instances. From the client’s perspective, PgDog looks like the broker. In reality, PostgreSQL is still doing that job.
Concretely, PgDog uses Tokio’s broadcast channel to route messages between clients within the same process. For multi-container deployments (a Kubernetes production environment, for example), it maintains a dedicated connection to PostgreSQL to relay all LISTEN and NOTIFY traffic. PgDog acts as a pub/sub proxy, using PostgreSQL as the real broker.
The team also reports having fixed transactional NOTIFY behaviors that had caused production incidents for some users.
A Multithreaded Engine Built on Tokio in Rust
PgDog is written in Rust and built on Tokio, a multithreaded async runtime. Each client is handled by an independent async task. This makes it possible to use multiple CPUs within a single process, without fragmenting the connection pool.
With PgBouncer, each process has its own set of PostgreSQL connections. If one process is saturated, the clients attached to it wait. PgDog avoids this by centralizing connection management in a multithreaded process that can absorb traffic spikes without relying on external autoscaling.
The concrete benefits:
- Better server connection utilization through a pool shared across all threads
- Faster response to traffic spikes without waiting for a scale-out
- Simplified observability: a single source of metrics and health checks
- No hidden complexity on the Linux kernel side or in the AWS control plane
A Few Things to Keep in Mind
PgDog is presented as open source and free to use. The team states it has been running in production for over a year, handling 2 million queries per second. These figures come from the team itself: independent benchmarks and real-world feedback from external users are still to be documented.
The full identity of the team and the project’s governance model are not detailed in the public documentation available at this time. That’s something to watch when evaluating the project’s long-term viability.
Compared to other alternatives like Supavisor or Pgpool-II, PgDog has not yet published any public comparative benchmarks. The comparison remains qualitative for now.
Key Takeaways
- PgDog is an open source PostgreSQL pooler that addresses the abstraction leaks of classic tools (PgBouncer, RDS Proxy) without forcing you to rewrite application code.
- Its embedded SQL parser preserves the behavior of
SETcommands and prevents state contamination between clients. - Native
LISTEN/NOTIFYhandling across multiple processes is the project’s most distinctive engineering decision. - The multithreaded Rust/Tokio architecture targets better resource utilization and simplified observability.
- The project is still early in terms of public visibility: independent benchmarks and large-scale adoption feedback are still to come.
If you’re running a PostgreSQL infrastructure in production and have already given up on RLS or LISTEN/NOTIFY because of a pooler, PgDog is clearly worth a look. Feel free to share your experience or ask questions in the comments, or follow the blog for future deep dives.
Sources
- PgDog – Why we built yet another Postgres connection pooler : official article from the PgDog team, primary reference source for this article.