YSQL Connection Manager is Now GA

We are excited to announce the General Availability (GA) of YSQL Connection Manager in YugabyteDB 2026.1.1, YugabyteDB Anywhere, and YugabyteDB Aeon. Built directly into every YugabyteDB node, YSQL Connection Manager is a native connection pooler that solves the classic trade-off between connection scalability and feature compatibility.

In this blog, we examine current PostgreSQL connection management challenges and detail how YSQL Connection Manager provides seamless session-state management at scale.

PostgreSQL Connection Management Challenges

PostgreSQL uses a dedicated backend process for each client connection and a per-backend catalog cache. YugabyteDB inherits PostgreSQL’s process-per-connection architecture, so establishing connections in YugabyteDB carries noticeable memory and CPU overhead. This means (until now) we have recommended capping active server connections at 15 per vCPU.

This limitation becomes more pronounced in modern distributed architectures. Microservices, serverless deployments, and autoscaling pods maintain independent client-side connection pools, each contributing to the total number of connections reaching the database. As application instances scale, these pools can collectively drive connection counts beyond recommended limits, increasing resource consumption and risking connection exhaustion.

Organizations have typically addressed this by deploying transaction-mode poolers like PgBouncer. While this approach limits active backend processes, it discards session state upon transaction commit. This breaks workloads that depend on everyday features like SET parameters, temporary tables, advisory locks, or LISTEN notifications. In practice, the vast majority of applications rely on at least one of these capabilities.

Built directly into each YugabyteDB node, YSQL Connection Manager executes transaction-level pooling while seamlessly preserving client session state across transactions. Applications connect over standard ports without requiring code changes or application-level re-architecting.

The Session-State Problem

Traditional connection poolers like PgBouncer and Odyssey, as well as managed services such as Amazon RDS Proxy, offer two distinct operational modes: transaction pooling and session pooling.

While session pooling provides full feature compatibility, it retains a dedicated backend per client, thereby optimizing connection latency without reducing backend overhead.

Conversely, transaction pooling releases the backend process upon transaction commit, drastically lowering resource consumption. However, client session state is discarded and crucial PostgreSQL capabilities like SET parameters, temporary tables, WITH HOLD cursors, SQL-level PREPARE, session-level advisory locks, and LISTEN notifications fail to persist.

Because modern software relies heavily on these standard features (such as multi-tenant platforms using SET for row-level security, task queues leveraging advisory locks and LISTEN, or Django requiring transaction-mode users to disable server-side cursors), deploying transaction poolers typically demands exhaustive code, ORM, and driver audits.

Overlooking a session-state dependency often results in subtle, silent data corruption rather than overt runtime errors, such as queries running under an incorrect search_path or advisory locks lingering on unrelated connections.

Alternative proxy architectures attempt to track session state by parsing client SQL statements.

While this strategy detects basic SET calls, it fails when GUC parameters are modified inside database functions or reversed via rollbacks. Furthermore, SQL-parsing proxies miss database-level configuration updates (such as ALTER ROLE … SET, ALTER DATABASE … SET, or configuration file reloads) since these modifications occur out-of-band across separate administrative connections.

How YSQL Connection Manager Handles Session State

YSQL Connection Manager restores each client’s session state on whichever backend runs its next transaction. It doesn’t parse SQL to do this. The YugabyteDB query layer reports every change, including settings changed inside functions and settings undone by a rollback.

Seamless tracking of session state

These features remain fully functional across pooled backends without triggering session pinning:

• Configuration settings. Commands like SET, RESET, and custom application parameters (such as app.tenant_id used for row-level security) preserve standard PostgreSQL rollback dynamics.
• Protocol-level prepared statements. Prepared statements created by client drivers and ORMs are shared seamlessly throughout the connection pool.
• NOTIFY and transaction-scoped advisory locks.

Features requiring session pinning

Specific features, including LISTEN, temporary tables, WITH HOLD cursors, SQL-level PREPARE, and SET ROLE, require a single backend process.

When a session uses any of these, YSQL Connection Manager automatically pins it to its specific backend while continuing to pool all remaining connections. Although a pinned session shares fewer resources, accuracy is always preserved.

Users do not need to manually select a pooling mode; Connection Manager evaluates and assigns the appropriate behavior for each session.

