Firefly2026-01-302026-02-013https://www.postgresql.eu/events/fosdem2026/schedule/08:3000:30Otherhttps://www.postgresql.eu/events/fosdem2026/schedule/session/7629/Breaks09:0000:20Otherhttps://www.postgresql.eu/events/fosdem2026/schedule/session/7630/Breaks09:3000:50Ballroom AImplementing new ideas and concepts in any codebase always carry an element of exploration, Postgres is no exception. A Postgres cluster is a complex machine with many interoperating subsystems, and features that span subsystem boundaries need to understand how these interact, and which states they can be in. Synchronizing state across a distributed system might not be the final frontier, but it is challenging and filled with learning. Sometimes an idea seem so well defined and contained, that it just makes sense. The finish line is almost in sight before firing up the editor. Hacking starts and progress is fast, the first patch is done in mere hours. But, as the surface is scratched and that small corner which was cut in the proof of concept patch is addressed, more corners appear. Then, even more corners lurk in the shadowy depths of the codebase turning the straight path into a winding mountain road. Hours turns to days, days turns to months and.. This talk will use the proposed patchset for enabling data checksums in an online cluster as an example of how a complex patch evolves from the initial proof of concept as the domain is explored and more is learnt. It will discuss what kinds of unexpected architectural and correctness issues we ran into, how to tackle the unknowns, the importance of identifying scope and how to stay motivated as problems mount and time pass. This is not a talk about a failure, but about how embarking on a patch adventure can bring deeper understanding of the system makes us grow as developers and reviewers.https://www.postgresql.eu/events/fosdem2026/schedule/session/7467/Postgres Internals (45 minutes)Daniel Gustafsson09:3000:50Ballroom BUpgrading high load PostgreSQL databases is a challenge on its own. When having customers around the globe with tight SLAs, the requirement arises to execute these upgrades with minimal or even no downtime at all. This talk shares GitLab's journey from multi-hour maintenance windows to truly zero-downtime upgrades for our PostgreSQL infrastructure. You'll learn the battle-tested techniques we've developed over the last 4 years, like how we execute PostgreSQL major upgrades and OS (glibc) upgrades at the same time, prevent data corruption, as well as always keeping a rollback path via reverse replication. We'll walk through real production examples, the gotchas we discovered, and the tooling we built. Whether you're managing a single HA cluster or a global fleet, you'll leave with actionable strategies to minimize (or eliminate) downtime during your next major upgrade.https://www.postgresql.eu/events/fosdem2026/schedule/session/7370/DBA (45 minutes)Alexander Sosna10:2000:30Otherhttps://www.postgresql.eu/events/fosdem2026/schedule/session/7631/Breaks10:5000:50Ballroom ACalculating percentiles/quantiles is a part of many common analytical tasks. Calculating them exactly is expensive, and it's difficult to apply some of the usual strategies - calculate them incrementally, or pre-calculate the results. So what can we do about it? In this talk I'll show lesser-known ways to calculate estimates or percentiles (you can also say it's approximating the percentiles). I'll talk about extensions tdigest/ddsketch, and possibly some additional ones. I'll explain the ideas these extensions (or rather the user-defined data types) are based on. We'll also see how we can use this to generate histograms, which is a representation understandable for many users.https://www.postgresql.eu/events/fosdem2026/schedule/session/7465/App Developer (45 minutes)Tomas Vondra10:5000:50Ballroom BpgBackRest is a reliable and flexible backup solution for PostgreSQL, built to scale effortlessly for even the largest databases and most demanding workloads. But like any tool, its true power comes from knowing how to use it right. In this talk, we'll take a closer look at pgBackRest's archiving system, a core component of Point-in-Time Recovery (PITR). You'll learn its capabilities and limitations, and see how asynchronous operations can significantly boost PostgreSQL WAL archiving performance. We'll also explore advanced recovery techniques, including partial data restoration, to show how pgBackRest unlocks recovery scenarios that PostgreSQL itself does not normally support. Already using pgBackRest or just considering it? This talk will help you reach its full potential and bring your PostgreSQL backup and recovery strategy to the next level.https://www.postgresql.eu/events/fosdem2026/schedule/session/7324/DBA (45 minutes)Stefan Fercot11:5000:50Ballroom ARunning PostgreSQL on Kubernetes introduces unique storage challenges that require careful attention to performance, reliability, and architecture. CloudNativePG, a CNCF Sandbox operator, simplifies PostgreSQL cluster lifecycle management and provides a native Kubernetes experience for deploying and operating resilient database workloads. However, it remains storage-agnostic by design, leaving it up to administrators to evaluate and select the most suitable and performant StorageClass for their environment. In this talk we’ll dive into how PostgreSQL’s behavior (such as WAL writes, buffer management, and sequential scans) impacts storage performance and why the choice between local and network-attached volumes can significantly affect workload efficiency. Through practical examples from a Data on Kubernetes guide, using benchmarking tools like FIO and pgbench you’ll learn how to evaluate persistent volumes, capture I/O baselines, and identify potential bottlenecks before they impact production. These insights are essential for tuning performance and building resilient, data-intensive platforms on Kubernetes. CloudNativePG: https://github.com/cloudnative-pg/cloudnative-pg FIO: https://fio.readthedocs.io/en/latest/ DoK Benchmark guide: https://github.com/dokc/best-practices-research/https://www.postgresql.eu/events/fosdem2026/schedule/session/7401/DBA (45 minutes)Jonathan Battiato11:5000:50Ballroom BJIT has been part of PostgreSQL for the past 6 years. Yet, why are we (you maybe, me surely) using "jit = off" in our postgresql.conf file? In this talk, we will answer this question, and many many more you may have asked yourself about JIT compilation: - what is JIT compilation exactly? How does it differ between PostgreSQL and other well-known JIT users (JVM, CLR, spidermonkey, V8...) - what is compiled in PostgreSQL currently? - what are the benefits and drawbacks of LLVM as a JIT provider? - any alternative JIT provider around, aka how fast could PostgreSQL get?https://www.postgresql.eu/events/fosdem2026/schedule/session/7321/Postgres Internals (45 minutes)Pierre Ducroquet12:4001:00Otherhttps://www.postgresql.eu/events/fosdem2026/schedule/session/7632/Breaks13:4000:20Ballroom ALightning Talkshttps://www.postgresql.eu/events/fosdem2026/schedule/session/7586/Lightning Talk (5 mins)14:1000:50Ballroom AEver wonder what happens during the 15-month development cycle for a new Postgres release? Ever wonder about all of the work that brings each new release to life? Let’s find out. In an open source project like Postgres, recognizing behind-the-scenes volunteer efforts isn’t just nice—it’s necessary to keep the momentum. This talk shares an analysis of contributions to Postgres in the v18 timeframe. The research is done by Postgres committer Daniel Gustafsson and Claire Giordano—and leverages data from public sources like commit logs, mailing lists, and PostgreSQL.org. You’ll see maps and charts as you learn about the people behind governance, conferences, meetups, infrastructure, and the code. You’ll leave with an appreciation for the full spectrum of work behind a Postgres release—and ideas about how you can earn one of those coveted Postgres coins.https://www.postgresql.eu/events/fosdem2026/schedule/session/7460/Community (45 minutes)Claire Giordano14:1000:50Ballroom BPostgreSQL’s executor still processes one tuple at a time -- a design inherited from the classic iterator model that favors modularity but adds significant per-tuple overhead on modern CPUs. Each tuple crosses multiple function call and branch boundaries, which limits instruction and cache efficiency even in simple scans. Recent improvements -- opcode-based expression evaluation, scan inlining, and faster tuple deforming -- have reduced overhead in key paths, but the iterator model remains a bottleneck for analytic workloads. This talk presents a prototype that enables executor nodes to operate on batches of tuples instead of individual slots, reducing per-tuple costs while preserving PostgreSQL’s row-based semantics and plan structure. The patch introduces an ExecProcNodeBatch() API and a TupleBatch abstraction for passing groups of tuples between nodes, along with table AM extensions for batch-mode scans. Expression evaluation is adapted to process batches in tight loops, paving the way for more efficient execution over large data sets. The talk will describe the prototype design, early performance results, and outline possible next steps toward broader batch-aware execution in PostgreSQL.https://www.postgresql.eu/events/fosdem2026/schedule/session/7366/Postgres Internals (45 minutes)Amit Langote15:1000:50Ballroom AIn this talk I will explore the popular pgvector HNSW index and show how it plugs into PostgreSQL. We will look at some of the ideas from academic papers about the wider "approximate nearest neighbours" family of indexes to get some basic intuitions about the problem domain, and the basic implementation tricks in comparable systems. Then we'll hunt down as many low-level inefficiencies as we can find along the way as we try them out. The adventure will involve prototyping and evaluating changes to both PostgreSQL and pgvector, including: * asynchronous I/O * the buffer pool * the cache hierarchy * parallelism Note: despite choosing pgvector as a subject, this is definitely not a talk about AI! It's a PostgreSQL hacking talk. Many of the ideas discussed apply to other kinds of indexes, but this is an interesting motivating example.https://www.postgresql.eu/events/fosdem2026/schedule/session/7491/Postgres Internals (45 minutes)Thomas Munro15:1000:50Ballroom BFor me, database corruptions are the most frightening problems to face. I see it as my primary task to keep the data safe and available, and corruptions are an especially tough nut to crack when you encounter them. They can be many years old, and restoring from a backup might not be an option. I've now faced corruptions multiple times and can deal with them with confidence. I'd like to show you how you can handle corruptions as well, without losing any data or have to rely only on your backups. There are multiple ways to corrupt data yourself, but today I'll focus on transaction corruptions caused by sub-optimal planning on my side, or maybe a bug in the system, I am still not totally sure. Corruptions are hard to fix because they require a deep understanding of multiple parts of the database. In this presentation, I'll guide you through the entire journey, from detecting the corruption and unblocking the vacuum, to decision-making, and finally mitigating and fixing the problem. For all these steps, you'll need different extensions, and I'll walk you through each of them. After this presentation, you should have the confidence to start tackling corruptions yourself. With the help of our blog at https://www.adyen.com/knowledge-hub/database-corruption-in-postgresql, you'll be the company hero who ensures the company's data remains secure and recoverable, even in the face of corruption.https://www.postgresql.eu/events/fosdem2026/schedule/session/7455/DBA (45 minutes)Derk van Veen16:0000:30Otherhttps://www.postgresql.eu/events/fosdem2026/schedule/session/7633/Breaks16:3000:50Ballroom APostgres adds about 200 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 optimizer hints, sharding, cluster file encryption (i.e., TDE), global indexes, and multi-master replication.https://www.postgresql.eu/events/fosdem2026/schedule/session/7327/DBA (45 minutes)Bruce Momjian16:3000:50Ballroom BThe latest Stack Overflow survey shows 84% of developers are using or planning to use AI. But for PostgreSQL, what does this mean beyond just autocompleting SQL queries? Is that all there is? This talk explores how AI-assisted IDEs are creating a new "vibe" for database development, one that goes far beyond code generation. We will demonstrate how these tools are becoming intelligent partners for a variety of roles. We'll look at schema-aware refactoring for developers, automated performance analysis for DBAs, and even natural language to complex-query workflows for business users. This is your guide to taking real advantage of the AI in your daily work with Postgres.https://www.postgresql.eu/events/fosdem2026/schedule/session/7429/App Developer (45 minutes)Matt Cornillon17:2000:10Otherhttps://www.postgresql.eu/events/fosdem2026/schedule/session/7634/Breaks