Odyssey vs PgBouncer: PostgreSQL Connection Poolers (2026)

Quick verdict

Short answer

Start with PgBouncer unless you have a specific reason not to: it is small, widely packaged and documented, and supports transaction pooling with protocol-level prepared statements. Look at Odyssey when one PgBouncer process has become CPU-bound and running several processes is awkward, or when you want different pool modes, authentication and limits per database and user, plus host selection by session attributes and availability zone. Odyssey is Linux-only and has thinner documentation, so budget time to read its configuration reference.

How we know: This comparison is research-based: architecture, pooling modes, prepared statement handling, authentication, host balancing, platforms, licences and release history were checked against the Odyssey and PgBouncer repositories, documentation and changelogs on 7 November 2026. We have not deployed either pooler or measured throughput, so nothing here is a performance result.

Odyssey is a connection pooler and request router for PostgreSQL, published by Yandex under the BSD 3-Clause licence and maintained by the Yandex Cloud managed databases team. Worker threads handle authentication and proxying while sharing global server pools. Pools are defined by rules for each database and user pair, each with its own pool mode, authentication and limits. The latest release is v1.5.2 (13 September 2026), and 1.6.0-rc1 followed on 5 October 2026.

PgBouncer is an ISC-licensed connection pooler for PostgreSQL with session (default), transaction and statement pooling. It runs as a single-threaded process; scaling across CPU cores means running several processes with so_reuseport, with peering to forward cancel requests between them. The current release is 1.26.1 (14 October 2026). Version 1.26.0 removed online restart (-R), and the changelog recommends rolling restarts with so_reuseport.

Same job, different shape. Both poolers reduce PostgreSQL server connections, and both lose session state in transaction mode. The differences are in threading, per-rule configuration, host selection and how much documentation and packaging you get. If you also need SQL-aware read/write splitting or failover, see PgBouncer vs Pgpool-II.

Side by side

Aspect	Odyssey	PgBouncer
Architecture	Multi-threaded: worker threads share global server pools in one process	Single-threaded per process; several processes with so_reuseport and peering to use more cores
Pooling modes	Session and transaction (documented per rule)	Session (default), transaction and statement
Configuration unit	Rules per database and user pair, each with pool mode, authentication and limits	Global settings with per-database and per-user overrides such as pool_size and pool_mode
Prepared statements in transaction mode	Supported per rule with pool_reserve_prepared_statement	Protocol-level prepared statements since 1.21 via max_prepared_statements (default 200 since 1.24)
Abandoned transactions	Can cancel and roll back work left by a client that disconnects mid-transaction before reusing the connection	Not described as a separate feature in the pages checked
Host selection	Random balancing across listed hosts, preferring localhost, then the same availability zone; target_session_attrs (read-write, read-only, prefer-standby, any)	Host list with load_balance_hosts (round-robin by default, or stick to one host); no role detection
Authentication	md5, scram-sha-256, clear text, cert, PAM, LDAP, block or none per rule; TLS	cert, md5, scram-sha-256, trust, hba, ldap (1.25.0), pam; auth_query; TLS
Observability	Built-in Prometheus metrics and an admin console	Admin console with SHOW commands; Prometheus via external exporters
Platforms	Linux on x86 and x86_64 only, per the README	Linux and BSD, Windows via MinGW build; widely packaged
Licence and price	BSD 3-Clause, free	ISC, free

Key differences

Threads versus processes

The architectural difference is the main reason Odyssey exists. PgBouncer uses one CPU core per process, according to its documentation. That is enough for many deployments, and when it is not, you can start several PgBouncer processes on the same port with so_reuseport and configure them as peers so that cancel requests reach the right process. Each process keeps its own pools, so connection limits are per process.

Odyssey runs several worker threads inside one process that share global server pools, so one Odyssey instance can use several cores while keeping one set of pools and limits. If you are running a large fleet and want a single pooler process per host, that is simpler to reason about than a group of PgBouncer peers. We have not measured either, so treat throughput differences as something to check under your own workload.

Per-rule configuration

Odyssey configures storage (backend servers) and rules (database and user pairs) separately. Each rule sets its own pool mode, authentication method, pool size and options such as pool_reserve_prepared_statement, so one tenant can use transaction pooling while an administrative user stays in session mode on the same instance. PgBouncer also lets you override pool mode and size per database and per user, but most settings are global, and authentication is chosen through auth_type or an auth_hba_file.

# odyssey.conf (sketch based on the rules reference): one rule per database and user
storage "postgres_server" {
    type "remote"
    host "127.0.0.1"
    port 5432
}

database "app" {
    user "web" {
        authentication "scram-sha-256"
        storage "postgres_server"
        pool "transaction"
        pool_size 20
        pool_reserve_prepared_statement yes
    }
}

Choosing hosts

