PGConf.Russia 2025

Every day, thousands of engineers work tirelessly to make data more accurate, reliable, and up-to-date. But sometimes, we need to do the exact opposite—corrupt it.

Whether it’s masking or replacing sensitive information, or even generating entirely new datasets while preserving key business properties, data obfuscation is a crucial task. It’s essential for testing systems, sharing data with third parties, and more. However, given the complexity of data schemas and business logic, this is far from trivial.

In this talk, we’ll explore the challenges of working with artificial data and discuss various approaches to solving them using PostgreSQL’s built-in features and external extensions.

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

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.

Making changes to tables under production load is always a complex task. For example, when you need to change a column type (e.g., from int to bigint or from timestamp to timestamptz), or move a table to a different tablespace without losing any changes that occur during the data migration.

What if you have hundreds of such tables? With pg-transparent-alter-table, this is no longer a problem. These tasks can be solved with a single simple command:
$ pg_tat -h 0.0.0.0 -d mydb -c "alter table mytable alter column id bigint"

Key features include:

• You can specify any number of alter table commands at once.
• You can modify partitioned tables, supporting both the old inheritance-based partitioning and new declarative partitioning, including multi-level partitioning.
• You can interrupt the process at any stage and continue later without losing progress from previous stages.
• You can change your mind at any time, stop the execution, run "pg_tat --clean," and revert to the original state.
• Custom commands for changing column order.
• PostgreSQL version support: 11-17.

After more than 5 years of existence (previously called transparent-alter-type), the project has become a reliable tool actively used in production. I would like to share my experience and discuss its capabilities.