PGConf.Russia 2025

Where I used to work, we had pushed ElasticSearch to its breaking point. We needed an even more scalable replacement for a write-heavy, read-seldom workload. So we built one on PostgreSQL. Now, many of us are building the successor as an open source project. 

This talk goes over the design of Bagger (named after the giant mining machines), which can manage logs into tens or hundreds of petabytes. More than just a review of the architecture, this talk focuses on the whys and the tradeoffs made in the design. 

The talk is intended both to showcase how programmable and powerful PostgreSQL is, but also illustrate the fundamental tradeoffs which must be faced when pushing any technology into the big data space.

t’s well known that pg_upgrade is the go-to tool for fast PostgreSQL upgrades. However, even with this tool, there are cases where the upgrade process takes far longer than expected.

In our case, upgrading a PostgreSQL database with 350,000 tables meant either waiting 3.5 hours or finding a better approach. By digging into the pg_upgrade source code, we discovered a way to speed up the process significantly. In this talk, we’ll share how we did it.

This talk explores the challenges we encountered — and solved — while migrating massive databases from Oracle to PostgreSQL.

One of the most complex aspects of this process was rebuilding foreign keys (FKs). To overcome these challenges, we had to dive deep into the internal workings of FK creation and validation.

Key topics include:

Does ALTER TABLE ... ADD CONSTRAINT ... FOREIGN KEY have an execution plan?

Can an ordinary user influence this process?

What locks are applied during FK creation and validation?

Also, we’ll introduce a first-principles method for investigating performance issues, applying it to a real-world FK creation bottleneck.

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.