Tags → #connection-pooling
2026
- Talk
What it takes to make a Postgres connection pooler invisible to your app: session settings, shared prepared statements, LISTEN/NOTIFY and failed commits.
-
How we test connection pooling in Multigres, and what a 100% pass rate actually tells you about correctness.
- Talk
How the Multigres pooler supports transactions, temp tables and LISTEN/NOTIFY without falling back to session pooling.
-
We test the scalability of Multigres' native connection pooler past 16,000 connections, and prove real Postgres compatibility by running Miniflux unmodified on a Multigres cluster.
-
In a single database, prepared statements parse once. Behind many gateways that win quietly evaporates. How Multigres consolidates prepared statements so Postgres parses each one exactly once.
-
Connection pool modes force a tradeoff between performance and correctness. Multigres figures out per-query which mode a connection needs, so you never have to choose statement, transaction, or session mode.
-
Why Multigres gives every user a dedicated connection pool (mostly a security story), how it shares a fixed budget fairly with max-min fairness, and the bucketing trick that keeps lookup fast.
-
Most connection poolers do two jobs in one process. Multigres splits them: multigateway accepts clients, multipooler manages backends. This is why.
- Talk
Building a custom connection pooler for Multigres: extended query protocol, per-user pools for RLS, and prepared statement consolidation.
- Talk
Why Multigres bundles pooling, HA, backups and sharding into one system for Postgres, and how its query-serving layer works.