Firefly2026-10-202026-10-234https://www.postgresql.eu/events/pgconfeu2026/schedule/08:1501:15OtherCome and collect your conference badges.https://www.postgresql.eu/events/pgconfeu2026/schedule/session/8508/Breaks09:3000:15Audit 1Welcome everybody to PostgreSQL Conference Europe 2026!https://www.postgresql.eu/events/pgconfeu2026/schedule/session/8501/PGConf.EU09:4501:00Audit 1Coming Soon!https://www.postgresql.eu/events/pgconfeu2026/schedule/session/8502/PGConf.EU10:4500:30Otherhttps://www.postgresql.eu/events/pgconfeu2026/schedule/session/8492/Breaks11:1500:50Audit 1PostgreSQL is a general-purpose transactional engine. Its row store, WAL, MVCC, vacuum and constraint enforcement are tuned for OLTP and that same machinery carries a cost for append-heavy telemetry, large analytical scans or datasets that live in object storage. Running everything on Postgres is possible but past a certain scale it often means adding partitioning, replicas, extensions and caching layers to fit workloads the core engine was not optimized for. Many architectures are becoming compositional: PostgreSQL as the transactional source of truth with specialized systems for specialized access patterns. Columnar engines like ClickHouse are faster at analytical aggregation, Apache Kafka is built for durable event streams and dedicated search and graph engines optimize for different execution models. Choosing the storage and compute model that fits the workload is not anti-Postgres; it is matching the tool to the access pattern. The PostgreSQL ecosystem reflects this. Extensions such as pg_search, pg_lake, pg_duckdb and pg_clickhouse embed external execution engines like Tantivy, DuckDB and ClickHouse directly into PostgreSQL workflows. These are strong engineering efforts and they point to the same reality: different workloads benefit from different execution models. ClickHouse aggregates over billions of rows faster not because it is better software but because columnar storage, late materialization and vectorized execution suit analytical work better than a row-oriented engine. In these setups PostgreSQL increasingly acts as a transactional control plane and SQL interface while specialized systems handle execution paths that differ from OLTP. This talk looks at where PostgreSQL's execution model excels, where it starts to strain operationally at scale and why compositional data architectures are emerging around PostgreSQL rather than replacing it. The goal is not to argue against PostgreSQL but to understand its boundaries, where they matter operationally and how the ecosystem is evolving around them.https://www.postgresql.eu/events/pgconfeu2026/schedule/session/8326/DBA (45 minutes)Gülçin Yıldırım JelinekPetr Jelinek11:1500:50Audit 2Back in 2021 Joel approached me with an idea: what if we could take inspiration from graph databases and allow people people to use foreign key relationships to express joins so people could do a bit less typing and at the same time avoid the risk of typos when writing the ON clause. Sounds pretty simple, right? This talk tells the story all the way from the initial idea to, five years later, the submission of a formal change proposal to the SQL standard and of a concrete patch to PostgreSQL. Along the way we had many false starts and bad ideas, Joel ended up joining the SQL committee and hosting an ISO meeting, more people joined forces to help us and the feature grew into something quite different, and in our opinion something much more useful.https://www.postgresql.eu/events/pgconfeu2026/schedule/session/8343/Postgres Internals (45 minutes)Andreas KarlssonJoel Jacobson11:1500:50SM1-BI have been working with databases for 20 years. I have seen bad schemas in every company I have ever worked for. Not because the developers were incompetent. Because nobody gave them a framework. MERISE is a French methodology developed in the 1970s for industrial database modeling. It is almost unknown outside francophone countries. That is a mistake. Where ER diagrams produce drawings, MERISE produces conversations. The Conceptual Data Model is not a deliverable: it is a tool for extracting business rules from people who have never thought about them explicitly. Cardinalities force decisions. Relationships catch contradictions. Business stakeholders sign off before a single line of SQL is written. In this talk, I will walk you through the full MERISE stack, from MCD to MLD to MPD, using real examples from production systems. I will show why it catches design errors that ER diagrams miss, how it survives contact with non-technical stakeholders, and what it looks like to apply it on a modern Postgres project. You will leave with a concrete methodology you can use on your next project, and a very good reason to be annoyed that nobody taught you this earlier.https://www.postgresql.eu/events/pgconfeu2026/schedule/session/8002/App Developer (45 minutes)Lætitia AVROT12:0501:00Otherhttps://www.postgresql.eu/events/pgconfeu2026/schedule/session/8495/Breaks13:0500:30Audit 1Where and how to host your PostgreSQL comes with a range of tradeoffs, usually cost and performance related. With cloud vendors with turn-key style services seemingly becoming default choices, but at what cost. This talk will take a look at the different tradeoffs of where and how to host your PostgreSQL database. We'll cover ways in which you can benchmark your infrastructure and how different solutions can affect performance vs cost. Looking at things like: - Ways to benchmark and understand storage and PostgreSQL performance - Local vs network attached storage and how this affects performance - Can we make network attached storage almost as fast as local storage - How availability comes into play - How replication and data safety requirements can affect things - How does performance for price compare - Tradeoffs of self hosting And trying to answer the fun question, is PostgreSQL on my Raspberry Pi faster than some common cloud offerings? If so, at what cost?https://www.postgresql.eu/events/pgconfeu2026/schedule/session/8058/DBA (25 minutes)Chris Ellis13:0500:30Audit 2Asynchronous replication always leaves a window: you commit on the primary, immediately query a replica, and your own write isn't there yet. The fix sounds trivial — let the client wait until the replica has replayed up to a given LSN before reading. WAIT FOR LSN finally ships in PostgreSQL 19, and getting it there took the better part of a decade. In this talk I'll explain why such a "simple" feature was anything but. The central obstacle is subtle: on a standby, you cannot wait while holding a snapshot. Recovery advances visibility by replaying WAL, but an open snapshot pins an old view of the database and can block that replay — so a backend waiting inside a transaction for WAL to advance can end up waiting on itself. A textbook self-deadlock, hiding inside a one-line feature. I'll walk through the design attempts this constraint killed off — implementing it as a function, folding it into an existing statement, making it a procedure — and why each ran aground on snapshot semantics, SQL grammar, or what should even happen mid-transaction. The answer the community converged on was a brand-new top-level SQL statement that holds no snapshot at all, with all the grammar and infrastructure cost that implies. Beyond the post-mortem, this is a candid story of how features actually land in PostgreSQL: the reviews, redesigns, and reverts required to push one good idea through a community that refuses to compromise on correctness. If you've ever wondered why an "obvious" feature takes ten years, here's your answer.https://www.postgresql.eu/events/pgconfeu2026/schedule/session/8063/Community (25 minutes)Alexander Korotkov13:0500:30Audit 3As PostgreSQL deployments increasingly rely on extensions for advanced capabilities, extension maintainers face the critical challenge of shipping new features without disrupting production systems. In this talk, we present a systematic framework for categorizing PostgreSQL extension changes—using Citus and other real-world examples—based on their impact on backward compatibility and user-facing behavior. We introduce a taxonomy of extension changes, ranging from non-breaking enhancements to explicitly breaking changes and subtle C‑ABI incompatibilities. Each category is mapped to appropriate versioning decisions, testing practices, and upgrade workflows. By aligning release policies with the severity of changes, an extension team can minimize risk to applications when rolling out new versions. We share practical safeguards proven in real-world production environments, including regression test suites that cover upgrades from all supported versions, mixed-version scenarios involving replicas, pre-upgrade validation scripts, and staged rollout techniques that surface issues early. Through examples, we illustrate these principles in action and highlight lessons learned. Attendees will gain actionable guidelines on designing extension upgrade processes that balance rapid innovation with the stability that users demand – all grounded in the collective experience of the PostgreSQL extension ecosystem.https://www.postgresql.eu/events/pgconfeu2026/schedule/session/7939/DBA (25 minutes)Ebru Aydin Gol13:0500:30SM1-Apg_ivm is an extension that enables Incremental View Maintenance (IVM) for PostgreSQL, updating materialized views by applying only incremental changes instead of rebuilding the entire view with REFRESH MATERIALIZED VIEW. This talk briefly introduces the architecture and maintenance mechanism used by pg_ivm and reviews recent progress in the project, including recently added support for outer joins. The talk also discusses ongoing work and future directions, including deferred maintenance approaches that could reduce update overhead while preserving the benefits of incremental view maintenance. Current limitations and remaining challenges will be examined, along with opportunities for future development.https://www.postgresql.eu/events/pgconfeu2026/schedule/session/8219/Postgres Internals (25 minutes)Yugo Nagata13:0500:30SM1-B(This talk was accepted as a 25-minute session for PGConf.dev 2026, but I was unable to present it due to a delay in my Canada visa process. I am submitting the same topic to PGConf.eu because I believe these lessons from my first year contributing to PostgreSQL remain useful for new and aspiring contributors.) PostgreSQL hacking has a steep learning curve: a large and mature codebase, long-running design discussions, and a development culture that can be difficult for newcomers to navigate. In this talk, I share my experience as a recent newcomer to PostgreSQL development. Over my first several months, I became deeply involved in patch review and development discussions across multiple PostgreSQL subsystems, participating in over 150 commits as an author or reviewer. This provides concrete context for what “ramping up fast” looked like in practice. While I came to PostgreSQL hacking with prior experience as a professional software engineer, I’ll also discuss which skills transferred well and which PostgreSQL-specific challenges required a different approach. Rather than presenting this as an achievement story, the talk focuses on the process of learning: the lessons I learned, the mistakes I made early on (both technical and communication-related), what I misunderstood at first, and the concrete workflows and tools that supported that learning. Topics include: * How I approached reading PostgreSQL code without deep prior context * How I learned to review patches before fully understanding a subsystem * Mistakes I made as a newcomer, both technical and communication-related * Tools and workflows that accelerated learning (debugging, tests, commitfests, mailing lists) * How feedback from experienced developers shaped my approach I’ll also discuss what this experience suggests for both aspiring hackers and experienced contributors, including practical ways newcomers can learn more effectively and small changes that can make the onboarding experience smoother.https://www.postgresql.eu/events/pgconfeu2026/schedule/session/7905/Community (25 minutes)Chao Li13:4500:50Audit 1We kick off with a short DEV/DBA/DBRE panel discussion to surface the most common “Postgres at scale” failures. Then the mic is open: attendees can step up for a lightning confession : A real production “obvious fix” that backfired, the metric that proved it, and what they’d do differently. Panel can chime in at the end with best practice or alternate solution. Panel: Ants Aasma , Henrietta Dombrovskaya , Jimmy Angelakos , Pavlo Golub , Teresa Lopes, Mayuresh Bagayatkar.https://www.postgresql.eu/events/pgconfeu2026/schedule/session/7876/Community (45 minutes)Ants AasmaHenrietta DombrovskayaJimmy AngelakosMayuresh Suresh BagayatkarPavlo GolubTeresa Lopes13:4500:50Audit 2There is a lot of excitement around the new REPACK command in Postgres 19, but how much of that is hype rather than something that will actually help? In this talk we will walk through a brief history of bloat management in Postgres, covering commands like CLUSTER and the evolution of VACUUM FULL, and discuss how tools like pg_repack and pg_squeeze came to be, including why we even have two different tools. But most importantly, we will review the new REPACK command (and its ever so important CONCURRENTLY option), and explain how it works, how it is meant to be used, and explore topics like ease of use, scheduling, and other items involved with operational complexity. If you have ever had to wrestle with bloat management in Postgres, this talk will help provide actionable advice for keeping production tables lean with minimal risk.https://www.postgresql.eu/events/pgconfeu2026/schedule/session/8177/DBA (45 minutes)Robert Treat13:4500:50SM1-BJust-in-Time compilation has been available in PostgreSQL since v11, and it has been compiling query expressions ever since. JIT has the capability to make long-running queries go a lot faster, but it can also make short queries take longer than they should due to the cost of compilation and optimizing. JIT is a fantastic technology with great potential, but our JIT support hasn't aged all that well and PostgreSQL 19 turns JIT of by default. In this talk we will look at what JIT is, what PostgreSQL currently support as well as what is left to do in order to turn it on by default again. We will also look at current projects which are under way to hopefully improve JIT in releases to come.https://www.postgresql.eu/events/pgconfeu2026/schedule/session/8180/Postgres Internals (45 minutes)Daniel Gustafsson14:4500:50Audit 1Managed PostgreSQL services give each customer an apparently isolated database instance, and work hard to guarantee one thing: the customer never becomes a superuser on it. This talk examines why that boundary matters and how similarly it fails across the industry. In this talk, I will discuss months of research and how I found ways to escalate privileges to superuser on nearly every managed Postgres provider. The bug differs each time, which could be a logical vulnerability in the privilege-relaxation extension, or cloud-native underlying software mistakes affecting vendors, memory corruption bugs on extensions that everybody installs and so on. What stays the same is the set of root causes behind them. Whether you are a DBA, developer building on a managed provider, or are simply curious to see from a hacker's perspective, you are welcome at this session. You will leave this talk with a knowledge of recurring root causes, a clear threat model, and a practical hardening checklist.https://www.postgresql.eu/events/pgconfeu2026/schedule/session/8137/Postgres Internals (45 minutes)Mehmet Ince14:4500:50Audit 2One Monday morning in April, pgBackRest, one of the most widely used PostgreSQL backup tools, was suddenly labelled as no longer maintained. For many users and vendors, that sounded like the beginning of the end. It wasn't. What followed exposed a challenge that extends far beyond a single project: critical open source infrastructure relied upon by numerous organizations, yet sustained by a handful of people operating with limited resources and support. In this talk, we'll revisit the events surrounding pgBackRest from two perspectives. First, we'll hear the story of pgBackRest itself: why it was created, how it grew into a cornerstone of the PostgreSQL ecosystem, and what maintaining a widely adopted open source project actually looks like from the inside. Then we'll examine what happened when news of its uncertain future spread across the industry, triggering reactions from users, vendors, and the wider PostgreSQL community. Together, we'll explore what was missing, what worked, what was misunderstood, and how the ecosystem responded. Most importantly, we'll discuss the broader lessons around maintainership, funding, succession planning, and the shared responsibilities of users and vendors who depend on open source software every day. Attendees will leave with a deeper understanding of the human side of open source infrastructure, practical lessons from the pgBackRest experience, and ideas for how the PostgreSQL ecosystem can become more resilient before the next crisis arrives.https://www.postgresql.eu/events/pgconfeu2026/schedule/session/7963/Community (45 minutes)David SteeleJan Wieremjewicz14:4500:50SM1-BDisks fail. RAM goes bad. Software bugs introduce silent corruption that spreads through a cluster before anyone notices. The question is not whether this will happen. The question is whether you have a procedure ready when it does. I have a procedure. Eight steps, in the order you actually need them during an incident. Step one: detect. Log patterns, checksum mismatches, page header anomalies, WAL inconsistencies. Step two: stop writing immediately. Every second the cluster stays up with damaged files makes recovery harder. Steps three and four are backup restoration and point-in-time recovery. I spend time on the part most people skip: how to verify that your backup is actually intact before you bet your data on it. LSN markers and timestamps give you precise control over how far to roll forward. Step five is salvage. Not every situation has a clean backup. Sometimes you need to extract individual tables with pg_dump or inspect pages at a low level to pull out what you can. Step six is pg_resetwal, which I only use as a last resort. I explain what it actually does to the WAL state and what you are agreeing to lose. Steps seven and eight are about never being here again. Checksum enforcement, scheduled integrity checks, WAL archiving discipline, and replica placement for failover. Every command in this talk runs on standard PostgreSQL. No third-party tools required.https://www.postgresql.eu/events/pgconfeu2026/schedule/session/8037/DBA (45 minutes)Ibrar Ahmed15:3500:30Otherhttps://www.postgresql.eu/events/pgconfeu2026/schedule/session/8496/Breaks16:0500:50Audit 1Until PostgreSQL 6.2 had time travel implemented in its core. It has been removed in PostgreSQL 6.3. But it can be implemented with PostgreSQL methods by adding some triggers. As that can result in big tables, when there are many updates, this can be solved with partitioned tables. In this talk I would explain what is needed and how to implement time travel into PostgreSQL again. The code to implement is shown live on stage with examples and will be available afterwards for everyone under PostgreSQL license..https://www.postgresql.eu/events/pgconfeu2026/schedule/session/8096/App Developer (45 minutes)Stefanie Janine Stölting16:0500:50Audit 2The events of last April reminded us just how important pgBackRest has become. The strong reaction from users, vendors, and sponsors showed that this backup tool is relied upon in an extraordinary range of environments — from small deployments to some of the most critical PostgreSQL infrastructures in production today. Yet many organizations use only a fraction of what pgBackRest can offer. Having a solid recovery plan is essential, because in a real outage, just having a backup is not enough. pgBackRest provides a remarkably flexible foundation that can fit many different setups: using a dedicated backup host, taking backups from standby servers, or sending data straight to the cloud with S3, Azure, or Google Cloud. However, many of these deployment patterns remain largely unknown or underutilized. In this talk, we'll go beyond the basics and look at several pgBackRest deployment patterns that can be combined for better resilience, performance, and cost efficiency. We'll discuss setups that mix backup hosts and cloud storage, make use of multiple standbys, and keep things running smoothly in High-Availability environments. Based on real-world experience deploying this "undocumented magical solution" in highly critical systems, this session will show how to unlock pgBackRest's full potential and design resilient backup architectures that meet the requirements of modern HA environments.https://www.postgresql.eu/events/pgconfeu2026/schedule/session/8238/DBA (45 minutes)Stefan Fercot16:0500:50SM1-BPost-quantum cryptography (PQC) is a set of cryptographic schemes that are assumed to be unbreakable even with the help of a quantum computer. With the advance of quantum computing, PQC is becoming more and more important for the industry and is already finding its way into NIST standards. Which in turn affects many software projects, including PostgreSQL. In this talk we will try to break through layers of hype and marketing, and discuss the current state of art in PQC and what does it mean for PostgreSQL, what still needs to be done, which versions already support PQC, to what extent and how to verify this.https://www.postgresql.eu/events/pgconfeu2026/schedule/session/8101/Postgres Internals (45 minutes)Dmitry DolgovFilip Janus17:0500:50Audit 1What's new in PostgreSQL 19? Quite a bit, and there's features for everyone who uses Postgres - app developers, DBAs, administrators, and more. In this presentation, we'll review new features in PostgreSQL 19, including new performance improvements that speedup reads from storage, better support property graph and bitemporal, and jsonpath queries, more OAuth capabilities, new monitoring data, and much more. We'll explore how these new capabilities build on previous PostgreSQL features, helping you understand how they fit into your daily usage.https://www.postgresql.eu/events/pgconfeu2026/schedule/session/8111/App Developer (45 minutes)Jonathan S. Katz17:0500:50Audit 2The PostgreSQL event landscape has never been richer, ranging from small local meetups with just a handful of participants to large international conferences with hundreds of attendees from across the globe. While human connection can form in different settings, PostgreSQL events serve as a pressure cooker for the project's technical evolution, community growth, and individual development. Large conferences, in particular, bring together a diverse mix of people: attendees, companies, organisers and volunteers, sponsors, and speakers, each with their own interests and goals. In this talk, marking 30 years of the project, I'll zoom in on PostgreSQL events: why people attend, why companies sponsor, and why being a speaker matters. I'll explore what makes community conference organising teams work, what motivates organisers to keep "getting together for the gig," and where they struggle. Along the way, we'll look at how the connections and collaborations that emerge from events ripple outward, shaping features, careers, and companies alike. I'll take you on a visual journey through 30 years of PostgreSQL history and community milestones, showing how the collaborations and interactions that emerge from PostgreSQL events shape the project's development in ways that the mailing list alone never could. Here's to 30 more years of changing the course of open source, and to PostgreSQL events that are fun, welcoming, and full of meaningful connections that last a lifetime!https://www.postgresql.eu/events/pgconfeu2026/schedule/session/8066/Community (45 minutes)Valeria Kaplan17:0500:50Audit 3Imagine the following, common scenario: Your database is configured for the needs of your day-to-day (OLTP) application activity; many concurrent user connections each performing multiple short select, insert and update statements. This OLTP activity constantly generates data, which has built up in your database over time, and is now seen as a valuable business resource. The organisation wants to use this data to answer real-world business questions such as “what percentage increase in sales did we see as a result of this marketing campaign?”. This means you need to run analytics queries (OLAP activity) against the data; complex queries that work on large data sets and are therefore very resource intensive. How can you do that without compromising the performance of your application? Let’s look at some of the ways that you can design your environment and tune your database to work with this hybrid (OLTP + OLAP) workload. The goal is to make sure you've got performant analytics queries that have minimal impact on your day-to-day database activity.https://www.postgresql.eu/events/pgconfeu2026/schedule/session/8153/DBA (45 minutes)Karen Jex17:0500:50SM1-AAt Toggl, we run a multi-tenant analytics pipeline on top of vanilla PostgreSQL, sourcing data via logical replication from OLTP and molding it to meet analytic use cases with a Golang ETL fleet. For years, we leaned on a single, generously sized Postgres cluster with PARTITION BY HASH (workspace_id) and trigger-driven transformations inside the ingest transaction. It worked, but it came with issues - the biggest one was reliance on sequential data processing. By coupling ingestion and transformation, we made one noisy tenant everybody's problem. To overcome that, we chose application-level sharding over Citus, FDW, or vertical scaling. This talk is about war stories and how we came to like our sharding solution after realizing that splitting the ETL pipeline into independent stages improved resilience, but on its own would have pushed us off near-real-time processing unless we threw a humongous amount of resources at the cluster. It's also a story about lean engineering: at every painful turn, the tempting move - and the one most engineering teams reach for - is to defer the problem to an established OLAP solution. We didn't, and this is what we learned by staying on vanilla Postgres.https://www.postgresql.eu/events/pgconfeu2026/schedule/session/8016/App Developer (45 minutes)José Neves17:0500:50SM1-BTelangana's MeeSeva platform delivers over 500 government services to 40 million citizens across India's sixth-largest state. This April '26, we migrated the entire stack from Oracle to PostgreSQL, not as a pilot, not in parallel, but as a full production cutover for a system handling 100K transactions per day. This talk is a practitioner's account of how that migration happened, what broke, and what we'd do differently. I'll cover: - How we assessed Oracle-specific dependencies (PL/SQL packages, materialized views, proprietary datatypes) and scoped the migration - What Ora2Pg handled automatically, what required manual rewriting, and where its limitations forced architectural decisions; the performance tuning we did post-migration, query plan differences, index strategy changes, and connection pooling adjustments for PostgreSQL - How we managed the cutover for a 24/7 citizen-facing service with zero tolerance for downtime; and the measurable outcomes: licensing cost reduction, operational changes, and where PostgreSQL exceeded or fell short of Oracle. The talk is tool-agnostic and vendor-neutral. Whether you're migrating a government platform, a financial system, or an enterprise ERP, the patterns, dependency analysis, automated-vs-manual conversion ratios, performance regression testing, cutover planning, are the same. I'll share the decision frameworks, not just the results.https://www.postgresql.eu/events/pgconfeu2026/schedule/session/7957/DBA (45 minutes)Hari Kiran08:3000:30Otherhttps://www.postgresql.eu/events/pgconfeu2026/schedule/session/8509/Breaks09:0000:15Audit 1Welcome back to the second day of PostgreSQL Conference Europe 2026!https://www.postgresql.eu/events/pgconfeu2026/schedule/session/8503/PGConf.EU09:2500:50Audit 1AI agents are told to be the next revolution, and of course they will need data. But instead of building another boring chatbot, let's create a Dungeon Master for our next Dungeons & Dragons campaign! Using this practical and fun example, we will build an AI agent that runs entirely on PostgreSQL. We'll go beyond simple query generation to explore how to grant agents secure, contextual access to your database for complex, non-predictive tasks. You'll learn how to architect an MCP (Model Context Protocol) server to prevent rogue AIs from dropping your tables while still empowering them to act as creative partners. Join this quest to save the realm of elephants and learn to forge the weapons you'll need for the coming run.https://www.postgresql.eu/events/pgconfeu2026/schedule/session/7982/App Developer (45 minutes)Matt Cornillon09:2500:50Audit 2Vacuum gets a bad reputation and other RDBMS vendors are quick to point it out as a PostgreSQL flaw - and yet PostgreSQL keeps getting more and more popular, year after year. Vacuum is a design decision, not an accident - Fast writes now, clean up later. The problem is not vacuum. The problem is misconfiguration. But how do you know if your autovacuum config is wrong? And what does "wrong" even look like? In this talk we take the same workload and change the parameters - and you see exactly what happens. Dead tuples, bloat, table size, vacuum frequency, all measured, all explained. It will also cover what to do when bloat is already there! More and more developers are managing their own databases - especially on managed services - without a dedicated DBA, so getting this right is no longer just a DBA concern.https://www.postgresql.eu/events/pgconfeu2026/schedule/session/8120/DBA (45 minutes)Teresa Lopes09:2500:50Audit 3How do backend processes communicate with each other in a PostgreSQL server? We have built many different mechanisms over the years, ranging from Unix signals and semaphores to co-operative signal handling through "interrupts" and homegrown condition variables. Some mechanisms are redundant and exist for historical reasons, some to serve some special needs. In this presentation, I will cover the most important mechanisms in detail, and present a new "interrupts" mechanisms that I have been working on, which has hopefully been committed for v20 by the time of the conference.https://www.postgresql.eu/events/pgconfeu2026/schedule/session/8146/Postgres Internals (45 minutes)Heikki Linnakangas09:2500:50SM1-APostgreSQL 19 ships a focused set of monitoring improvements that, taken together, close several long-standing observability gaps. This talk walks through the changes that matter most for DBAs, platform engineers and tooling authors. On the logging side, `log_lock_waits` is now enabled by default, making lock contention visible out of the box without manual configuration. `log_min_messages` now accepts a comma-separated list of type:level pairs, letting operators set different log verbosity per process type. Autoanalyze logging is also split from autovacuum with the new `log_autoanalyze_min_duration` setting, giving independent control over two very different maintenance operations. For WAL and I/O observability, VACUUM and ANALYZE logging now report WAL full page write bytes, surfacing the true I/O cost of maintenance workloads. New wait events cover WAL write and flush LSNs, while new I/O wait events for COPY operations on pipes, files and programs fill coverage gaps that previously made it difficult to attribute I/O time to specific operations. Messages from remote servers (replication, postgres_fdw, and dblink) now appear in the server log in the same format as local messages, making log correlation across distributed setups significantly easier. Finally, the new `pg_get_multixact_stats()` function exposes multixact activity that was previously opaque and the XID wraparound warning threshold has been raised from 40 million to 100 million transactions, giving operators more lead time to react. The talk will close with a look at what these changes mean for existing observability tooling and where gaps remain heading into PostgreSQL 20.https://www.postgresql.eu/events/pgconfeu2026/schedule/session/8182/DBA (45 minutes)Gülçin Yıldırım Jelinek09:2500:50SM1-BWhile some people shun database functions as something that is hard to develop, test and debug I will show that the opposite is true - having a clearly designed API between your application and database not only makes all the above easier but also allows infinite scalability with full developer control and very clean and easy to understand model. I will also show that testing database functions is 1:1 similar to testing microservices and should be approached exactly the same way. And some testing is just not needed, as PostgreSQL itself can enforce many business rules by just defining them as constraints. And I will also talk about one of the great things that came out of Skype's PostgreSQL team - `pl/proxy `- providing virtually unlimited scalability with no SPOFs The original version of `pl/proxy` was invented and implemented at Skype about 20+ years ago. A little over two years later full rewrite - and splitting out `pgbouncer `- was published as `pl/proxy` version 2.0 on github. ## The original target The original, and successful, target was to give PostgreSQL a tool that allows functions infinite scalability via sharding inside the function. This enabled an architecture with no scaling limits and no SPoF A short intro to Sharding with `pl/proxy` is presented. ## What else came out of this As with many simple but novel tools several other, sometimes unexpected, use cases emerged The ones I'll cover, in no particular order of "importance" are * A PostgreSQL-native "microservices architecture" * Using `pl/proxy` and a data-less PostgreSQL proxy instance to expose functionality to CloudSQL that is otherways not available in a managed database, like reading any file system, sending emails or using languages like `pl/R` or `pl/python` . * Easy and Intuitive way to do map/reduce style data analyses on both multi-core servers and sharded clusters of databases. * Autonomous Transactions * Sharding `BY REFERENCE` - it is easy to write apps where all related data is on the same database node even when the identifying column is not in the table. * Roll-your-own parallel queries and DML - while PostgreSQL's parallel query capabilities have improved a lot over last 20 years there are still a lot of cases where it does not do what you want. Especially only the driver process can write data. * Write "on streaming read-only replica" - RO replicas are by definition read-only. I'll show how you can write a function which a) extracts connect string to master and b) calls a function on aster to write data (which is then immediately replicated back.) * Writing progress or debug info from a parallelized query. * Running complex in-database jobs * Security-at-depth via having only functions on the host the user connects to. * the above also helps when one wants to avoid internal structure of tables and source code of functions from ordinary users * collecting monitoring info in database at high frequency - up to 2kHz is possible for some metrics.https://www.postgresql.eu/events/pgconfeu2026/schedule/session/8283/App Developer (45 minutes)Hannu Krosing10:1500:30Otherhttps://www.postgresql.eu/events/pgconfeu2026/schedule/session/8493/Breaks10:4500:50Audit 1Have you ever struggled to figure out how something in Postgres works, or why it is the way it is? Maybe you found a few relevant references in the documentation; more likely you spent some time experimenting and asking questions until your understanding was complete and your curiosity was satisfied. Now what? How about contributing that understanding to the PostgreSQL documentation? Help those who come after enjoy a clearer path to insight, without the need to trudge the same journey as you. Sound daunting? It's not so bad, I promise! Drawing on my experience documenting the differing behaviors of the two modes of jsonpath behavior, this talk will look at: * How the PostgreSQL project maintains its documentation * How to figure out what bits correspond to what appears on the web site * The tools and practices you need to successfully improve the docs * The path to getting your docs merged and released Come with curiosity and a basic comfort with a text editor and the command-line. Leave with the goal to become an official contributor to the project.https://www.postgresql.eu/events/pgconfeu2026/schedule/session/7973/Community (45 minutes)David E. Wheeler10:4500:50Audit 2Columnar and vectorized query engines routinely outperform PostgreSQL by 10-100x on analytical workloads. Three things account for most of that gap. First, they amortize per-tuple overhead by moving data in batches rather than one row at a time. PostgreSQL's executor re-enters the storage AM, dispatches expression opcodes, and calls through fmgr for every single tuple. A batch of 1024 tuples turns all of that per-row work into per-batch work. Second, they operate on packed, typed arrays instead of Datum. A column of int32 values in PostgreSQL is an array of 8-byte Datums with per-row bool null flags. In a vectorized engine it's a contiguous int32_t array with a bitmask for nulls. The native type width and contiguous layout let the compiler emit SIMD instructions. The Datum representation structurally prevents this. Third, they exploit knowing about multiple rows at once. A hash join probe that sees one row at a time stalls on memory latency for every lookup. A probe that sees 1024 rows can issue prefetches for all of them and overlap the latency. Two-phase column fetch can deform only qual-relevant columns for a batch, filter, and skip the rest for non-survivors. None of this is possible when the executor sees one tuple at a time. This talk presents a design for closing that gap incrementally from inside PostgreSQL -- starting with batch delivery from the table AM through the slot interface, adding a typed columnar intermediate representation, and building toward batch-aware expression evaluation with type-specific opcodes. Each layer is independently useful and leaves the row path intact. Audience: Core and extension developers working on executor internals, storage access methods, or analytical performance in PostgreSQL.https://www.postgresql.eu/events/pgconfeu2026/schedule/session/7997/Postgres Internals (45 minutes)Amit Langote10:4500:50SM1-BLet’s be honest: nobody actually likes a midnight maintenance window. Taking an application offline to reclaim disk space, holding your breath during a sequence cutover on a logical migration, or dealing with flaky schema parsing scripts introduces massive operational stress. For years, the community has relied on complex external workarounds or third-party extensions to bypass these core limitations. With PostgreSQL 19, the engine is growing up. It is absorbing these operational headaches and turning them into native, first-class, non-blocking primitives. This talk is a practical, battle-tested operational guide for DBAs, SREs, and engineering leads who need to maintain continuous database uptime. Through quick, side-by-side structural demos, we will look at the painful "Before" vs. the native "After," diving straight into three core pillars of the Postgres 19 ecosystem: 1- Native, Non-Blocking Space Reclamation: We’ll contrast the old way of relying on external extensions like pg_repack against the new in-core REPACK CONCURRENTLY mechanism. You’ll see how the core engine natively handles logical decoding boundaries to clean up tables on high-traffic primaries without blowing out write latency or replication slot lag. 2- Flawless Logical Failovers: Sequence drift is a historic headache during logical migrations, usually requiring custom, error-prone sync scripts. We will look at how the new logical sequence synchronization workers (REFRESH SEQUENCES) handle this natively to guarantee a clean, conflict-free cutover before you promote a subscriber. 3- Decoupled Schema Automation: We’ll show how to replace the brittle text-parsing of old pg_dump outputs with stable, native DDL extraction catalog functions like pg_get_database_ddl to seamlessly automate schema verification pipelines inside your CI/CD engine. Key Takeaways for Attendees: - Master Live Table Rebuilds: Implement native REPACK CONCURRENTLY safely, understanding how to monitor WAL production and manage replication slots under heavy write workloads. - Eliminate Sequence Drift: Step-by-step configuration of sequence synchronization workers to ensure flawless, zero-data-loss logical migration cutovers. - Automate Schema Pipelines: Leverage new in-core catalog contracts to pull database, role, and tablespace DDL directly into automated infrastructure-as-code workflows.https://www.postgresql.eu/events/pgconfeu2026/schedule/session/8067/DBA (45 minutes)Rajni Baliyan11:4500:50Audit 1Why isn’t wait-event observability as ubiquitous in the Postgres world as it is in other database ecosystems? While wait events provide the definitive "ground truth" for database bottlenecks, capturing them at scale remains notoriously difficult due to sampling data gaps. In this presentation, we will bridge the gap between high-level database metrics and low-level engine contention. We will start by establishing exactly why wait events are the most powerful diagnostic tool in a DBA's arsenal. By breaking down query latency into specific wait states (such as disk I/O, LWLock contention, or network delays), wait-event analysis shifts troubleshooting from guessing based on vague system symptoms to pinpointing the exact resource constraint holding up your database. Armed with this understanding, we will explore the mechanics of the Postgres wait event subsystem and existing tools and demonstrate how these states can decisively isolate critical production incidents—such as WAL write bottlenecks and LWLock lock storms—where traditional metrics fall flat. Moving beyond theory, we will evaluate the architectural limitations of existing observability tooling. To address these gaps, the session will introduce a brand-new open-source tool designed for lightweight, wait events tracing capture, alongside practical usage patterns. Finally, we will dive into a custom Postgres patch aimed at introducing native wait-event tracing directly into the Postgres core, paving the way for low-overhead, event-driven diagnostic pipelines.https://www.postgresql.eu/events/pgconfeu2026/schedule/session/7907/Postgres Internals (45 minutes)Dmitry Fomin11:4500:50Audit 2Migrating from Oracle to PostgreSQL seems straightforward on paper - after all, they’re both relational databases, right? This journey reveals unexpected challenges that go far beyond simple syntax changes. This talk shares hard-won lessons from product migrations at Lufthansa Group Business Services, covering some easy wins as well as painful gotchas that can impact performance, correctness, and your sanity. We’ll explore technical nuances that cause real-world problems: Differences in NULL handling and why IS DISTINCT FROM is a distinctly bad idea for your query performance. Numeric types, rounding behaviors, and how to enforce the desired precision. How PostgreSQL’s MVCC architecture fundamentally changes your update strategy - when updating 80 million records in a single query brings your system to its knees. You’ll leave with practical strategies, performance insights, and a realistic understanding of what it takes to successfully migrate from Oracle to PostgreSQL.https://www.postgresql.eu/events/pgconfeu2026/schedule/session/7944/App Developer (45 minutes)Joshua SteinmannTino Engelbrecht11:4500:50SM1-BWriting a PostgreSQL performance patch requires more than identifying an optimization and implementing it. To propose the change effectively, you need a clear performance reproducer, meaningful measurements, and an understanding of the conditions where the patch helps, has little effect, or introduces tradeoffs. This talk will cover a few practical techniques for designing benchmarks for PostgreSQL performance patches. We will look at how to turn an observed inefficiency, either from reading the code or from a real workload, into a minimal reproducer suitable for discussion on pgsql-hackers. We will discuss how to identify best-case and worst-case scenarios and how to scale a benchmark down without accidentally moving the bottleneck somewhere else. The talk will also cover cases where the system must be in a particular state before the performance effect appears: for example, when checkpoint timing, page visibility state, or concurrent activity matter. We will discuss practical techniques such as tuning checkpoint behavior, using or disabling WAL compression, configuring OS settings, and shaping the workload so that the benchmark exercises the intended part of PostgreSQL. The goal is to construct performance test cases that are small enough to share, realistic enough to be meaningful, and precise enough to help reviewers evaluate a proposed PostgreSQL patch.https://www.postgresql.eu/events/pgconfeu2026/schedule/session/8341/Postgres Internals (45 minutes)Melanie Plageman12:3501:00Otherhttps://www.postgresql.eu/events/pgconfeu2026/schedule/session/8497/Breaks13:3500:50Audit 1Everybody knows about row locks, right? They prevent conflicts between data modifications, and you take them with `UPDATE`, `DELETE` and `SELECT ... FOR UPDATE`. This talk shows that there is much more to know about row locks: - What lock levels are there and what is their purpose? - How does PostgreSQL use row locks to maintain foreign key consistency? - How are row locks stored and how are they taken? - How can you inspect row locks? - How do row locks look in `pg_locks`? - What the heck is a "MultiXact", and what is the connection with row locks? If you administrate or develop a highly transactional PostgreSQL database, you should know about these things.https://www.postgresql.eu/events/pgconfeu2026/schedule/session/7938/Postgres Internals (45 minutes)Laurenz Albe13:3500:50Audit 2When designing a new database we pay a lot of attention to the database forefront: roles and grants, password protection, SSL/TLS, defence against SQL injection etc. But when it comes to database backups, most of the time the importance is given to taking backups, their restorability and the time it takes to backup and restore. But backups if not secured can be as vulnerable as an unprotected live database. Imagine a malicious user getting his hand on an unsecured backup storage and extracting all the confidential data! Or an intern with access deleting all the backups and then the database by mistake(or they were feeling adventurous). Hence it is important to implement security strategies for Database backups too. My talk will be about different possibilities for backup security in Postgres world. We will talk about some practical concepts and how to implement them. Attendees will leave the talk with an understanding of various strategies that they can implement in their environment to harden their database backup infrastructure and avoid some major Gotchas!https://www.postgresql.eu/events/pgconfeu2026/schedule/session/7930/DBA (45 minutes)Priyanka Chatterjee13:3500:50Audit 3Modern application development has changed how databases are designed and used. Teams move faster, systems grow more complex, and database decisions are increasingly made by developers without dedicated database specialists. In this environment, performance issues often emerge not from scale itself, but from common design choices that don’t behave well under real workloads. This presentation explores database performance anti-patterns - recurring query and schema design decisions that consistently lead to inefficiencies in production systems. Using PostgreSQL as the primary example, the talk examines how these patterns affect I/O, memory usage, indexing, query planning, and partitioning behavior. Topics include data access patterns such as SELECT *, query constructs that prevent index usage, pitfalls of NOT IN, schema-level choices such as storing timestamps as strings or numbers, using 4-byte integers for auto-generated primary keys, and defining all columns as nullable - decisions that often seem harmless but create long-term performance and maintenance costs. While the examples focus on PostgreSQL, the concepts apply broadly to relational databases. The goal is to help developers better understand how design decisions impact database performance and avoid patterns that have repeatedly caused problems for users.https://www.postgresql.eu/events/pgconfeu2026/schedule/session/8255/App Developer (45 minutes)Evgenia Yertsenkin13:3500:50SM1-AThe PostgreSQL project is mature; it is the leading enterprise data management platform of choice for many very large companies. Yet, PostgreSQL, with all its benefits, is substantially less well-known than we think and perhaps hope. Do we care, or should we care? This presentation reviews a decade of high-end enterprise sales with PostgreSQL, and shares some of the insights from discussions and debates with potential PostgreSQL users. Lessons range from the technical side of the spectrum to the absolute abstract approach. How PostgreSQL lives in golf-course conversations and how it could and should be well known in continental political scenes. And it highlights where we are failing PostgreSQL!https://www.postgresql.eu/events/pgconfeu2026/schedule/session/7887/Community (45 minutes)Jan Karremans13:3500:50SM1-BIf you ever wanted to find out what can be configured in postgresql.conf, you can easily find it in the official Postgres documentation. So, all you need to do is read it, yes, all of it, and you will have a perfectly configured database. Sounds easy, right? The reality, however, tends to differ from the laboratory conditions that documentation describes, in addition, there is never enough time to go through the documentation, especially, considering that not every parameter would make sense for your database. There are also settled differences that one should be aware of and the new releases that require constant adaptation of your config settings. In this talk, I will take you through all the settings that, in my experience, as a consultant working with a variety of databases, should be adjusted. I will look into reasoning for it, and review the chain reaction that each change in each of these settings, will trigger. We will review some typical workloads and I will also be sharing some recommended configurations which our DBAs follow when setting up for our clients and which have been proven over and over with different databases and under variety of our client’s requirements. Following this talk you will have the knowledge required to understand major postgresql.conf parameters, know what role they play in the overall database performance and will be able to set up your own version that will work for your database. If you are a DBA who is just starting to work with Postgres and would like to make sure that you have a reliable base to build your work on, this talk is for you.https://www.postgresql.eu/events/pgconfeu2026/schedule/session/8261/DBA (45 minutes)Ilya Kosmodemiansky14:3500:50Audit 1How much memory does a Postgres server actually request? Why do Postgres and Linux allocation metrics sometimes disagree by multiple gigabytes? And what happens when the OS encounters a memory request it simply cannot fulfill? We didn't ask those questions out of mere curiosity. For several years, the platform team at Tigerdata successfully relied on a custom library to shield thousands of Postgres services from the Linux Out-Of-Memory (OOM) killer in an environment where memory overcommit is an unavoidable reality. However, as workloads scaled and memory requirements grew, we noticed an uptick in allocations that were bypassing the library limit and leading to OOMs. We found ourselves facing a question: why were the OOM conditions bypassing our safeguards and what could we do about it? This talk details our deep dive into the intersection of Linux and PostgreSQL memory management that resulted in a sharp decrease in the number of OOM events. We will explore: * The Root Cause of OOMs: How overcommit works and how to prevent the kernel from sending SIGKILL to Postgres processes in a modern cgroup-based environment. * Postgres Memory Architecture: A breakdown of the Postgres memory model and the parameters, both per backend and at the server level, that affect how much memory Postgres uses. * Our journey into finding unaccounted allocations: How we used modern tools like eBPF to analyze OOM kill statistics and identify both 'extra' memory and unexpected malloc behavior. The Solution: What we did to establish a reliable cap on the memory usage, relying on Patroni hooks and Postgres extensions to put everything in place. Beyond the story, attendees will walk away with strategies to minimize Postgres memory overhead, insights into glibc malloc and its alternatives, and a suite of Linux tools for analyzing per-process and system-wide memory usage.https://www.postgresql.eu/events/pgconfeu2026/schedule/session/8246/DBA (45 minutes)Dimitris SiderisOleksii Kliukin14:3500:50Audit 2Is PostgreSQL good enough to satisfy all your graph database needs? Relational databases store data in tables, graph databases store data in nodes and edges. Or so is the common wisdom. But look one layer deeper and both store data as blocks on a disk. And in the world of databases, storage layout is what determines performance. In this talk I will explore options for mapping graphs onto a relational database. What are the upsides and downsides of each one and how to write common graph queries. We will also see how SQL/PGQ coming in PostgreSQL 19 makes things easier and what the future additions will improve.https://www.postgresql.eu/events/pgconfeu2026/schedule/session/8169/App Developer (45 minutes)Ants Aasma14:3500:50SM1-BPostgres databases are usually the source of truth of other data stores and tools: search indexes, downstream replicas, webhooks, analytics warehouses. Most teams get there by putting together triggers, cron jobs, dual writes, Debezium, and scripts. Each with its own failure mode, its own operational burden, and its own way of drifting from the source of truth. Using pgstream, an open-source Go CLI tool and library that uses Postgres logical replication to stream schema and data changes, we will walk through each target: - Postgres: an `ALTER TABLE` on the source appears on the target seconds later. A dive into DDL replication and TOAST + REPLICA IDENTITY discussion. - OpenSearch: a row insert lands as a search hit. We look into challenges of type mapping, out-of-order events versus LSN as a document version, and the cost of renames in an immutable mapping. - Kafka: a row insert becomes a topic message. A glimpse into partitioning, ordering versus throughput, and a side-by-side comparison with Debezium. - Webhooks: a row insert fires an HTTP POST. This is the entry point for idempotency, retry, and the discussion of database triggers. Each demo is short and self-contained. Then we go through the relevant Postgres mechanics. We'll close with a comparison with Debezium and native logical replication. Attendees will leave with a mental model of CDC fan-out as a set of Postgres primitives; a list of the gotchas (TOAST, identity, ordering, DDL, slot lag); and operational knowledge to decide whether a lightweight approach fits their stack or not.https://www.postgresql.eu/events/pgconfeu2026/schedule/session/8159/Postgres Internals (45 minutes)Noémi Ványi15:3500:50Audit 1The Cyber ​​Resilience Act is an EU regulation that came into force in 2024 and will take full effect in the coming years. It obligates software manufacturers to implement specific measures to ensure the security and quality of the software they produce. These measures include, for example, clearly defined procedures for providing security updates. Special rules apply to open-source software and to companies that sponsor open-source projects. PostgreSQL in enterprise use will almost certainly fall under these rules. Due to the unique structure of the PostgreSQL community, with its loose organization, numerous participating companies, and stakeholders worldwide, determining which rules apply to whom is a challenge. In this presentation, I would like to begin to explore what this law means for the PostgreSQL project and its community, which measures the various parties should take, and how this can improve the security and quality of the software.https://www.postgresql.eu/events/pgconfeu2026/schedule/session/7970/Community (45 minutes)Peter Eisentraut15:3500:50Audit 2PostgreSQL has traditionally offered cluster-wide or database-wide statistics. But when you have hundreds of connections and something goes sideways due to excessive I/O, WAL generation, or lock contention, the question is always: which backend? Answering that has meant polling pg_stat_activity, parsing logs, or guesswork. The new per-backend statistics infrastructure changes that. Per-backend I/O and WAL statistics are already committed, with transaction counters, relation access patterns, and lock statistics proposed. Together, they give you direct, real-time visibility into what each connection is actually doing. We'll cover what's landed, what's coming, and the design behind it. Then in a live demo, we'll run a mixed workload and identify the misbehaving backend on the spot — no log grep, no polling loops, just direct observation.https://www.postgresql.eu/events/pgconfeu2026/schedule/session/7989/Postgres Internals (45 minutes)Bertrand Drouvot15:3500:50SM1-AThe query runs in 4ms in dev. In production it takes 12 seconds. The usual response is more CPU, more memory, a larger instance. The bill goes up, but the query is still doing the same wrong thing. The problem is not your code and it is not your indexes. The development database is lying to the planner. PostgreSQL does not look at your data when it plans a query. It looks at statistics about your data: row counts, value distributions, most common values, and the correlation between column values and physical storage order. These live in pg_statistic and pg_class. In dev, those numbers describe a table with 10,000 rows. In production, the same table has 50 million, and that distribution changes which indexes the planner will touch. Most developers know data volume matters. Almost none have looked at what pg_statistic actually contains or how directly it controls plan shape. Those statistics are just data. They can be serialized to a file, moved to another machine, and injected into a local PostgreSQL instance using pg_restore_relation_stats(), shipped in PostgreSQL 18. The local planner then makes the same decisions the production planner would make. No production access. No copy of the data. Just the statistics. pg_statistic has columns most developers have never opened. Each one is a direct input to the planner's cost model. A production snapshot goes into a local database and the plan changes: the query that took 4ms starts sequential-scanning 8 million rows, exactly as it does in production. Fix the query, verify the plan locally, ship something that actually works on the other database too.https://www.postgresql.eu/events/pgconfeu2026/schedule/session/8025/DBA (45 minutes)Radim Marek15:3500:50SM1-BAfter more than 25 years helping customers and partners build and troubleshoot SQL Server applications, both on-premises and in the cloud, I began working with PostgreSQL and quickly discovered that some of the things I assumed were “obvious” were not universal after all. Not the fundamentals: an 8 TB database with roughly 80% unused indexes, or a supposedly “slow” web page firing off 63 separate database queries—those problems still exist 😊. But the defaults, the tools, and especially the failure modes are different enough to create trouble if you are not paying attention. This talk comes out of those moments. We’ll walk through a few patterns I’ve encountered—and sometimes introduced myself—including chatty applications, accidental N+1 queries, parameterization surprises, pagination that breaks down at scale, and schema changes that seemed safe until they were not. For each one, we’ll look at how it appears in PostgreSQL, why it behaves that way, and how to fix it, often contrasting it with the approaches I used on SQL Server. We’ll also look at cases where the platforms are just different. For example, without built-in resource governance, one bad query can suddenly slow everything else down—and now the fix is no longer in the database, but in how your application behaves. This is not about comparing databases. It is about building a mental model you can carry with you. You’ll leave with practical ways to read execution plans, think about indexes, and troubleshoot performance issues without instinctively blaming the database.https://www.postgresql.eu/events/pgconfeu2026/schedule/session/8017/App Developer (45 minutes)Silvano Coriani16:2500:30Otherhttps://www.postgresql.eu/events/pgconfeu2026/schedule/session/8498/Breaks16:5501:15Audit 1https://www.postgresql.eu/events/pgconfeu2026/schedule/session/8505/PGConf.EU08:3000:30Otherhttps://www.postgresql.eu/events/pgconfeu2026/schedule/session/8510/Breaks09:0000:15Audit 1https://www.postgresql.eu/events/pgconfeu2026/schedule/session/8504/PGConf.EU09:2500:50Audit 1By this time of the year PostgreSQL 19 was probably already released and the new features and improvements are set. As there is no better way of learning, we'll go through the new features with plenty of demos, live. All the demos will be in the slides for you to re-play and it is guaranteed that the slides will be uploaded after the talk. By the end of this talk you'll have a clear overview of what's new, what got improved and also what is incompatible with previous releases.https://www.postgresql.eu/events/pgconfeu2026/schedule/session/7904/DBA (45 minutes)Daniel Westermann09:2500:50Audit 2PostgreSQL development relies heavily on traditional mailing lists, but managing the "firehose" of daily emails can overwhelm both new and veteran contributors. Hackorum solves this by providing a modern, forum-style interface that respects existing email culture while dramatically improving the user experience. Initially focused on core development with real-time "pg-hackers" threads and Commitfest tracking, Hackorum is rapidly evolving. We are expanding our reach to support more mailing lists and enable direct mail sending from the UI. Furthermore, fresh off discussions at pgconf.dev in Vancouver, we are tackling big new ideas, such as integrated bug tracking and advanced topic grouping. We've also been discussing new ideas for Bug tracking or topic grouping in Vancouver at pgconf.dev, which I would like to present our progress on. Join us for a demo of our latest updates, including per-message read tracking, shared notes, and advanced synchronization, and discover how we are making the entire Postgres ecosystem more accessible and usable for everyone.https://www.postgresql.eu/events/pgconfeu2026/schedule/session/8197/Community (45 minutes)Jack BonatakisKai09:2500:50Audit 3PostgreSQL does not have any prescribed guidelines for the use of schemas, also called namespaces. A namespace is just one of many attributes of an object, whether an object is a table, a view, a function, or any other object type available in PostgreSQL. However, one of the common reasons for using schemas is to simplify the access control management. The idea is straightforward: all objects within one schema should have identical access privileges, isolating projects or applications from one another. As simple as it sounds, the practical implementation of this approach can quickly turn into an operational nightmare. The problem many PostgreSQL users face is that there is currently no simple way to ensure that all objects created in a schema have identical ownership and permissions. Even when we define default schema privileges, they apply only to the specific user(s) creating objects. Since any role, including the schema owner role, can be granted to multiple users, there is no easy way to ensure that default permissions will work for all of them. Nowadays, rapid development demands a smooth feature rollout, while keeping sensitive data secure is more important than ever. Faced with an unexpected “permission denied” error during the production rollout, teams rush to grant excessive permissions, which can be difficult to revoke later when no one can untangle the cascading grants. Observing situations like that happening again and again, we thought about ways to make permissions management a little simpler and, more importantly, to autocorrect inevitable user errors. The pg_acm tool, which we introduce in this talk, addresses these problems using a set of security-definer functions and event triggers. When you use pg_acm, all you need to do is define an access management policy for your database. Once it is defined, the CREATE SCHEMA command creates a set of event triggers and roles. All of them, working together, will ensure your access policy enforcement. We hope that someday we will see an option to create “schemas with permissions” as part of the PostgreSQL core.https://www.postgresql.eu/events/pgconfeu2026/schedule/session/7956/App Developer (45 minutes)Henrietta Dombrovskaya09:2500:50SM1-APostgreSQL added single-node parallel query execution in a series of leaps and bounds a few years ago, but it is far from finished. This talk is a reflection on design choices made, path dependencies that influenced those choices, where they sit in the design space, and a selection of major opportunities that remain open for future development. * How does PostgreSQL plan and execute queries that use multiple CPUs? * Missing, incomplete, sub-optimal and unorthodox features * How do other systems do it, and what can we learn from them? Topics touched on include planning strategies, resource management, write queries, efficiency and overall architecture.https://www.postgresql.eu/events/pgconfeu2026/schedule/session/8190/Postgres Internals (45 minutes)Thomas Munro10:2500:30Audit 1PostgreSQL diagnostic tooling today asks you to compromise. Either you install an invasive agent on the database server before the incident: Datadog, Prometheus exporters, telegraf, monitoring sidecars, vendor agents, take your pick. Each comes with its own attack surface, dependencies, and update schedule. Or you can point pgBadger at your Postgres log after the fact, but logs only describe what your queries did, not deep server info: configuration, HBA rules, replication topology, Postgres statistics, the kernel and I/O configuration underneath. *radar* is the missing piece. An agentless, zero-dependency Go binary that captures a comprehensive PostgreSQL + system snapshot in seconds: host facts, settings, HBA, roles, replication, WAL state, per-database tables / indexes / sequences / extensions, `pg_stat_statements` when loaded, and dozens of catalog and `/proc` files. It captures metadata only: no row data, ever. There's no scheduled job or resident daemon, no Python or systemd dependency. It's safe to drop on any production box, and every collector is skippable on demand. Output is a zip file the operator can forward to any support team. *radar-ui* can be the analyst on the receiving end. A service that parses every entry into typed records and runs deterministic rules across five categories (Host & OS, PostgreSQL Configuration, Workload, Internals & I/O Health, Replication) plus per-database analysis. Every finding pairs a fact with a fix: "198 recent WAL archive failures", "oc_filecache has 56% dead rows". An LLM (OpenAI compatible, Claude, Gemini, or local Ollama) optionally synthesises each category into the kind of summary a senior DBA would write: invaluable for time-pressed operators. The talk covers: - The collector. What radar captures, what it deliberately doesn't, and how the agentless / zero-dependency posture can serve Linux, macOS, bare-metal, VMs, and containers. - The rule pack. A walk through what radar-ui catches in real production snapshots, such as WAL archiver failures, idle-in-transaction blocking vacuum, sequences nearing exhaustion, bloat, and dozens more. - The verdict. How findings reach the operator: deterministic status tags first, optional AI synthesis second, with a severity floor that prevents the model from softening CRITICAL to "consider investigating". You'll leave the presentation with a concrete catalogue of the issues a structured PostgreSQL snapshot surfaces (and which a human can definitely miss), and an invitation to extend the rule pack: radar and radar-ui are open source.https://www.postgresql.eu/events/pgconfeu2026/schedule/session/8013/DBA (25 minutes)Jimmy Angelakos10:2500:30Audit 2If you are new to PostgreSQL, you have probably already asked it: why does it work like this? Why does vacuum exist? Why does autovacuum run in the background? Why do parts of PostgreSQL feel designed for a different era? They were. And I found out why. In January 2026, I sat down with Greg Kemnitz and Curt Kolovson — two engineers who built the original Postgres at Berkeley in the late 1980s under Professor Michael Stonebraker. Presented in documentary style, this talk brings their answers directly to you. Vacuum was never designed for MVCC — it was built for optical storage that barely exists anymore. The no-overwrite storage model was a workaround for 1986 hardware constraints. Lisp was chosen for the query optimizer because it was the hot language of the moment, then spent a year being removed because the bugs were unmanageable. The early mascot was a turtle. Because the database was that slow. These aren't just good stories. They are the answer to the question every PostgreSQL beginner eventually asks — told by the people who were actually there. You will leave with the human reasoning behind PostgreSQL's most foundational decisions, and a completely different way of understanding the database you are learning.https://www.postgresql.eu/events/pgconfeu2026/schedule/session/8310/Community (25 minutes)Ellyne Phneah10:2500:30Audit 3PostgreSQL 18 brought asynchronous I/O to most scan types, letting Postgres read ahead and hide storage latency instead of stalling on every page read. But support for "plain" index scans was deferred. Such support requires a fundamental rethink of how the scan orders work internally, making it a large and complicated project in its own right. Work now targeting PostgreSQL 20 will add support for prefetching during index scans. This talk (giving by one of the authors of the index prefetching patch set) looks at what that means for users: which kinds of queries are faster, and by how much.https://www.postgresql.eu/events/pgconfeu2026/schedule/session/8163/Postgres Internals (25 minutes)Peter Geoghegan10:2500:30SM1-AThe PostgreSQL and its ecosystem are not being just distributed as source code, they are also distributed in various binaries formats -- and RPMs are one of them. This talk will go through the packaging cycle: What do package, how to package, how to maintain the package and its lifetime.https://www.postgresql.eu/events/pgconfeu2026/schedule/session/8027/Community (25 minutes)Devrim Gündüz10:5500:30Otherhttps://www.postgresql.eu/events/pgconfeu2026/schedule/session/8494/Breaks11:2500:50Audit 1PostgreSQL’s shared memory system has traditionally relied on static allocation at server startup, with a two-stage request process that differs between extensions and core subsystems. While robust, this model limits flexibility, complicates extension development, and often requires restarts to load extensions that require even small portion of the shared memory. In this talk, we present recent improvements to PostgreSQL’s shared memory infrastructure, including the new ShmemRequestStruct and ShmemRequestHash APIs. These APIs unify shared structure requests into a single step which is same for both the core subsystems and extensions. They also enable shared memory allocation beyond the early startup phase, avoiding server restarts when loading extensions. These changes form the foundation for an elastic shared memory model paving the way for resizable shared memory structures, which can grow and shrink at runtime while consuming only the memory they actually require. This work, in turn, becomes a key building block for future work, including the ability to resize shared buffers without requiring a server restart. A long-standing limitation in PostgreSQL is about to be lifted. You will learn how to use the new shared memory APIs to simplify extensions. You will get a sneak peek into the APIs of resizable shared structures and shared buffers from the co-author himself.https://www.postgresql.eu/events/pgconfeu2026/schedule/session/7917/Postgres Internals (45 minutes)Ashutosh Bapat11:2500:50Audit 2When cleaning up some old data we found some corrupted pages in a toast table. Suddenly these corruptions blocked the vacuum and transaction wrap around was waiting for us just around the corner. In this presentation I will guide you through the entire journey from detecting the corruption, unblocking the vacuum, decision making and fixing/mitigation the effects of the corruptions. For all of these steps you need different extensions and I will guide you through all of them. The extensions are great, but didn't provide us all the information we needed. To close the final gap we have been inspecting all pages of an index to find the missing links. The goal for this presentation is to build confidence and skills for whenever you might face a corruption.https://www.postgresql.eu/events/pgconfeu2026/schedule/session/8034/DBA (45 minutes)Derk van Veen12:1501:00Otherhttps://www.postgresql.eu/events/pgconfeu2026/schedule/session/8499/Breaks13:1500:30Audit 1I have been giving lightningtalks for several years now at pg-nl meetups and sometimes at pgconf.eu, now I bundeled a selection of those up in a 25 minute high-energy collection. The topics include: - ORM’s are the root of all evil (or at least most of it) - Embedding a date into a bigserial - When partitioning had unforeseen consequences - Geospatial indexes without PostGIS - What really is selectivity ? - That time when just one unusual little index had a major impacthttps://www.postgresql.eu/events/pgconfeu2026/schedule/session/7975/DBA (25 minutes)Ellert van Koperen13:1500:30Audit 2Postgres availability is currently bound by the volume of WAL generated since the last checkpoint; the server simply cannot accept connections until every single record is replayed. What if we could decouple startup time from WAL volume? This talk explores an experimental architecture for on-demand WAL Replay, where the server opens for connections immediately after a crash, and individual pages are recovered lazily only when requested by a client. This shifts recovery from a global blocking operation to a granular, page-level cost. In this talk We will explore the problems encountered during the implementation of on-demand recovery, the strategies used to solve them, and the unresolved design challenges I am trying to solve. Problems Faced: 1. couldn't skip replaying in-total. 2. Initially It was very slow to read all the related WALs of a specific page every time on on-demand replay. 3. what happens when checkpointer timeout or manual checkpoint runs during on-demand replay? 4. what if no one requests for a page for a long time? 5. what if on-demand replay happens recursively?? because Each WAL touches more than 1 page. 6. pg_basebackup was able to see inconsistent data. Open Challenges: 1. on-demand replay relies on a shared hashtable ,but it's required to know the size (number of pages to recover) upfront which is not possible in crash recovery. 2. Recent changes in PG 18 make it unsafe to perform replay at the point where pages are read during recovery, as this now happens inside a critical section.https://www.postgresql.eu/events/pgconfeu2026/schedule/session/7858/Postgres Internals (25 minutes)Srinath Reddy Sadipiralla13:1500:30Audit 3PostgreSQL has dozens of logging-related settings, but it is not always obvious what they actually log, how they interact, what they cost, and which operational questions they can answer. This talk is a practical walkthrough of PostgreSQL logging in plain language: how to choose settings based on the questions your logs need to answer, without adding unnecessary overhead or missing important signals. The session works through real production scenarios: investigating production incidents, finding slow queries, diagnosing lock waits, tracking temp file spills, understanding checkpoint pressure, and investigating autovacuum activity. Each scenario compares logs with standard monitoring queries, shows which logging settings add useful context, explains where they overlap with pg_stat_* views and pg_stat_statements, and discusses how to choose the better source of information for the question at hand. Practical examples include why log_duration is rarely the setting you want, when log_hostname adds cost without useful context, and why the right log_line_prefix makes a real difference. Attendees leave with a clear mental model of PostgreSQL logging, a checklist for reviewing production logging, and a framework for choosing settings that fit their workload.https://www.postgresql.eu/events/pgconfeu2026/schedule/session/7961/DBA (25 minutes)Alicja Kucharczyk13:1500:30SM1-Apostgres_fdw is the standard way to query remote PostgreSQL servers, but every scan uses a cursor, and cursors prevent the remote server from using parallel query plans. For large analytical queries, this means leaving significant performance on the table. This talk presents streaming_fetch, a new option for postgres_fdw that replaces cursor-based fetching with libpq's chunked rows mode. When enabled, the remote query gets results stream back in a configurable chunk, Now, since this doesn't use cursors, the remote server can use a parallel plan if it is performant. The option is available at both server and table level and defaults to off, so existing behavior is preserved. The interesting engineering challenge is multi-scan coordination. Cursors are naturally multiplexed on a single connection — several can be open simultaneously with no conflict. Streaming queries cannot: only one query can be in flight on a connection at a time. When a second scan starts on the same connection the ongoing stream must be drained and buffered before the new query can be sent. We solved this by draining remaining chunks into a tuplestore scan then the query fetches from it on demand. The talk covers the design of the fetch mechanism, the connection state tracking required to coordinate concurrent scans and the rescan handling that ties it together. We will also discuss what the patch deliberately does not do — async execution is incompatible with streaming mode and is disabled automatically , this is a work in progress and the patch is available in commitfest. The talk will provide a concrete understanding of how postgres_fdw's scan lifecycle works, where the parallel-query barrier lies today, and how streaming fetch removes it.https://www.postgresql.eu/events/pgconfeu2026/schedule/session/8076/Postgres Internals (25 minutes)Rafia Sabih13:5500:50Audit 1PostgreSQL’s query planner attempts to estimate the runtime cost of various plans, but those estimates can be based on statistics which are sometimes misleading and can change over time. This means that the planner will sometimes switch from a good plan that runs quickly to a poor one that runs extremely slowly, sometimes without warning. At other times, even the initial choice of plan will be suboptimal. Historically, PostgreSQL has provided few ways for users to control planner behavior, making such problems difficult to prevent or resolve. In this talk, I’ll discuss my work on pg_plan_advice, a contrib module which I hope will ship as part of PostgreSQL 19. pg_plan_advice is intended to serve a variety of use cases, including (1) regenerating in whole or in part a plan previously discovered to work well, (2) enforcing choice of an alternate plan that the user prefers over the one that the planner would normally select, or (3) debugging the failure of the planner to produce what the user believes to be the correct plan. In this talk, I’ll give an overview of what this module does, how it does that, and what problems had to be solved in order to enable it to do those things In addition, I’ll briefly discuss potential future features that could use this feature as scaffolding.https://www.postgresql.eu/events/pgconfeu2026/schedule/session/7993/Postgres Internals (45 minutes)Robert Haas13:5500:50Audit 2PostgreSQL supports AIO since version 18, and it's gradually adopting it in more and more places. Let's talk about the performance impact you should expect, tuning the various configuration options, and the pros/cons etc. I'll briefly explain the overall AIO architecture, and the expected benefits. Then we'll go over the main configuration options - their purpose and tuning them, with the various trade offs. During the talk I'll present various benchmarks, to illustrate the points. This is a talk about internals / PostgreSQL feature, but it's intended for PostgreSQL users / DBAs.https://www.postgresql.eu/events/pgconfeu2026/schedule/session/8020/DBA (45 minutes)Tomas Vondra14:5500:50Audit 1When encountering a postgres instance that is too slow, it's not always easy to identify what makes it slow. Having been asked to analyze "slowness" many times and having worked on postgres for a long time, I will show how I approach answering that question. Topics will include: - What to look at first? - When to look at postgres statistics, when to look at kernel statistics. - Seeing a lot of IO in the EXPLAIN ANALYZE of a query may or may not indicate IO being the bottleneck. How to identify which one is which? - When looking at wait events, sometimes seeing LWLock wait events can indicate contention internal to postgres, other times it indicates being IO bound. - How to identify if the latency between postgres and clients likely the bottleneck? - Is the problem just "too many fast queries"?https://www.postgresql.eu/events/pgconfeu2026/schedule/session/8186/DBA (45 minutes)Andres Freund14:5500:50Audit 2PostgreSQL relies on multiple configuration files. Among them, pg_hba, pg_ident, and pg_hosts use tabular formats with slightly different semantics. The format of these files is unique to PostgreSQL and has been part of the project since its early days. Back then, tabular configuration formats were more common, but they are relatively rare nowadays. The format has accumulated many features over the years, and the resulting complexity is especially visible in pg_hba.conf: support for includes, a complex options section at the end of each line, and yet another include syntax within those options. As PostgreSQL authentication methods and deployment environments continue to evolve, these limitations are becoming increasingly apparent. At this point, the format is difficult to read for both humans and machines, and it is becoming increasingly difficult to extend as authentication options continue to grow. This talk presents an ongoing effort rather than a finished feature. We'd like to modernize these configuration files using a modern structured configuration format, making them more readable and easier to work with across a wide range of use cases. We'll showcase our ideas, present our current proposal for an alternative format, and discuss some of the practical considerations around introducing it. Most importantly, we'd like practical feedback from DBAs, PostgreSQL users, and contributors: what would you like to see, what's missing, and what's unnecessary? Feedback is welcome even before the talk, whether by email or on pgsql-hackers. If you send it early enough, we may even be able to incorporate it into the presentation!https://www.postgresql.eu/events/pgconfeu2026/schedule/session/8344/Postgres Internals (45 minutes)Zsolt Parragi15:5500:30Audit 1You heard that PostgreSQL also supports the JSON data type, and you wanted to enjoy the dynamics of schema freedom mixed with the benefits of a relational database. You wanted a flexible data type combined with columns with strong types, with relationships between tables, and with constraints to guarantee data integrity. But now that you have integrated JSON deep in your schema design, you start observing odd behaviors, unpredictable performance, and unused indexes. You start to wonder if you haven’t introduced an evil data type disguised as a friendly and flexible object… Maybe there are things you could do in Postgres to make things run faster. Are some indexes better than others? What about table partitioning? And what about TOAST tables? Do they play a role accessing the data stored in JSON? Or maybe the B in JSONB stands for Beast? Can you tame the JSONB objects? In this talk we will review schema-design decisions when using JSON/JSONB in PostgreSQL, with some tips and tricks, based on experience working with real case scenarios. We will work through a case study to create a pragmatic view of working with JSON/JSONB in PostgreSQL.https://www.postgresql.eu/events/pgconfeu2026/schedule/session/8224/App Developer (25 minutes)Boriss Mejias15:5500:30Audit 2The PostgreSQL community is maintaining a list of recognized Major and Significant Contributors, curated by the Contributors Committee. Getting onto this list requires a lot of dedication; the people on this list have worked on PostgreSQL for years. To recognize a broader range of contributors, we are introducing contributor badges. A "badge" is awarded for any kind of contribution to the PostgreSQL community. Examples are "PostgreSQL 19 Contributor", "PGConf.EU 2026 Speaker", "Patroni Contributor" and everything that benefits PostgreSQL and the open source ecosystem around it. Each contributor gets a page under postgresql.org/community/people/ where badges appear as clickable images for more details. This talk offers a look behind the scenes of the Contributors Committee and how the badges are implemented in postgresql.org's Django framework. We hope the badges help making contributions to PostgreSQL more visible. And as a side-effect, badges will help us with adding new people to the recognized contributors list.https://www.postgresql.eu/events/pgconfeu2026/schedule/session/8089/Community (25 minutes)Christoph BergMelanie Plageman15:5500:30Audit 3PostgreSQL’s query optimiser is highly advanced, but it can still make mistakes. Traditional monitoring tools, such as pg_stat_statements, track execution performance metrics, including CPU time, I/O, and duration. They don't show how far off the planner's predictions were. A query that finishes in 100ms might seem fine, but if the planner expected 10000 rows and got 100, it may mean the query could have executed in 10ms if tuned. On a scale of millions of executions, it may yield a significant performance gain. In this talk, I’ll introduce pg_track_optimizer, an extension I built to spot planner errors in databases that handle many different queries. There, I calculate metrics that compare the planner's expectations to what really occurred.https://www.postgresql.eu/events/pgconfeu2026/schedule/session/7926/Postgres Internals (25 minutes)Andrei Lepikhov15:5500:30SM1-APostgres on Kubernetes usually works well enough — until the operator itself becomes part of the incident. The harder problems tend to show up in two areas that operator documentation rarely covers: troubleshooting incidents that cross multiple systems, and sizing the operator pod and its reconciliation behaviour. This session draws on real cases from working on the Percona Operator for PostgreSQL. The specific incidents are tied to design choices we made and bugs we shipped; different operators will hit different problems. What generalises is the shape of the problem. Key discussion areas: - Why debugging operator-managed Postgres often means debugging three systems at once: Kubernetes, the operator, and Postgres - Correlating operator logs, Postgres logs, controller state, and Kubernetes events into a single debugging workflow - Sizing the operator pod: CPU, memory, and how much work it is allowed to reconcile in parallel Attendees will leave with practical knowledge for debugging operator-managed Postgres, a starting point for sizing operator, and a set of questions to ask before trusting any Postgres operator in production. This session is intended for SREs, DBAs, and platform engineers running or evaluating Postgres on Kubernetes.https://www.postgresql.eu/events/pgconfeu2026/schedule/session/8319/Community (25 minutes)Natalia Marukovich16:2500:30Otherhttps://www.postgresql.eu/events/pgconfeu2026/schedule/session/8500/Breaks16:5500:45Audit 1https://www.postgresql.eu/events/pgconfeu2026/schedule/session/8506/PGConf.EU17:4000:15Audit 1Let us wrap up PostgreSQL Conference Europe 2026 together. While the main event might be over, we'll take a look at some stats from the event, a look at upcoming events and maybe where next years event will be. Don't forget we've also got the Community Events Day starting on the Friday, so you don't want to wait long. So long and thanks for all the fish!https://www.postgresql.eu/events/pgconfeu2026/schedule/session/8507/PGConf.EU