Instant application of configuration updates

Whenever settings are updated using ALTER ROLE … SET, ALTER DATABASE … SET, or through a configuration reload, newly initiated sessions immediately adopt the updated parameters, even when drawn from a pool of long-running backends. YSQL Connection Manager’s internal configurations can be modified dynamically without requiring a service restart.

You can enable pooling for existing applications immediately, without a session-state audit.

Native to the Database Across All Nodes

Built directly into YugabyteDB, YSQL Connection Manager listens on the standard YSQL port for each node. This eliminates the need to manage separate proxy infrastructure while seamlessly scaling pool capacity as nodes are added.

YSQL Connection Manager: Key Features

• Single-setting activation. Enabled via a simple YugabyteDB flag or a UI control within YugabyteDB Anywhere and YugabyteDB Aeon.
• Multi-threaded architecture. Unlike PgBouncer’s single-threaded design, YSQL Connection Manager distributes workload across multiple threads. A single node easily scales beyond 10,000 active clients and handles over 15,000 incoming connections per second with minimal added latency under heavy load.
• Shared connection limits. Node-level pools operate under a unified connection allowance defined per database or user, with inactive sessions closing incrementally to prevent sudden traffic spikes from overloading backends.
• Dynamic multi-route pooling fairness. Automatically balances connections across unique user-database pools based on demand. Pools are assigned a baseline quota but can temporarily burst above it when total demand is low. Under high overall demand, idle connections from pools exceeding their share are reclaimed and reallocated to waiting pools to prevent starvation.
• Enterprise security and TLS. Native support for CERT, SCRAM-SHA-256, LDAP, and JWT/OIDC authentication, alongside wire encryption managed directly from cluster configuration.
• Native distributed architecture. Smart client drivers balance connections across nodes, where local YSQL Connection Manager instances pool them locally.

The Numbers

YSQL Connection Manager delivers robust performance by authenticating over 13,000 new connections per second per node on an AWS c5.4xlarge instance (16 vCPUs), adding only 1–3 ms of latency even with 10,000 active clients per node. All this while supporting more than 10,000 logical connections per node at a memory overhead of 100 KB per connection.

How it Compares

PgBouncer trades compatibility for scale, and RDS Proxy trades pooling for compatibility. YSQL Connection Manager keeps all three:

1. It’s built into every node with nothing new to configure
2. It scales with the cluster
3. It keeps PostgreSQL session behavior, pinning a session only for states that can’t move

For every release, pg_regress/yb_regress, YSQL tests, and the test suites of pgJDBC, the YugabyteDB Smart drivers, psycopg, Npgsql, Go pgx, and Django all run through YSQL Connection Manager. Passing them is one of the release requirements.

The comparison below highlights how YSQL Connection Manager differs from traditional poolers like PgBouncer and Amazon RDS Proxy in handling architecture, session state, and scalability:

What to Know Before You Start

• Pinned sessions aren’t shared. Prefer transaction-scoped advisory locks and protocol-level prepared statements, which most drivers use by default.
• Not yet supported: IPv6, Unix-domain sockets, Kerberos authentication.
• Memory: about 200 MB per node for the YSQL Connection Manager process.

What’s Next?

• Certificate (cert) authentication.
• A way for applications to request a pinned session explicitly.

Get Started Today!

YSQL Connection Manager is generally available in YugabyteDB 2026.1.1, YugabyteDB Anywhere, and YugabyteDB Aeon.

• YugabyteDB: start each YB-TServer with enable_ysql_conn_mgr=true:
  ./bin/yugabyted start --tserver_flags "enable_ysql_conn_mgr=true"
• YugabyteDB Anywhere: turn on Connection pooling when you create or edit a universe.
• YugabyteDB Aeon: turn on Connection Pooling when you create a cluster, or under Settings > Connection Pooling.

For more information, check out:

• Set up YSQL Connection Manager,
• YSQL Connection Manager Best Practices
• Migrate from PgBouncer.

Look out for upcoming YSQL Connection Manager blogs, which will examine the internal mechanics, exploring how parameter updates propagate seamlessly to pooled sessions across all nodes, as well as its handling of client authentication and protocol-level prepared statements.