<?xml version='1.0' encoding='utf-8' ?>
<!-- Made with love by pretalx v2025.1.0. -->
<schedule>
    <generator name="pretalx" version="2025.1.0" />
    <version>0.5</version>
    <conference>
        <title>Prague PostgreSQL Developer Day 2026</title>
        <acronym>2026</acronym>
        <start>2026-01-27</start>
        <end>2026-01-28</end>
        <days>2</days>
        <timeslot_duration>00:05</timeslot_duration>
        <base_url>https://cfp.p2d2.cz</base_url>
        
        <time_zone_name>Europe/Prague</time_zone_name>
        
        
        <track name="SQL" slug="1-sql"  color="#01b155" />
        
        <track name="internals" slug="2-internals"  color="#e75b02" />
        
        <track name="performance" slug="3-performance"  color="#00aad5" />
        
        <track name="backups &amp; replication" slug="4-backups-replication"  color="#d30000" />
        
        <track name="containers" slug="5-containers"  color="#a0a0a0" />
        
        <track name="AI" slug="6-ai"  color="#d800f6" />
        
        <track name="security" slug="7-security"  color="#000000" />
        
        <track name="forks" slug="8-forks"  color="#ffc800" />
        
    </conference>
    <day index='1' date='2026-01-27' start='2026-01-27T04:00:00+01:00' end='2026-01-28T03:59:00+01:00'>
        <room name='T9:301' guid='4ac49969-a4e8-58a6-8e5b-dab7e0c76cfc'>
            <event guid='5ec3efbf-5d0e-514c-8679-4ed245c118d6' id='10'>
                <room>T9:301</room>
                <title>PostgreSQL Query Optimization: How to Write Efficient Queries</title>
                <subtitle></subtitle>
                <type>Workshop (half-day)</type>
                <date>2026-01-27T09:00:00+01:00</date>
                <start>09:00</start>
                <duration>03:30</duration>
                <abstract>Would you like to write queries that perform fast and deliver results on time? During this workshop, you will learn that query optimization is not a dark art practiced by a small group of sorcerers. Any motivated professional can learn to write efficient queries from the get-go and capably optimize existing queries. You will learn to look at the process of writing a query from the database engine&#8217;s point of view and know how to think like the database optimizer.</abstract>
                <slug>2026-10-postgresql-query-optimization-how-to-write-efficient-queries</slug>
                <track>performance</track>
                
                <persons>
                    <person id='17'>Hettie Dombrovskaya</person>
                </persons>
                <language>en</language>
                <description>Upon workshop completion, the participants will learn to:
- Identify optimization goals in OLTP (Online Transaction Processing)
and OLAP (Online Analytical Processing) systems
- Read and understand PostgreSQL execution plans
- Identify indexes that will improve query performance
- Optimize full table scans
- Distinguish between long queries and short queries
- Choose the correct optimization technique for each query type
- We will conclude the workshop by presenting  the Ultimate Optimization Algorithm</description>
                <recording>
                    <license></license>
                    <optout>true</optout>
                </recording>
                <links></links>
                <attachments></attachments>

                <url>https://cfp.p2d2.cz/2026/talk/HCKQAD/</url>
                <feedback_url>https://cfp.p2d2.cz/2026/talk/HCKQAD/feedback/</feedback_url>
            </event>
            <event guid='bb2cb4ed-0c0b-5576-90a9-fef2833b6f6b' id='46'>
                <room>T9:301</room>
                <title>PgBouncer - Everything, Everywhere, All At Once about this tool</title>
                <subtitle></subtitle>
                <type>Workshop (half-day)</type>
                <date>2026-01-27T13:30:00+01:00</date>
                <start>13:30</start>
                <duration>03:30</duration>
                <abstract>PgBouncer is widely used in PostgreSQL environments. Like any connection pooler, it has clear strengths and limits, and it has been applied across a range of production patterns. Recent releases added support for protocol&#8209;level prepared statements in transaction and statement pooling; in 2025 the project also made progress toward a multithreaded design.

In this half&#8209;day workshop we examine how PgBouncer&#8217;s current single&#8209;threaded event loop works and outline the proposed multithreaded approach. We&#8217;ll cover practical and experimental use cases and the configuration edges that matter in production&#8212;like scaling across cores with multiple processes on the same port via so_reuseport and peering and other interesting solutions. Attendees receive runnable examples for the key use cases as well as commented list of online resources.

Key takeaways:
* Know the trade&#8209;offs of this connection pooler
* Prepared statements can work in transaction/statement pooling
* PgBouncer is single&#8209;threaded today; scale across cores with multiple processes
* PgBouncer can help with HA/failover &#8212; but not alone
* A multithreaded architecture is on the horizon</abstract>
                <slug>2026-46-pgbouncer-everything-everywhere-all-at-once-about-this-tool</slug>
                <track>performance</track>
                
                <persons>
                    <person id='16'>Josef Machytka</person>
                </persons>
                <language>en</language>
                
                <recording>
                    <license></license>
                    <optout>true</optout>
                </recording>
                <links></links>
                <attachments></attachments>

                <url>https://cfp.p2d2.cz/2026/talk/3TMCQN/</url>
                <feedback_url>https://cfp.p2d2.cz/2026/talk/3TMCQN/feedback/</feedback_url>
            </event>
            
        </room>
        <room name='T9:302' guid='a5860d02-fc9d-5836-8ed5-7e4b059e44bd'>
            <event guid='2cafa85b-896b-50ec-8b5e-b2a4236d35dd' id='32'>
                <room>T9:302</room>
                <title>Running PostgreSQL in Kubernetes with CloudNativePG</title>
                <subtitle></subtitle>
                <type>Workshop (half-day)</type>
                <date>2026-01-27T09:00:00+01:00</date>
                <start>09:00</start>
                <duration>03:30</duration>
                <abstract>In this hands-on, 3-hour workshop, participants will learn how to deploy and manage PostgreSQL in Kubernetes using CloudNativePG (CNPG), the open source operator in the CNCF sandbox. The workshop will walk through the main features to manage a PostgreSQL cluster, from deploying the first CNPG cluster to managing configuration, databases, and roles in a declarative way, to enabling continuous backups for recovery from a disaster.

