PGConf.Russia 2025

Not a PgBouncer, But a Connection Pooler. Not Odyssey, But with Coroutines

If you’ve ever set up a high-availability PostgreSQL cluster, you’ve likely faced the challenge of redirecting traffic to the primary node after a failover.

Typically, this requires additional software to monitor cluster status and reroute traffic accordingly. To avoid a single point of failure, you may have had to implement failover handling within that layer. Additionally, you might have encountered PostgreSQL’s limitations on handling large numbers of concurrent client sessions, necessitating query pooling.

To solve these issues, we developed Proxima — a scalable, fault-tolerant proxy and connection pooler. Proxima automatically redirects traffic to the primary node and, in BiHA setups, seamlessly switches to a new primary in case of failure.

In this talk, I’ll cover why and how we built Proxima, the key architectural decisions behind the extension, and the

implementation details that enable it to handle 10,000+ concurrent client sessions.

We’ll also explore use cases and answer your questions.

In PostgreSQL performance testing, benchmarks measure query execution time (latency). To get more reliable results, queries are executed repeatedly, generating a dataset of latency values. Performance is often assessed using standard metrics like the median or mean, but we propose a more advanced approach.

In practice, latency distributions are often multimodal, consisting of multiple underlying distributions with distinct characteristics. In such cases, traditional statistical methods are insufficient, requiring a more detailed analysis of the dataset’s structure.

Our work presents a tool that automatically performs statistical analysis of benchmark results, accounting for dataset-specific features. It detects multimodality, identifies the number and boundaries of dominant modes, and determines key distribution parameters—providing deeper insights into PostgreSQL performance variations.

This talk will cover key aspects of migrating from SQL Server to PostgreSQL, with a focus on converting stored procedures, triggers, views, functions, and other database objects. We’ll discuss the unique characteristics of each database system that can complicate code conversion, as well as unexpected factors that impact performance and correctness.

The session will be valuable for both experienced database professionals and those new to database migrations.

In this talk, we will discuss what character encodings and collations are. I will explain the issues that can arise from sorting (COLLATION) in databases and show how these problems can be addressed using the COLLATION PROVIDER = ICU feature in PostgreSQL.