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.

I’ll talk about the challenges you’ll face if you decide to implement a new TableAM. What to choose: Generic XLog or Custom RMGR? Why use a Custom SMGR? How to integrate PostgreSQL allocators into third-party libraries, even if they don't officially support it? What’s missing for a columnar engine (including vectorization and late materialization), and how can we work around those limitations?

In the second part, I’ll dive into the internals of pgpro_tam — a new native table engine for OLAP that supports standard data formats, various SMGRs, and, if needed, third-party schedulers and execution engines, all while adhering to ACID principles. This is designed to achieve the fastest analytics on PostgreSQL (not just plugging in DuckDB).

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.

In today’s rapidly evolving technology landscape, PostgreSQL has emerged as a popular choice for organizations seeking to leverage the power of open-source databases while maintaining scalability, performance, and flexibility. 

As enterprises migrate from proprietary database systems like Oracle to PostgreSQL, developers face the challenge of adapting existing PL/SQL codebases to PL/pgSQL. Despite the similarities between these two procedural languages, significant differences in their syntax, performance characteristics, and ecosystem features require a thoughtful approach to migration and optimization. 

This session will focus on highlighting the key differences between Oracle’s PL/SQL and PostgreSQL’s PL/pgSQL, providing actionable insights on how to efficiently navigate these differences during migration. A deep dive will be taken into critical areas including compilation methodology, Code Debugging , Exception Handling, work_mem , Bulk Load and more.