PGConf.Russia 2025

As part of the import substitution process, we encountered the need to find a reliable alternative to Oracle. PostgreSQL was considered the primary candidate for replacement, but during the research, the "vanilla" version revealed a number of critical limitations that hindered a successful transition.

These issues included support for autonomous transactions, batch variables, and several other specifics. What is special about pg_settings? Why do we need autonomous transactions, and how do HOLD cursors relate to this? These and other topics will be discussed in our presentation, where we will also share our experience of implementing Postgres Pro Enterprise.

In this talk, we’ll:

• Share our experience of reworking the ECM system and platform that was originally built on C.Net + MS SQL for Windows to run on Linux + Postgres, while maintaining the option to install and operate on Windows + MS.

• Discuss migrating clients to new platforms with data migration.

• Share insights from operating the system with a high-load client (PG servers with 192 cores and 3 TB of RAM).

In this talk, I will challenge architectural stereotypes about the impossibility of communication with external systems directly from a DBMS. PostgreSQL offers vast communication capabilities; you just need to know which extensions to use.

And when extensions aren't enough, you can create your own. For the Luxms BI project, we needed communication with NATS, so we developed our own extension in Rust. I’ll share the GitHub link and my experience of developing PostgreSQL extensions in Rust during this talk.

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).