PGConf.Russia 2025

The visibility map in PostgreSQL is an important mechanism for optimizing database performance, accelerating read operations, data cleanup, and indexing. Despite some limitations, such as memory consumption and fragmentation, its use can significantly enhance performance in high-load systems. Effective utilization of the visibility map requires proper configuration and monitoring, which is especially crucial in systems with large data volumes and high transaction concurrency.

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.

Two years ago, I spoke about data retrieval queries, where the LINQ to DB library offers almost limitless possibilities.

This talk is about data modification operations. LINQ to DB allows you to execute UPDATE + JOIN queries, INSERT FROM SELECT, supports the MERGE operator, row-level locking with SELECT FOR UPDATE, temporary table creation, and features a fast data insertion mechanism.

I will also discuss the linq2db. EntityFrameworkCore project — a solution for those who aren’t ready to leave EF Core but still want the capabilities of LINQ to DB. I’ll share our experience implementing LINQ to DB in a large-scale project.

Currently, WAL files can be compressed with a ratio of up to 6x, but the existing compression system is inefficient.

In this talk, I’ll share my work on improving WAL compression.