PGConf.Russia 2025

This talk addresses a common issue and touches a bit on application architecture. Temporary tables in database applications are typically used for several purposes. 

Firstly, they are used to store intermediate results when implementing complex data processing algorithms. Secondly, in the case of stored procedures, application servers often place large datasets into temporary tables when they are too large or inconvenient to pass as parameters to stored procedures. 

The handling of temporary tables in different DBMSs is implemented in various ways, which often complicates migration from these systems to Postgres. 

The drawbacks of temporary tables are well-known, which leads to a reasonable desire to replace them, where possible, with other methods that can achieve the same goal. This talk focuses on alternative mechanisms provided by Postgres to solve this problem.

Covering all the key changes in PostgreSQL 18 during this talk would be quite a challenge — especially since the code freeze is set to happen just a week after the presentation. However, I’ll focus on what has already been finalized.

There are plenty of exciting updates in performance, monitoring, vacuuming (of course!), and beyond. As always, this talk is based on a series of articles reviewing the commit fests for PostgreSQL 18, published on Postgres Professional’s corporate blog on Habr.

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

For DBAs, ensuring database protection and integrity is always a top priority. Along with that comes the need to store data efficiently and compactly, without overloading the network, and ensuring reliable recovery.

In this talk, we’ll discuss a universal solution for backup and archive storage that not only offers effective deduplication but also minimizes network load. TATLIN.BACKUP is a platform for storing PostgreSQL backups or WAL archives with compression, deduplication, and minimal data transmission over the network.

TATLIN.BACKUP is a versatile solution for transferring and storing PostgreSQL archives at remote locations from a central office.