Attendees will manage the PostgreSQL cluster by applying the changes from the YAML manifest definition, demonstrating the declarative nature of the Operator. We will cover basic DBA managements, from DB initialization, to declarative SQL execution and DB import from other PG source, to reading the aggregated logs for investigation. Moreover we will show the benefits of using the CNPG operator for taking and restoring backups, and for its self-healing capabilities in case of incidents. This session is ideal for DevOps engineers, DBAs, and developers looking to operationalize PostgreSQL in Kubernetes.</abstract>
                <slug>2026-32-running-postgresql-in-kubernetes-with-cloudnativepg</slug>
                <track>containers</track>
                
                <persons>
                    <person id='27'>Jonathan</person><person id='39'>Danish</person>
                </persons>
                <language>en</language>
                <description>Following the instructions from the CNPG Playground project, anyone will create Kubernetes clusters on their own laptop using &quot;kind&quot;.

While the kind clusters will be created on each laptop, we will introduce the CNPG operator and basic concepts. We will walk the attendees to understand a bit of the Kubernetes world and the problems we are trying to solve with this PostgreSQL operator.

The course will cover the following points:

* Introduction to CloudNativePG (CNPG)
* Installation of the kubectl plugin for CNPG
* First deployment of a CNPG cluster
* PostgreSQL configuration, databases, and roles management
* Database import
* Setup and execution of the first backup
* PostgreSQL Extensions
* Incident simulation (failover showcase)
* Log reading
* Upgrade of the Operator and the PostgreSQL version (minor, and major)
* Restore from a backup.

To speed up the process, we will provide a link to download all the commands to actually follow the workshop in real time, without wasting precious minutes writing them or looking for typos in case of issues.

**Requirements**

To run the playground environment on their own laptops, participants only need to have one of the following installed:

* Docker Desktop
* Rancher Desktop

Either of these tools ensures that containers run consistently across all major operating systems&#8212;Windows, Linux, and macOS&#8212;without requiring any additional configuration.</description>
                <recording>
                    <license></license>
                    <optout>true</optout>
                </recording>
                <links></links>
                <attachments></attachments>

                <url>https://cfp.p2d2.cz/2026/talk/AFFEUF/</url>
                <feedback_url>https://cfp.p2d2.cz/2026/talk/AFFEUF/feedback/</feedback_url>
            </event>
            <event guid='c5db723d-0997-592b-b986-3d494f1a8bd0' id='52'>
                <room>T9:302</room>
                <title>pgwatch: From Zero to Hero!</title>
                <subtitle></subtitle>
                <type>Workshop (half-day)</type>
                <date>2026-01-27T13:30:00+01:00</date>
                <start>13:30</start>
                <duration>03:30</duration>
                <abstract>In this hands-on workshop, attendees will learn how to set up and operate pgwatch, a powerful open-source monitoring system designed specifically for PostgreSQL. Starting from a clean environment, we will go step-by-step through deploying pgwatch, connecting monitored databases, and exploring built-in Grafana dashboards. Participants will also learn best practices for managing pgwatch efficiently in production environments&#8212;covering configuration, data retention, and performance considerations.</abstract>
                <slug>2026-52-pgwatch-from-zero-to-hero</slug>
                <track>internals</track>
                
                <persons>
                    <person id='12'>Pavlo Golub</person>
                </persons>
                <language>en</language>
                <description>In this hands-on workshop, attendees will learn how to set up and operate **pgwatch**, a powerful open-source monitoring system designed specifically for PostgreSQL. Starting from a clean environment, we will go step-by-step through deploying pgwatch, connecting monitored databases, and exploring built-in Grafana dashboards. Participants will also learn best practices for managing pgwatch efficiently in production environments&#8212;covering configuration, data retention, and performance considerations.

**Key topics covered:**

* Introduction to pgwatch architecture and components
* Installing pgwatch from scratch (Docker or native setup)
* Connecting PostgreSQL instances and collecting metrics
* Understanding key metrics and visualizations in Grafana
* Managing multiple clusters and optimizing data storage
* Practical tips for troubleshooting and maintenance

**Expected outcomes:**
By the end of the session, participants will have a fully functional monitoring setup for PostgreSQL and the knowledge to adapt pgwatch to their own environments.

**Prerequisites:**