Odyssey can list several hosts for a storage and choose among them at random, preferring localhost, then hosts in the same availability zone, then hosts that match the rule's target_session_attrs, such as read-only for standbys or read-write for the primary. That gives a simple form of read routing by user or database without parsing SQL. PgBouncer accepts a comma-separated host list and, with load_balance_hosts (added in 1.24.0), rotates new server connections across them or sticks to one until it fails; it does not check which host is the primary, so failover is usually handled by Patroni, a virtual IP, DNS or HAProxy.

Ecosystem, documentation and lifecycle

PgBouncer has a long release history, packages in most Linux distributions, and is built into several managed PostgreSQL services, so operational knowledge is easy to find. Its 2026 releases added parameter tracking for search_path, pool_idle_timeout and per-user query_wait_timeout, and removed online restart. Odyssey is actively developed by a cloud provider that runs it in production (commits on 7 November 2026, a 1.6.0 release candidate in October), but its documentation is less complete and some defaults in the reference tables are ambiguous, and the README lists only Linux on x86 and x86_64.

Pricing and licensing

Both are free. Odyssey is released under the BSD 3-Clause licence in the yandex/odyssey repository, with no paid edition or published commercial support offer. PgBouncer is released under the ISC licence, with no paid edition from the project. Your costs are servers or containers and the time to operate them. Some managed PostgreSQL services include PgBouncer within their own pricing; check your provider.

Pricing checked on the vendors' official pages on 7 November 2026. Prices change; confirm before buying.

Where each one leads

Odyssey strengths

Multi-threaded, so one process can use several CPU cores with shared pools
Rules per database and user with their own pool mode, authentication and limits
Host selection by target_session_attrs and availability zone
Rolls back transactions abandoned by disconnected clients before reusing the connection
Built-in Prometheus metrics

PgBouncer strengths

Small, well documented and widely packaged
Statement pooling mode in addition to session and transaction
Protocol-level prepared statements in transaction mode, on by default since 1.24
Broad authentication options including auth_query, LDAP and PAM
Used inside several managed PostgreSQL services, so skills transfer

Limitations

Odyssey limitations

Linux on x86 and x86_64 only, per the README
Documentation is thinner, and some defaults in the reference tables are ambiguous
Fewer distribution packages and less community material
No SQL-aware read/write splitting

PgBouncer limitations

Single-threaded per process; multi-core use needs several peered processes
No primary detection or read/write splitting
Online restart was removed in 1.26.0
Transaction mode breaks SET, LISTEN and SQL PREPARE

When to choose each

Choose Odyssey if

One PgBouncer process is CPU-bound and you want one multi-core pooler per host
Different tenants or services need different pool modes and authentication on one instance
You want reads for some users sent to standbys by session attributes, with availability-zone preference
You run Linux on x86_64 and are comfortable reading source and reference docs

Choose PgBouncer if

You want the most common, best documented PostgreSQL pooler
You need packages for many platforms or a Windows build
Your load fits in one process, or several peered processes are acceptable
You want the same pooler your managed PostgreSQL provider uses

When neither is right

You need the middleware to split reads from writes and handle failover: see PgBouncer vs Pgpool-II.
You are on Amazon RDS or Aurora and prefer a managed pooler: see Amazon RDS Proxy vs PgBouncer.
Your bottleneck is data size or write throughput rather than connections: sharding inside PostgreSQL with Citus addresses a different problem.
Your application servers already pool connections and the database is well below max_connections.

Final recommendation

Bottom line

PgBouncer is the safer default for most PostgreSQL teams: it is simple, well documented and the pooler most managed services build on. Odyssey is a credible, actively maintained alternative for large Linux fleets that have outgrown a single-threaded pooler or want per-rule settings and availability-zone aware host selection in one process. Move to Odyssey for a concrete scaling or configuration reason, and test your workload and drivers against it first.

Frequently asked questions

Is Odyssey faster than PgBouncer?

We have not benchmarked them. Odyssey is multi-threaded, so one process can use several cores, while PgBouncer uses one core per process and scales by running several processes with so_reuseport. Measure with your own workload before deciding.

Do both support prepared statements in transaction mode?

Yes. PgBouncer supports protocol-level prepared statements since 1.21 when max_prepared_statements is above zero (default 200 since 1.24). Odyssey supports them per rule with pool_reserve_prepared_statement. SQL-level PREPARE is still a problem in PgBouncer transaction mode.

Is Odyssey still maintained?

Yes. As of 7 November 2026 the yandex/odyssey repository is active, with v1.5.2 released on 13 September 2026 and 1.6.0-rc1 on 5 October 2026.

Does Odyssey offer statement pooling?

Its documentation describes session and transaction modes. A statement value appears in a parameter table but is not described, so do not rely on it. PgBouncer documents statement pooling.

Sources

Checked November 2026.

How we research comparisons: our editorial method.