PGConf.Russia 2025

This presentation examines the challenges of migrating an application system from Oracle to Postgres, based on a real-world project. It provides a detailed discussion on logical replication of data from Postgres to ensure the possibility of reverting back to Oracle while maintaining the functionality of legacy reporting and integration.

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.

Experience Report addressing the manual migration of MS SQL Server Stored Procedures and Table-Valued Functions to PL/pgSQL. We chose a manual migration from T-SQL over using a PostgreSQL Extension with an automated translation. The motivation was that the T-SQL code contains non-trivial business logic for which we wanted idiomatic PL/pgSQL code. 

The T-SQL Code used features like 

• Mix of Stored Procedures and Table-valued Functions

• Table variables, (user-defined) table types 

• Recursive Common Table Expressions 

• Optional parameters 

The migration required

• Adopting naming conventions 

• Renaming parameters and local variables 

• Maping table types 

• Mapping table-valued parameters to arrays 

• Mapping table-valued return types to SETOF record

• Translating between arrays and tables 

In this session we will migrate a chain of dependend functions T-SQL functions to PL/pgSQL. We will work around quirks in both T-SQL functions and PL/pgSQL.