title: Benchmarks

Benchmarks

Three connection poolers — pg_doorman, pgbouncer, odyssey — driven by pgbench against the same PostgreSQL backend on identical hardware. Numbers below are relative throughput against each competitor and absolute per-transaction latency.

Last updated: 2026-04-27 12:00 UTC.

TL;DR

• vs pgbouncer — pg_doorman peaks at x12.0 TPS on prepared protocol, 120 clients.
• vs odyssey — pg_doorman wins by +40% at most (extended protocol, 120 clients).
• Tail spread at 10 000 simple-protocol clients (p99/p50, lower = more predictable) — pg_doorman 1.1× (59.9→64.5ms), pgbouncer 1.4× (276→387ms), odyssey 11× (17.9→204ms).

Environment

• Provider: Ubicloud standard-60 (eu-central-h1)
• Resources: 60 vCPU / 235.9 GB
• Kernel: Linux 5.15.0-139-generic x86_64
• Versions: PostgreSQL 14.22, pg_doorman 3.6.1, pgbouncer 1.25.1, odyssey 1.4.1
• Workers: pg_doorman: 30, odyssey: 30
• Duration per pgbench run: 60s
• Started: 2026-04-27 08:06 UTC
• Finished: 2026-04-27 11:03 UTC
• Total wall-clock: 2h 57m 08s
• Commit: c9dd765c

Methodology

Each scenario runs pgbench -T <duration> against a 40-connection server-side pool (pool_mode = transaction). The workload is a single SELECT :aid (\set aid random(1, 100000)) — pure pooler overhead, no real working set. Three poolers, one PostgreSQL backend, identical hardware.

• Reconnect rows use pgbench --connect: a fresh TCP+startup per transaction (worst case for login latency).
• SSL rows set PGSSLMODE=require and a self-signed cert.
• Latency is collected with pgbench --log (per-transaction file); percentiles come from those samples, not from pgbench summary stats.
• Scenarios run sequentially with the same data dir and warm OS caches.

Source: tests/bdd/features/bench.feature, driver: benches/setup-and-run-bench.sh.

Reading the tables

Throughput — pg_doorman_TPS / competitor_TPS, rendered:

Latency — per-transaction in ms. Each row shows p50 / p99 for every pooler plus the spread (p99 / p50): how far the slowest 1% drifts from the median. 1.0× means the tail equals the median; 100× means the worst 1% takes two orders of magnitude longer than a typical request — the regime where fanout latency starts hitting users (Dean & Barroso, 2013). Watch the spread column to see whether tail latency stays bounded as the client count grows. Full p95 series ships in the raw pgbench --log files in the artifact tarball.

Simple protocol

Throughput

Latency (ms; spread = p99 / p50)

Extended protocol

Throughput

Latency (ms; spread = p99 / p50)

Prepared protocol

Throughput

Latency (ms; spread = p99 / p50)

Caveats

• 30 s per run is short by pgbench standards (the docs recommend minutes); expect ±5% variance between runs. Re-run for production decisions.
• Single PostgreSQL backend, no replicas, no real working set — these numbers measure pooler overhead, not full-system throughput.
• All three poolers use vendor defaults plus pool_size = 40. Tuning specific knobs (pgbouncer so_reuseport, odyssey workers) will move the curves.
• Reconnect is the worst-case login-latency scenario; the headline numbers in production rarely look like the Reconnect rows.
• Workload is a 1-row SELECT. Read-heavy OLTP, OLAP, or LISTEN/ NOTIFY paths are not represented.