* Basic familiarity with PostgreSQL administration
* Laptop with Docker or a PostgreSQL environment available (any OS is fine &#8212; pgwatch is cross-platform)</description>
                <recording>
                    <license></license>
                    <optout>true</optout>
                </recording>
                <links></links>
                <attachments></attachments>

                <url>https://cfp.p2d2.cz/2026/talk/MDZLK7/</url>
                <feedback_url>https://cfp.p2d2.cz/2026/talk/MDZLK7/feedback/</feedback_url>
            </event>
            
        </room>
        <room name='T9:347' guid='49f19834-3630-5ccd-82ed-15b8b3fffe5b'>
            <event guid='7aa85e09-d255-5db3-8772-b5612d8637c7' id='54'>
                <room>T9:347</room>
                <title>Introduction to Postgres hacking</title>
                <subtitle></subtitle>
                <type>Workshop (full-day)</type>
                <date>2026-01-27T09:00:00+01:00</date>
                <start>09:00</start>
                <duration>08:00</duration>
                <abstract>This workshop is an introduction into hacking on Postgres code, to help people with their first steps. It is intended for those who are interested either in contributing to Postgres directly, or plan to work on some extensions, Postgres forks etc. If you don&apos;t plan to work on Postgres internals and write C code, this workshop may not be a good fit for you.</abstract>
                <slug>2026-54-introduction-to-postgres-hacking</slug>
                <track>internals</track>
                
                <persons>
                    <person id='3'>Tomas Vondra</person><person id='44'>Nazir Bilal Yavuz</person>
                </persons>
                <language>en</language>
                <description>The planned agenda is roughly this:

* Brief introduction into the development process and how it&#8217;s organized (mailing lists, commit fests, patch submissions, buildfarm, tools used to organize all this). We might also discuss how this might evolve in the future.
* Walk through the source code, to explain how it&#8217;s organized, what are the basic modules, where to look for stuff, what tools are available, etc.
* Basic work with the code (cloning, using configure, running various types of tests).
* Advanced stuff (using github CI, ...)
* Postgres-specific infrastructure and coding idioms (Datum, SQL vs. C functions, memory contexts and palloc, error logging, ...).

We plan to do small exercises to get some practical experience with these topics, so bring your Linux laptop with a recent distribution (Fedora, Ubuntu, Debian, ...). You won&#8217;t need anything very special, just console, git, gcc, and your favorite editor to write C code (we&#8217;ll setup the environment in the first section).

We expect basic knowledge of C, but we don&#8217;t expect you to know the strange/unique C stuff in Postgres. That&#8217;s what the workshop is meant to address. Prior experience with autotools is an advantage, not a requirement. After the workshop you should be familiar with how the Postgres project is organized, and with the fundamental tools and infrastructure used by Postgres. You may not be able to understand every patch right away, but you should have the foundations to quickly learn.</description>
                <recording>
                    <license></license>
                    <optout>false</optout>
                </recording>
                <links></links>
                <attachments></attachments>

                <url>https://cfp.p2d2.cz/2026/talk/BRPVYB/</url>
                <feedback_url>https://cfp.p2d2.cz/2026/talk/BRPVYB/feedback/</feedback_url>
            </event>
            
        </room>
        
    </day>
    <day index='2' date='2026-01-28' start='2026-01-28T04:00:00+01:00' end='2026-01-29T03:59:00+01:00'>
        <room name='105' guid='24f0f4e7-a3bc-5f2f-961c-5cfce6a05f3e'>
            <event guid='113b5eb2-17d8-5528-85ba-ed3c7f877f78' id='14'>
                <room>105</room>
                <title>The Art of Keeping PostgreSQL Clean: Internals, Autovacuum, and Controlled Deletion</title>
                <subtitle></subtitle>
                <type>Talk</type>
                <date>2026-01-28T09:20:00+01:00</date>
                <start>09:20</start>
                <duration>00:50</duration>
                <abstract>Large PostgreSQL tables never shrink on their own and deleting data at scale can easily cause more harm than good.
This talk focuses on how to safely clean up data in production without blocking workloads or causing vacuum storms.

We&#8217;ll explore real cleanup patterns , from partition drops and rebuild-and-reattach approaches to cursor- and CTE-based batched deletions , each designed to minimize lock contention and replication lag.
We&#8217;ll also examine what actually happens inside PostgreSQL when data is deleted: how tuples become dead, how autovacuum reclaims space, and why transaction age and WAL behavior matter for performance.

By the end, attendees will understand how to plan, execute, and automate cleanup in large, high-concurrency PostgreSQL environments  safely, continuously, and with full awareness of the engine&#8217;s internals.</abstract>
                <slug>2026-14-the-art-of-keeping-postgresql-clean-internals-autovacuum-and-controlled-deletion</slug>
                <track>internals</track>
                
                <persons>
                    <person id='18'>Cagri Biroglu</person>
                </persons>
                <language>en</language>
                
                <recording>
                    <license></license>
                    <optout>false</optout>
                </recording>
                <links></links>
                <attachments></attachments>

                <url>https://cfp.p2d2.cz/2026/talk/WQX3FA/</url>
                <feedback_url>https://cfp.p2d2.cz/2026/talk/WQX3FA/feedback/</feedback_url>
            </event>
            <event guid='d82ef4da-60f3-51e1-a7a7-4ff58fc20bf7' id='17'>
                <room>105</room>
                <title>SQL Injection Is Boring - Advanced Threats You&#8217;re Not Watching</title>
                <subtitle></subtitle>
                <type>Talk</type>
                <date>2026-01-28T10:15:00+01:00</date>
                <start>10:15</start>
                <duration>00:50</duration>
                <abstract>Everyone knows how to prevent basic SQL injection but modern attackers have moved far beyond textbook exploits. In high-traffic PostgreSQL deployments, subtle misconfigurations and overlooked features can open doors to far more sophisticated attacks.
This talk uncovers the next generation of database threats that rarely make it into security checklists. We&#8217;ll examine:
* Privilege Escalation via Extensions and Foreign Data Wrappers how seemingly harmless extensions or FDWs can leak credentials or access external systems.
* Timing and Side-Channel Attacks : extracting secrets by measuring query latency and caching behavior.
* Abusing Logical Replication and LISTEN/NOTIFY : stealthy data exfiltration channels hidden in plain sight.
* Role Inheritance &amp; Row-Level Security Pitfalls : ways attackers exploit complex permission hierarchies.
Attendees will learn how to recognize these attack surfaces, configure PostgreSQL securely, and implement defense-in-depth strategies such as strict role design, immutable infrastructure, and continuous auditing.
Whether you&#8217;re a DBA, developer, or security engineer, this session will challenge the assumption that SQL injection is the only real database risk and provide actionable steps to harden your PostgreSQL environment against today&#8217;s most overlooked threats.</abstract>
                <slug>2026-17-sql-injection-is-boring-advanced-threats-you-re-not-watching</slug>
                <track>internals</track>
                
                <persons>
                    <person id='19'>Kranthi Kiran Burada</person><person id='25'>Narendra Tawar</person>
                </persons>
                <language>en</language>
                
                <recording>
                    <license></license>
                    <optout>false</optout>
                </recording>
                <links></links>
                <attachments></attachments>

                <url>https://cfp.p2d2.cz/2026/talk/HGLVLL/</url>
                <feedback_url>https://cfp.p2d2.cz/2026/talk/HGLVLL/feedback/</feedback_url>
            </event>
            <event guid='28a94ed2-7d66-5e7a-9a7e-88b46f3d15f9' id='65'>
                <room>105</room>
                <title>Why your PostgreSQL tuning guide might be wrong (and what to do about it)</title>
                <subtitle></subtitle>
                <type>Talk</type>
                <date>2026-01-28T11:10:00+01:00</date>
                <start>11:10</start>
                <duration>00:50</duration>
                <abstract>Have you ever applied PostgreSQL tuning advice only to see no improvement&#8212;or made things worse? While generic PostgreSQL wisdom is valuable, the complexity of PostgreSQL makes catch-all solutions underperform in unexpected ways.
I will share examples where one PostgreSQL configuration improved performance in one system but hurt it in another&#8212;even for the same workload. The key insight: optimal PostgreSQL parameters depend heavily on your specific infrastructure characteristics. I&apos;ll present a checklist of important infrastructure differences&#8212;local vs network storage, IOPS limits, JIT availability, cloud vs on-premise&#8212;and demonstrate how these different environments require different optimal configurations for the same workload.
You&apos;ll leave understanding why generic tuning guides often fail and what infrastructure characteristics you need to consider when tuning YOUR specific PostgreSQL system.</abstract>
                <slug>2026-65-why-your-postgresql-tuning-guide-might-be-wrong-and-what-to-do-about-it</slug>
                <track>performance</track>
                <logo>/media/2026/submissions/GDJ7SE/me_fnfXdNH.jpeg</logo>
                <persons>
                    <person id='53'>Mohsin Ejaz</person>
                </persons>
                <language>en</language>
                
                <recording>
                    <license></license>
                    <optout>false</optout>
                </recording>
                <links></links>
                <attachments></attachments>

                <url>https://cfp.p2d2.cz/2026/talk/GDJ7SE/</url>
                <feedback_url>https://cfp.p2d2.cz/2026/talk/GDJ7SE/feedback/</feedback_url>
            </event>
            <event guid='1876b5c6-66a5-5f54-aedf-30e4cf18def7' id='80'>
                <room>105</room>
                <title>lightning talks</title>
                <subtitle></subtitle>
                <type>Talk</type>
                <date>2026-01-28T13:10:00+01:00</date>
                <start>13:10</start>
                <duration>01:00</duration>
                <abstract>* PostgreSQL Compatibility Index / Mayur
* Lutra language compiles to SQL / Alja&#382; Mur Er&#382;en
* Public Role - Critical Flaw / Michal Bartak
* Boldly Migrate to PostgreSQL with credativ-pg-migrator / Josef Machytka
* Making Access Control Management Easy: pg_acm / Hettie Dombrovskaya
* Shortest path using roaring bitmaps / Ants Aasma
* How did I end up using Postgres? / Serge
* pg_dance: Normalized Choreography with CloudNativePG / Jonathan Battiato and Ellyne Phneah
* PostgreSQL tuning meets Kubernetes: What breaks and how we automated It / Mohsin Ejaz
* Guessing application owner desires How to select important query groups without asking the app owner / Luigi Nardi
* Why pg_trgm Returned Zero Results: The ARM vs x86 Trap / Anton Borisov</abstract>
                <slug>2026-80-lightning-talks</slug>
                <track>SQL</track>
                
                <persons>
                    <person id='12'>Pavlo Golub</person>
                </persons>
                <language>cs</language>
                
                <recording>
                    <license></license>
                    <optout>false</optout>
                </recording>
                <links></links>
                <attachments></attachments>

                <url>https://cfp.p2d2.cz/2026/talk/RHHJDT/</url>
                <feedback_url>https://cfp.p2d2.cz/2026/talk/RHHJDT/feedback/</feedback_url>
            </event>
            <event guid='3cdab0e4-58c2-53ca-93e4-732629ff2002' id='23'>
                <room>105</room>
                <title>What you should know about constraints in PostgreSQL (and what&apos;s new in 18)</title>
                <subtitle></subtitle>
                <type>Talk</type>
                <date>2026-01-28T14:15:00+01:00</date>
                <start>14:15</start>
                <duration>00:50</duration>
                <abstract>PostgreSQL 18 introduced significant enhancements to constraints, your first line of defense for maintaining data integrity. This talk focuses on the new capabilities brought by version 18, including temporal PK/UK and FKs, NOT NULL constraints being promoted to first-class constraints, new NOT ENFORCED constraints, and improved support for partitioned tables. We&#8217;ll look at what&#8217;s new, why it matters, and how to apply these features in real-world systems.

We&#8217;ll begin with a brief refresher on the different types of constraints to help you get the most out of PostgreSQL&#8217;s declarative integrity model by looking at the pg_constraint catalog.

Then we&#8217;ll go into the details of what&#8217;s new in PostgreSQL 18 and what you should take away from these changes.</abstract>
                <slug>2026-23-what-you-should-know-about-constraints-in-postgresql-and-what-s-new-in-18</slug>
                <track>SQL</track>
                
                <persons>
                    <person id='23'>Gulcin Yildirim Jelinek</person>
                </persons>
                <language>en</language>
                
                <recording>
                    <license></license>
                    <optout>false</optout>
                </recording>
                <links></links>
                <attachments></attachments>

                <url>https://cfp.p2d2.cz/2026/talk/B8QJAL/</url>
                <feedback_url>https://cfp.p2d2.cz/2026/talk/B8QJAL/feedback/</feedback_url>
            </event>
            <event guid='e6944215-2d11-5884-b7f8-69fd591777e7' id='33'>
                <room>105</room>
                <title>Vacuuming Large Tables: How Recent Postgres Changes Further Enable Mission Critical Workloads</title>
                <subtitle></subtitle>
                <type>Talk</type>
                <date>2026-01-28T15:35:00+01:00</date>
                <start>15:35</start>
                <duration>00:50</duration>
                <abstract>Follow along as we deep dive into a real-world transaction wraparound incident, discuss recent Postgres innovations, and explore features like index de-duplication and autovacuum enhancements designed to help eliminate the problems. We&apos;ll talk about how to optimize your Postgres environment and make a strong case why upgrading might just eliminate your XID wraparound risks.</abstract>
                <slug>2026-33-vacuuming-large-tables-how-recent-postgres-changes-further-enable-mission-critical-workloads</slug>
                <track>internals</track>
                
                <persons>
                    <person id='29'>Robert Treat</person>
                </persons>
                <language>en</language>
                <description>We have all heard about Postgres vacuum horror stories and tales of transaction wraparound disasters. Even if you&apos;ve never been through one yourself, you may be concerned that you might someday experience it, or maybe you even know people who have avoided Postgres altogether due to fear of it happening to them. But it doesn&apos;t have to be this way.

In this talk, we will explore this topic through a review of a real-world wraparound incident, walking through the challenges and hope offered by changes in the last several Postgres releases. We&apos;ll explore the inner workings of the Postgres vacuum process, its dual purpose of managing both disk bloat and transaction IDs (XIDs), and how recent innovations have improved this process, particularly for large tables with heavy transaction loads. We&apos;ll dive deep into key features like: - How index de-duplication minimizes vacuum workloads and improves efficiency. - How on/off index vacuuming gives you better control during maintenance windows. - Why one key autovacuum enhancement may be the key for eliminating XID wraparounds.

Beyond theory, we&apos;ll revisit the real-world incident and see how each new Postgres feature could have helped mitigate the impact. While no single change is a silver bullet, the combined effect is significant. We&apos;ll also explore how the radix tree implementation in Postgres 17 might be the possible final piece of the puzzle for providing a manageable solution to XID wraparound risks.

This talk equips DBAs with a deeper understanding of recent Postgres advancements and their practical application in managing high-transactional and/or mission-critical workloads. You&apos;ll leave with actionable insights to optimize your Postgres environment and concrete arguments to convince management that it is worth the upgrade for the potential to minimize the risk of XID wraparound incidents.</description>
                <recording>
                    <license></license>
                    <optout>true</optout>
                </recording>
                <links></links>
                <attachments></attachments>

                <url>https://cfp.p2d2.cz/2026/talk/GMZKNF/</url>
                <feedback_url>https://cfp.p2d2.cz/2026/talk/GMZKNF/feedback/</feedback_url>
            </event>
            <event guid='fc6c4310-2637-5ced-a16e-1d5fc9955b9c' id='47'>
                <room>105</room>
                <title>PostgreSQL Query Performance Monitoring for the Absolute Beginner</title>
                <subtitle></subtitle>
                <type>Talk</type>
                <date>2026-01-28T16:30:00+01:00</date>
                <start>16:30</start>
                <duration>00:50</duration>
                <abstract>You may know that your database is slow, or, you may be told that there are performance problems in the database. However, how do you know where the performance problems are? Which queries are running the slowest? Why are they running slow? This session will take you through the fundamental tools that are built right into PostgreSQL that can help you answer all these questions. We&apos;ll start with using queries against the Cumulative Statistics Systems. We&apos;ll begin an exploration of explain plans. Setup and guidance for how all these tools work will be provided along the way. You can finally know which queries are slow, and why they are slow.</abstract>
                <slug>2026-47-postgresql-query-performance-monitoring-for-the-absolute-beginner</slug>
                <track>performance</track>
                
                <persons>
                    <person id='41'>Grant Fritchey</person>
                </persons>
                <language>en</language>
                
                <recording>
                    <license></license>
                    <optout>false</optout>
                </recording>
                <links></links>
                <attachments></attachments>

                <url>https://cfp.p2d2.cz/2026/talk/KGNTVC/</url>
                <feedback_url>https://cfp.p2d2.cz/2026/talk/KGNTVC/feedback/</feedback_url>
            </event>
            
        </room>
        <room name='155' guid='d1be941a-fdbe-551e-b3d9-96837abaad02'>
            <event guid='23f768cf-e5ad-5ad2-be0b-c1c62775808e' id='72'>
                <room>155</room>
                <title>B-Tree Index Access Paths: Tuning Today and Tomorrow&#8221;</title>
                <subtitle></subtitle>
                <type>Talk</type>
                <date>2026-01-28T09:20:00+01:00</date>
                <start>09:20</start>
                <duration>00:50</duration>
                <abstract>This talk introduces the key access paths for B-tree indexes in PostgreSQL. Based on over ten years of experience with Oracle&#8217;s index skip scan, I will highlight common problems it can cause and show practical ways to avoid them in PostgreSQL. I will briefly demo DB Booster, a tool that automatically finds missing indexes, and discuss the future of index tuning in relational databases&#8212;self-tuning engines and PostgreSQL&#8217;s place in that shift.</abstract>
                <slug>2026-72-b-tree-index-access-paths-tuning-today-and-tomorrow</slug>
                <track>performance</track>
                
                <persons>
                    <person id='40'>Jakub Kuzela</person>
                </persons>
                <language>en</language>
                <description>Whatever will fit in 45 minutes:

-Index tuning introduction - fast, effective, impactful
-Table without any index
-B-Tree: the basic index
-Why does the B-Tree index work
-Index Seek
-Index Scan
-Index Skip Scan
-Real-life issues with the Skip Scan in Oracle
-How to avoid these issues in PotsgreSQL
-Automated indexing - DB Booster
-The future of the databases - self-tuning engines</description>
                <recording>
                    <license></license>
                    <optout>false</optout>
                </recording>
                <links></links>
                <attachments></attachments>

                <url>https://cfp.p2d2.cz/2026/talk/ZFWHEY/</url>
                <feedback_url>https://cfp.p2d2.cz/2026/talk/ZFWHEY/feedback/</feedback_url>
            </event>
            <event guid='38b58aa5-4661-5c08-b8c7-683361438579' id='39'>
                <room>155</room>
                <title>What&apos;s Missing in Postgres?</title>
                <subtitle></subtitle>
                <type>Talk</type>
                <date>2026-01-28T10:15:00+01:00</date>
                <start>10:15</start>
                <duration>00:50</duration>
                <abstract>Postgres adds about 180 features and changes every year, yet it is missing some major ones.  This talk explains what those features are, and why they have not been implemented. The features include sharding, TDE, global indexes, and multi-master replication.</abstract>
                <slug>2026-39-what-s-missing-in-postgres</slug>
                <track>SQL</track>
                
                <persons>
                    <person id='35'>Bruce Momjian</person>
                </persons>
                <language>en</language>
                
                <recording>
                    <license></license>
                    <optout>false</optout>
                </recording>
                <links></links>
                <attachments></attachments>

                <url>https://cfp.p2d2.cz/2026/talk/A3ZQRJ/</url>
                <feedback_url>https://cfp.p2d2.cz/2026/talk/A3ZQRJ/feedback/</feedback_url>
            </event>
            <event guid='ce7ffcdc-0158-53b3-b30c-41778ffcd65a' id='42'>
                <room>155</room>
                <title>Do ORMs make you happy OR Mad?</title>
                <subtitle></subtitle>
                <type>Talk</type>
                <date>2026-01-28T11:10:00+01:00</date>
                <start>11:10</start>
                <duration>00:50</duration>
                <abstract>The story of a database engineer coming to the world of strongly typed programming languages. How have I found my favorite way of building Go services on top of PostgreSQL database. Introduction to sqlc, what&apos;s so great about it, what&apos;s not ideal and how to fix that and where it fails completely.</abstract>
                <slug>2026-42-do-orms-make-you-happy-or-mad</slug>
                <track>SQL</track>
                
                <persons>
                    <person id='28'>Petr &#352;mejkal</person>
                </persons>
                <language>cs</language>
                
                <recording>
                    <license></license>
                    <optout>false</optout>
                </recording>
                <links></links>
                <attachments></attachments>

                <url>https://cfp.p2d2.cz/2026/talk/NFDMRG/</url>
                <feedback_url>https://cfp.p2d2.cz/2026/talk/NFDMRG/feedback/</feedback_url>
            </event>
            <event guid='194a02c0-6dbb-511c-9076-4b7acebd19b9' id='15'>
                <room>155</room>
                <title>Operational hazards of managing PostgreSQL DBs over 100TB</title>
                <subtitle></subtitle>
                <type>Talk</type>
                <date>2026-01-28T14:15:00+01:00</date>
                <start>14:15</start>
                <duration>00:50</duration>
                <abstract>Picture this: you start a new role, eager to learn and contribute with your ideas! Your next task is to get familiar with the database setup, and then you start encountering these massive PostgreSQL databases &#8212; 100TB, 200TB, 300TB...

And you start questioning yourself: how do you backup (and restore) a +100TB database? And how about HA? Performance? Vacuum?

It should work the same way as for a 100GB database, right? Well, maybe not exactly.

Blog posts and best practice guides make PostgreSQL seem straightforward&#8212;until you push it to its limits. At extreme scale, you will find yourself questioning the most fundamental assumptions about how PostgreSQL works.

Over the last years, my team at Adyen has been exploring the boundaries of what PostgreSQL can do, and today I will share our findings with you (at least the ones I can!).</abstract>
                <slug>2026-15-operational-hazards-of-managing-postgresql-dbs-over-100tb</slug>
                <track>performance</track>
                
                <persons>
                    <person id='5'>Teresa Lopes</person>
                </persons>
                <language>en</language>
                
                <recording>
                    <license></license>
                    <optout>true</optout>
                </recording>
                <links></links>
                <attachments></attachments>

                <url>https://cfp.p2d2.cz/2026/talk/JD8TSM/</url>
                <feedback_url>https://cfp.p2d2.cz/2026/talk/JD8TSM/feedback/</feedback_url>
            </event>
            <event guid='7c151573-1dd7-511b-ae6b-82200a2da238' id='76'>
                <room>155</room>
                <title>A benchmark study on the impact of PostgreSQL server parameter tuning</title>
                <subtitle></subtitle>
                <type>Talk</type>
                <date>2026-01-28T15:35:00+01:00</date>
                <start>15:35</start>
                <duration>00:50</duration>
                <abstract>PostgreSQL, renowned for its extensibility and robust feature set, offers a wealth of server configuration parameters that can significantly influence its performance. Most PostgreSQL users operate with default parameters, which are often not optimized for commonly used server machine flavors. This talk is a comprehensive benchmark analysis exploring the potential performance benefits achievable through server parameter tuning. We&apos;ll examine the impact of various parameter configurations on diverse workloads, ranging from OLTP to OLAP, and provide an analysis that highlights the performance gains and show that these depend on several factors related to the computing environment and workloads. This talk helps database administrators and developers with actionable insights for maximizing PostgreSQL performance through effective server parameter tuning.</abstract>
                <slug>2026-76-a-benchmark-study-on-the-impact-of-postgresql-server-parameter-tuning</slug>
                <track>performance</track>
                
                <persons>
                    <person id='58'>Luigi Nardi</person>
                </persons>
                <language>en</language>
                
                <recording>
                    <license></license>
                    <optout>false</optout>
                </recording>
                <links></links>
                <attachments></attachments>

                <url>https://cfp.p2d2.cz/2026/talk/YCZ9KL/</url>
                <feedback_url>https://cfp.p2d2.cz/2026/talk/YCZ9KL/feedback/</feedback_url>
            </event>
            <event guid='32e81dbd-40b4-5eba-be07-acd3944e3c29' id='63'>
                <room>155</room>
                <title>It works on my database - Regression testing of SQL queries</title>
                <subtitle></subtitle>
                <type>Talk</type>
                <date>2026-01-28T16:30:00+01:00</date>
                <start>16:30</start>
                <duration>00:50</duration>
                <abstract>SQL queries often lack systematic testing - they&apos;re treated as &quot;just glue code&quot; that only gets validated in production. Meanwhile, PostgreSQL itself has used robust regression testing for decades to prevent disasters in core development. This talk introduces RegreSQL, a tool that brings the same regression testing methodology to application queries, catching both correctness bugs and performance regressions before deployment.

We&apos;ll explore how RegreSQL tests SQL queries systematically: verifying correctness across schema changes, tracking performance baselines, detecting common query plan issues (sequential scans, missing indexes), and managing reproducible test data. You&apos;ll see live demonstrations of catching real-world issues - from missing indexes that cause production slowdowns to ORM-generated queries that perform sequential scans on millions of rows.

Whether you write raw SQL or use ORMs, whether you&apos;re maintaining legacy systems or building greenfield applications, this talk will show you practical techniques for making your PostgreSQL queries testable, maintainable, and production-ready.</abstract>
                <slug>2026-63-it-works-on-my-database-regression-testing-of-sql-queries</slug>
                <track>SQL</track>
                
                <persons>
                    <person id='51'>Radim Marek</person>
                </persons>
                <language>en</language>
                <description>Target Audience:

- Application developers who work with PostgreSQL daily
- Teams struggling with SQL-related production incidents
- DBAs looking to improve query quality from development teams

While the talk introduces RegreSQL as an open source project, it&apos;s meant to open discussion on the wider topics of improving developer experience and stability of production deployments in database applications backed by PostgreSQL.</description>
                <recording>
                    <license></license>
                    <optout>false</optout>
                </recording>
                <links></links>
                <attachments></attachments>

                <url>https://cfp.p2d2.cz/2026/talk/Z9FU8V/</url>
                <feedback_url>https://cfp.p2d2.cz/2026/talk/Z9FU8V/feedback/</feedback_url>
            </event>
            
        </room>
        <room name='107' guid='54387087-b750-51db-95b1-9c7c364b6489'>
            <event guid='422426c4-2d41-5478-9ab3-b8dfc7bbfa67' id='59'>
                <room>107</room>
                <title>Rediscovering PgQ</title>
                <subtitle></subtitle>
                <type>Talk</type>
                <date>2026-01-28T09:20:00+01:00</date>
                <start>09:20</start>
                <duration>00:50</duration>
                <abstract>Modern applications often rely on message queues - for  background jobs, data pipelines, notifications, and event-driven architectures. Using something external like Kafka, Redis, RabbitMQ, etc increases operational complexity and introduces new failure modes. It all could be avoided by keeping a message queue in a database.

Quick research on the internet shows that developers commonly are trying to engineer the database queue based on SELECT &#8230; FOR UPDATE SKIP LOCKED (available since 9.5). This approach works reasonably well under small load, and spectacularly falls apart if subscribers can&#8217;t keep up with publishing rate. PostgreSQL can do better - and in fact, it already did. PgQ is PostgreSQL extension that provides generic, high-performance lockless queue with simple SQL.

In this talk, we start with why common SELECT &#8230; FOR UPDATE SKIP LOCKED approaches fall apart under load, and how PgQ quietly solved those problems a couple decades ago. Then we take a deep look at PgQ internals: snapshot-based event reads, transaction-ordered delivery, and how PgQ gets away with just a single index to achieve high throughput and consistency. Finally, we will discuss practical patterns for running PgQ on managed PostgreSQL services where this extension is typically not available.

https://github.com/pgq/pgq/</abstract>
                <slug>2026-59-rediscovering-pgq</slug>
                <track>SQL</track>
                
                <persons>
                    <person id='47'>Alexander Kukushkin</person>
                </persons>
                <language>en</language>
                
                <recording>
                    <license></license>
                    <optout>false</optout>
                </recording>
                <links></links>
                <attachments></attachments>

                <url>https://cfp.p2d2.cz/2026/talk/7GVFDS/</url>
                <feedback_url>https://cfp.p2d2.cz/2026/talk/7GVFDS/feedback/</feedback_url>
            </event>
            <event guid='7a6bb9ce-55be-5541-91e1-7242da70077e' id='37'>
                <room>107</room>
                <title>Switching Me Softly: Zero-downtime Major PostrgreSQL Upgrades at Fresha</title>
                <subtitle></subtitle>
                <type>Talk</type>
                <date>2026-01-28T10:15:00+01:00</date>
                <start>10:15</start>
                <duration>00:50</duration>
                <abstract>Upgrading PostgreSQL in production is rarely about tools, it&#8217;s about timing, trust, and everything that can break in between.
At Fresha we had quute a few of Postgres 12 databases, streaming changes through Debezium into Kafka, serving live traffic around the clock. With end-of-life approaching, &#8220;just run pg_upgrade&#8221; wasn&#8217;t an option.

We built a blue-green upgrade process based on logical replication, sequence offsets, connector handover, and PgBouncer choreography: a way to move clusters forward without downtime or broken streams.
This talk shares how we made it repeatable: YAML configs, dry-run rehearsals, reversible scripts, and a few hard lessons learned along the way.

When the switch finally happened, no one noticed. That&#8217;s how you know it worked.</abstract>
                <slug>2026-37-switching-me-softly-zero-downtime-major-postrgresql-upgrades-at-fresha</slug>
                <track>backups &amp; replication</track>
                <logo>/media/2026/submissions/CKPR7B/bojan_copy1_a5FtxHQ.png</logo>
                <persons>
                    <person id='34'>Anton Borisov</person>
                </persons>
                <language>en</language>
                <description>This talk expands on Fresha&#8217;s Switching Me Softly framework: a production-tested zero-downtime upgrade path from PostgreSQL 12 &#8594; 17.

It covers:

* Logical replication with WAL origin alignment

* Coordinating Debezium CDC and outbox connectors

* PgBouncer two-phase switchover (read-only &#8594; write)

* YAML-driven orchestration and dry-run safety modes


We upgraded dozens of databases, including multi-terabyte clusters, without a second of downtime.
The session focuses on real engineering trade-offs what worked, what didn&#8217;t, and how to make major PostgreSQL upgrades safe, reversible, and boring.</description>
                <recording>
                    <license></license>
                    <optout>false</optout>
                </recording>
                <links></links>
                <attachments></attachments>

                <url>https://cfp.p2d2.cz/2026/talk/CKPR7B/</url>
                <feedback_url>https://cfp.p2d2.cz/2026/talk/CKPR7B/feedback/</feedback_url>
            </event>
            <event guid='52f1ad63-a633-5bde-9b7a-767bd5ec7c9f' id='24'>
                <room>107</room>
                <title>TimescaleDB - collecting and visualizing IOT data</title>
                <subtitle></subtitle>
                <type>Talk</type>
                <date>2026-01-28T11:10:00+01:00</date>
                <start>11:10</start>
                <duration>00:50</duration>
                <abstract>The session provides a walkthrough of key TimescaleDB features used for IoT data collection and visualization. It explores the functionality and benefits of continuous aggregates (CAGGs), data compression, and data retention - highlighting how these features relate to each other and how to maintain them effectively.

The talk also compares approaches tailored to different data characteristics (dense vs. sparse datasets) and discusses how these choices impact downstream tools such as Grafana dashboards.</abstract>
                <slug>2026-24-timescaledb-collecting-and-visualizing-iot-data</slug>
                <track>forks</track>
                <logo>/media/2026/submissions/WSQKUL/IMG_6166_AgFmbOU.jpeg</logo>
                <persons>
                    <person id='24'>Michal Bartak</person>
                </persons>
                <language>cs</language>
                
                <recording>
                    <license></license>
                    <optout>false</optout>
                </recording>
                <links></links>
                <attachments></attachments>

                <url>https://cfp.p2d2.cz/2026/talk/WSQKUL/</url>
                <feedback_url>https://cfp.p2d2.cz/2026/talk/WSQKUL/feedback/</feedback_url>
            </event>
            <event guid='736cd715-21ce-53a9-b334-140eff430cee' id='55'>
                <room>107</room>
                <title>Hey, I&apos;m using that! Fixing lock contention in OLTP.</title>
                <subtitle></subtitle>
                <type>Talk</type>
                <date>2026-01-28T14:15:00+01:00</date>
                <start>14:15</start>
                <duration>00:50</duration>
                <abstract>Some transaction processing workloads end up with horrible lock contention because they end up blocked on updating the same rows. There are now databases that advertise running this workload a 1000 times faster than PostgreSQL. In this talk will discuss strategies how to manage this contention in PostgreSQL while retaining application correctness. How network latencies, different isolation levels, optimistic and pessimistic concurrency control, deadlocks and livelocks affect the capability to get work done. Working with the database allows us to take a large step closer to single-purpose database performance while staying in our familiar PostgreSQL land.</abstract>
                <slug>2026-55-hey-i-m-using-that-fixing-lock-contention-in-oltp</slug>
                <track>performance</track>
                
                <persons>
                    <person id='45'>Ants Aasma</person>
                </persons>
                <language>en</language>
                
                <recording>
                    <license></license>
                    <optout>false</optout>
                </recording>
                <links></links>
                <attachments></attachments>

                <url>https://cfp.p2d2.cz/2026/talk/UEBNWK/</url>
                <feedback_url>https://cfp.p2d2.cz/2026/talk/UEBNWK/feedback/</feedback_url>
            </event>
            <event guid='3972fb7a-959c-5a81-871c-1e3b2b31da20' id='70'>
                <room>107</room>
                <title>Cloud-native Postgres observability: from client apps to underlying cloud resources</title>
                <subtitle></subtitle>
                <type>Talk</type>
                <date>2026-01-28T15:35:00+01:00</date>
                <start>15:35</start>
                <duration>00:50</duration>
                <abstract>In the current era of cloud computing, the days of managing single-app systems with standalone databases are long gone. Instead, we find ourselves responsible for overseeing complex systems containing hundreds of services and dozens of databases. Adding to the challenge is the dynamic nature of these systems, where databases can migrate between nodes, and their storage performance can be adjusted on the fly.
In this presentation, we will explore strategies for maintaining observability of Postgres databases in complex cloud environments. Topics include leveraging eBPF for generating comprehensive service maps and instrumenting Postgres calls across various client applications to specific databases. Additionally, we explore automatic discovery mechanisms for topologies within High Availability (HA) Postgres clusters, facilitated by different Kubernetes Operators. Furthermore, the talk addresses the importance of monitoring underlying cloud resources, encompassing virtual machines (VMs), storage volumes, and network components.</abstract>
                <slug>2026-70-cloud-native-postgres-observability-from-client-apps-to-underlying-cloud-resources</slug>
                <track>containers</track>
                
                <persons>
                    <person id='55'>Peter Zaitsev</person>
                </persons>
                <language>en</language>
                
                <recording>
                    <license></license>
                    <optout>false</optout>
                </recording>
                <links></links>
                <attachments></attachments>

                <url>https://cfp.p2d2.cz/2026/talk/Q7EWET/</url>
                <feedback_url>https://cfp.p2d2.cz/2026/talk/Q7EWET/feedback/</feedback_url>
            </event>
            <event guid='81bb47e9-7679-5f8e-8e0c-77a8b2a51851' id='44'>
                <room>107</room>
                <title>Knocking at the Door: Fuzzing libpq and PgBouncer</title>
                <subtitle></subtitle>
                <type>Talk</type>
                <date>2026-01-28T16:30:00+01:00</date>
                <start>16:30</start>
                <duration>00:50</duration>
                <abstract>Fuzzing is a simple but powerful technique for discovering edge-case bugs in large, stateful systems like PostgreSQL.

This talk shows how to apply it to Postgres&#8217; client library libpq and commonly used connection pooler PgBouncer - both handle every network connection before the server sees a query.

We&#8217;ll walk through building minimal harnesses, generating and mutating protocol inputs, and reasoning about what makes fuzzing effective on complex C codebases.

The session is meant as a practical guide: how to start fuzzing a Postgres-related project, what challenges to expect, and what kind of issues you can realistically uncover along the way.</abstract>
                <slug>2026-44-knocking-at-the-door-fuzzing-libpq-and-pgbouncer</slug>
                <track>security</track>
                
                <persons>
                    <person id='37'>Adam Wolk</person>
                </persons>
                <language>en</language>
                <description>In this session you will learn:
* what fuzzing is and why it finds bugs other techniques miss
* which PostgreSQL surfaces make good fuzzing targets and why
* how to apply fuzzing to Postgres networking components (libpq, PgBouncer)

If you&#8217;re a PostgreSQL developer, this talk will add another tool for improving the stability and security of the projects you build.</description>
                <recording>
                    <license></license>
                    <optout>false</optout>
                </recording>
                <links></links>
                <attachments></attachments>

                <url>https://cfp.p2d2.cz/2026/talk/9AHQ7F/</url>
                <feedback_url>https://cfp.p2d2.cz/2026/talk/9AHQ7F/feedback/</feedback_url>
            </event>
            
        </room>
        
    </day>
    
</schedule>
