Microsoft Reactor Redmond

Now in its 5th year, POSETTE: An Event for Postgres (pronounced /Pō-zet/) is a free and virtual developer event. The name POSETTE stands for Postgres Open Source Ecosystem Talks Training & Education. Happening 16-18 June 2026, join us for 4 unique livestreams to hear from open source users and experts in many aspects of the PostgreSQL ecosystem—including on Azure. Come learn what you can do with the world’s most advanced open source relational database—from the nerdy to the sublime. Come chat with POSETTE speakers & other community members on the #posetteconf channel in the Microsoft Open Source Discord before, during, and after the event. Full schedule & speakers for Livestream 3 below. In the meantime, you can catch up on last year’s talks at https://aka.ms/posette-playlist.

Organized by the Postgres team at Microsoft, in partnership with AMD. More info on POSETTE can be found on the POSETTE website.

---
Livestream 3 Agenda

|Session Title | Session Description | Speaker |
| :---------------- | :---------------------- | :----------------------- |
| | | |

| The Wonderful World of WAL | The Postgres write-ahead log, or WAL, is basically a change-log for the database. It enables several important Postgres features: crash recovery, point-in-time recovery, and binary and logical replication. This talk explains what is stored in the WAL, how binary and logical replication work, and how replication slots track replication progress.
SLIDES AT https://momjian.us/main/writings/pgsql/wal.pdf | Bruce Momjian |
| --------------------------------------------------------------------------- | ---------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | --------------------------------------------- |
| Building Event-Driven Systems with PostgreSQL Logical Replication and Drasi | PostgreSQL's logical replication captures database changes in real-time, but most developers still rely on external streaming platforms like Kafka for event processing. This session shows you how to build event-driven architectures directly on PostgreSQL using its write-ahead log and Drasi, a CNCF Sandbox project that adds continuous queries and filtering on top of change data capture.
You'll see a comparison of three CDC approaches: wal2json with custom consumers, Debezium with Kafka, and Drasi with PostgreSQL. I'll walk through live benchmarks measuring database overhead, end-to-end latency, and lines of code required for each approach. Using a working example, I'll demonstrate how PostgreSQL captures changes, how Drasi filters them with declarative queries, and how to trigger downstream actions—while monitoring PostgreSQL's actual CPU and network usage throughout.
You'll learn when logical replication makes sense for your architecture, how to configure replication slots and publications, how to avoid WAL accumulation issues, and how to choose between different CDC approaches based on your requirements. This session focuses on practical PostgreSQL skills you can apply immediately, whether you're building on Azure, AWS, or on-premises. | Diaa Radwan |
| pgcov: Bringing Real Test Coverage to PostgreSQL Code | We rely heavily on PostgreSQL functions, procedures, and SQL logic, yet we largely test them as black boxes. Tests may pass, but we rarely know what actually executed and what code paths remain untested.
pgcov proposes a missing piece in the PostgreSQL tooling ecosystem: coverage analysis for SQL and PL/pgSQL, similar to what `go test -cover` or `pytest --cov` provides for application code.
The idea is simple:
- treat SQL as first-class source code,
- run isolated tests against it,
- instrument execution at the SQL/PLpgSQL level,
- and produce actionable coverage reports.
pgcov does not require PostgreSQL extensions, does not depend on psql, and is designed to integrate naturally into CI/CD pipelines. It complements existing testing tools like pgTAP by answering a different question:
“Which parts of our database code are actually tested?”
This talk explores the motivation, design approach, and how pgcov can significantly improve confidence in database-centric systems without changing how we write PostgreSQL code today. | Pavlo Golub |
| Quorum-Based Consistency for Cluster Changes with CloudNativePG Operator | Most people don’t think of Postgres in the context of quorum or distributed systems theory but vanilla open source Postgres has supported quorum commits across multiple replicas for almost 10 years now. Technologies like cassandra and dynamo popularized quorum consistency in the hot path of distributed writes and reads, but the theory also applies to cluster reconfigurations in a single-writer database like Postgres. Stateful operators at level V of the capabilities framework require very careful end-to-end coordination between control plane and data plane algorithms to avoid data loss when providing auto-healing under circumstances like network partitions or compounded failures. This session will explore how quorum consistency can be applied in the CloudNativePG operator, offering insights to users of Postgres on Kubernetes about trusting Postgres to keep our data safe. | Jeremy Schneider & Leonardo Cecchi |
| From Queries to Agents: The Next Era of Data Retrieval on PostgreSQL | As AI agents move from demos to production, the real challenge isn’t the model, it’s reliable, safe, and context‑aware data retrieval. In this talk, we explore how PostgreSQL is becoming the backbone for agent workflows through emerging retrieval patterns that begin with today’s Model Context Protocol (MCP) and point toward more unified approaches.
We’ll break down how agents interact with Postgres today using MCP servers, what goes wrong when agents generate SQL blindly, and why retrieval increasingly requires robust context correction alongside blended retrieval, vector similarity, relational SQL, and graph‑aware traversal working together to give agents a complete and reliable view of the data.
We’ll then outline the architectural principles shaping the next generation of retrieval layers—designed to give agents controlled, high‑quality access to Postgres without bespoke glue code.
You’ll leave with a clear mental model for building Postgres‑backed agents today, and a practical roadmap for where agent retrieval at Microsoft is heading next. | Abe Omorogbe |
| PostgreSQL 17 vs 18: Side‑by‑Side Performance Wins in Real‑World Queries | Simply upgrading PostgreSQL can make many everyday queries run faster, without any schema changes or application rewrites. In this talk, I’ll do a side‑by‑side comparison of Postgres 17 and 18 using common query patterns that developers and operators see in real systems. For each example, I’ll compare execution plans and runtimes to show where PostgreSQL 18 is faster and what planner or executor changes are responsible. | Divya Bhargov |
| Production RAG at Scale with Azure Database for PostgreSQL | One of PostgreSQL's greatest strengths is its ability to serve as more than just a traditional database—it can be the foundation for intelligent systems. With the rise of AI-powered applications, PostgreSQL has emerged as a powerful platform for Retrieval-Augmented Generation (RAG) implementations. So, why should we consider PostgreSQL over specialized vector databases for production RAG systems?
In this talk, we'll explore a complete production RAG architecture that powers Serenity Star's enterprise knowledge management platform. With features like pgvector for semantic search, DiskANN for high-performance indexing, and seamless integration with Microsoft Semantic Kernel, PostgreSQL proves itself as a robust foundation for intelligent knowledge systems processing millions of queries monthly.
Drawing from our real-world experience as Azure customers scaling RAG from prototype to production, we will share practical insights on architecture decisions, performance optimization strategies, and monitoring approaches. We'll cover the complete pipeline: from document chunking and vector storage to semantic search optimization and production monitoring and observability. | Julia Schröder Langhaeuser & Paula Santamaría |
| The Rise of PostgreSQL as the Everything Database | PostgreSQL is no longer just a transactional workhorse - it’s rapidly becoming the “everything database” for modern developers. Backed by a vibrant open-source community, Postgres is blurring the lines between OLTP, analytics, and vector storage, reducing the need for multiple specialized systems and the complexity that comes with them.
According to the 𝟮𝟬𝟮𝟱 𝗦𝘁𝗮𝗰𝗸 𝗢𝘃𝗲𝗿𝗳𝗹𝗼𝘄 𝗗𝗲𝘃𝗲𝗹𝗼𝗽𝗲𝗿 𝗦𝘂𝗿𝘃𝗲𝘆 (https://survey.stackoverflow.co/2025/technology#1-databases), PostgreSQL is now the #1 most used and most loved database, chosen by over 61% of professional developers. In this session, we’ll explore what’s driving that momentum - from native 𝘑𝘚𝘖𝘕 and 𝘵𝘪𝘮𝘦-𝘴𝘦𝘳𝘪𝘦𝘴 support to 𝘧𝘶𝘭𝘭-𝘵𝘦𝘹𝘵 𝘴𝘦𝘢𝘳𝘤𝘩, 𝘷𝘦𝘤𝘵𝘰𝘳 𝘦𝘮𝘣𝘦𝘥𝘥𝘪𝘯𝘨𝘴, and more, all built on Postgres’ extensible core.
We’ll also highlight how 𝗔𝘇𝘂𝗿𝗲 𝗗𝗮𝘁𝗮𝗯𝗮𝘀𝗲 𝗳𝗼𝗿 𝗣𝗼𝘀𝘁𝗴𝗿𝗲𝗦𝗤𝗟 helps developers scale with confidence in the cloud - offering enterprise-grade reliability, built-in AI, and fully managed infrastructure, all while staying true to familiar Postgres’ open-source roots.
If you're building apps, reducing data sprawl, or just love open source, come see why PostgreSQL is now the everything database. | Varun Dhawan |
| Postgres isn’t slow, your storage is | A lot of Postgres “scaling problems” look the same: low CPU, high latency, falling insert rates, and unpredictable behavior once the dataset gets big, in the TBs. In most cases we’ve investigated, the bottleneck wasn’t Postgres it was slow or inconsistent storage.
In this talk we run the same workloads on networked block storage and on local NVMe and show what actually changes. Using perf, flamegraphs, and Postgres internal stats, we demonstrate how WAL fsync, buffer reads, and checkpoints dominate on slow IO, and how those costs largely disappear on NVMe. Insert-heavy time-series workloads scale linearly, OLTP latency stays stable under reporting queries, and performance becomes predictable.
We also show where NVMe does not help. For wide scans and repeated aggregations over hundreds of millions of rows, Postgres still spends most of its time in executor and tuple-processing code. Fast storage moves the bottleneck to CPU, but it doesn’t turn a row store into a column store. | Sai Srirampur |
| Why we built Azure HorizonDB for PostgreSQL | Modern Postgres workloads keep running into the same questions: How do you get consistent performance when traffic suddenly spikes? How do you keep latency predictable? How do you scale reads without bolting on more replicas than needed? What do failovers look like when you can’t afford long down times?
This talk digs into why our Postgres team at Microsoft built Azure HorizonDB for PostgreSQL, a shared storage architecture designed to handle those pressures. We’ll walk through the core design decisions behind HorizonDB: what database as logs means, how storage and compute are separated, how scale‑out works, and more.
If you are interested in which problems HorizonDB is meant to solve, what differentiates it from other managed PostgreSQL offerings in Azure, or how you can leverage HorizonDB for your workloads—then this session will help you make sense of it. | Dingding Lu |
| Maintaining Large Tables in PostgreSQL | This talk focuses on the real problems large tables create at scale: autovacuum falling behind, bloat accumulating silently, planner misestimation, WAL explosions, and maintenance operations colliding with production traffic. Rather than treating these as isolated issues, we’ll examine them as symptoms of unsustainable data growth.
Using PostgreSQL (with specific considerations for Azure Database for PostgreSQL), the session walks through practical strategies to sustain performance over time: per-table autovacuum tuning, bloat and statistics management, maintenance options, and observability guardrails.
Finally, we’ll address the critical architectural questions: when is a large table no longer the right abstraction? We’ll compare options such as partitioning, hot/cold splits, rollup tables, sharding, and offloading analytical workloads. | Sarat Balijepalli |

Now in its 5th year, POSETTE: An Event for Postgres (pronounced /Pō-zet/) is a free and virtual developer event. The name POSETTE stands for Postgres Open Source Ecosystem Talks Training & Education. Happening 16-18 June 2026, join us for 4 unique livestreams to hear from open source users and experts in many aspects of the PostgreSQL ecosystem—including on Azure. Come learn what you can do with the world’s most advanced open source relational database—from the nerdy to the sublime. Come chat with POSETTE speakers & other community members on the #posetteconf channel in the Microsoft Open Source Discord before, during, and after the event. Full schedule & speakers for Livestream 4 below. In the meantime, you can catch up on last year’s talks at https://aka.ms/posette-playlist.

Organized by the Postgres team at Microsoft, in partnership with AMD. More info on POSETTE can be found on the POSETTE website.

---
Livestream 4 Agenda

|Session Title | Session Description | Speaker |
| :---------------- | :---------------------- | :----------------------- |
| My Postgres partitioning cookbook | Over the last three years, I have tried every single thing I could think of with Postgres partitions, and I made many mistakes. Most of them on my laptop; some lessons were a bit more painful. I've seen my fair share of performance problems and converted inheritance-based partitions to native and back. I've created many default partitions and by now managed to almost drop all of them.
In this session, I want to go over all my lessons learned, especially the ones that surprised me the most. I will cover the basics about index and foreign key creations and implicit inheritance. And how the foreign keys caused catalog corruptions because of cleaning up data. I will discuss the good, the bad, and the ugly of the default partition and leave it to you to judge them as a blessing or a curse. An important part of working with Postgres partitions is cheating with the catalog. When I proposed this to my team the first time, everybody was nervous about it, as they should have been, but these days we do it without thinking. It is bad practice, but sometimes it is just the only way to get things done.
This presentation will show you the basics, but also shows the pitfalls (mines) and obvious mistakes you can easily avoid. | Derk van Veen |
| Exploring property graphs with SQL/PGQ in PostgreSQL | Using relational databases, how do you efficiently determine an optimal path covering all your tickets in the game of Ticket to Ride? Traditionally, solutions to graph-like problems in PostgreSQL—such as reachability and shortest-path discovery—have relied on Recursive Common Table Expressions (CTEs), which are often verbose, difficult to optimize, and complex to maintain. The SQL:2023 standard introduces SQL/PGQ (Property Graph Queries), finally allowing a relational database like PostgreSQL to treat graph traversals as first-class, declarative operations. And we are working to bring SQL/PGQ support to a future release of PostgreSQL, hopefully in PostgreSQL 19!
In this session, you will explore property graph (SQL/PGQ) capabilities using the Ticket to Ride - like schema as a practical example. You will learn important aspects of SQL/PGQ: from defining a Property Graph over standard relational tables to using MATCH clause to implement pathfinding logic.
Beyond the game, the session provides an under the hood look at the SQL/PGQ implementation in Postgres. The transformation of graph patterns into relational join trees and the complexities of path-variable bindings will be discussed. You will leave with a clear understanding of the Postgres implementation of the SQL/PGQ standard from one of the authors of the patch himself. | Ashutosh Bapat |
| Journey of developing a performance optimization feature in PostgreSQL | In this talk, I will share the journey of identifying and optimizing a performance bottleneck in PostgreSQL. The session will walk through a systematic approach to diagnosing performance issues — distinguishing whether the bottleneck lies in the CPU, I/O, or network — and how iterative profiling and analysis can guide effective optimizations. Using perf and other diagnostic tools, we’ll examine how bottlenecks can shift during optimization, sometimes masking real gains. I will demonstrate how to effectively measure improvement in performance through careful tuning of the database, along with use of pgbench and custom benchmarking scripts tailored to the optimization under test.
As a practical example, we will explore an optimization in PostgreSQL’s physical replication that enables the WAL sender to transmit WAL records to standbys before they are flushed to disk on the primary. This enhancement aims to reduce replication latency by leveraging WAL buffers to send data more proactively, minimizing disk reads and improving network utilization. For large transactions, this approach allows most WAL data to be sent in parallel with ongoing writes on master, aligning the flush operations on primary and standby more closely and significantly reducing replication lag. | Rahila Syed |
| pg_duckdb in Action: Accelerating Analytics on Azure Database for PostgreSQL | If your analytics workflow starts with exporting data from Postgres, you’re not alone. Many teams build ETL pipelines just to answer questions about data that already lives in Postgres. But what if you didn’t have to move it at all? With pg_duckdb, you can run fast, columnar-style analytical queries inside Postgres without setting up a separate warehouse, a sync process, or another system to manage.
In this talk, I’ll walk through how pg_duckdb works, what it’s good at, and where it fits into real-world workflows. The demo will showcase pg_duckdb installed on Azure Database for PostgreSQL, where I’ll run analytical queries over existing tables and query Parquet files directly from object storage—without loading them into Postgres first.
It’s not a full replacement for a data warehouse, but in many cases, it’s a faster, simpler path to the answers your team needs—right from the database you already use. Attendees will learn how pg_duckdb works, how to use it effectively, and how to speed up analytics without extra tools or data movement. You’ll leave with practical tips and real examples you can apply right away. | Nitin Jadhav |
| Modelling Postgres Performance Degradation on Burstable Cloud Instances | Many developers run Postgres on "burstable" cloud instances (like Azure B-series or AWS T-series) to optimise costs. While cost-effective, these instances operate on a CPU credit model that introduces non-linear performance risks.
The danger is not a system crash, but throughput exhaustion. When CPU credits are depleted, the cloud provider throttles the CPU to its base frequency. Because Postgres is unaware of this external throttling, it continues to accept connections it can no longer process in a timely manner. This leads to a cascading failure, i.e. connection pools saturate, p99 latencies skyrocket, and the app layer eventually times out. The database will effectively be unavailable despite being "online."
In this session, I will demonstrate how to model the exact saturation point of a throttled Postgres instance. I will show you a simple simulation method to calculate your "Base Performance Ceiling" without the need for expensive load-testing infrastructure, allowing you to right-size your database before the credits run out. | Chun Lin Goh |
| Past, Present, and Future: Logical Decoding and Replication in PostgreSQL | Logical replication has evolved into a foundational capability for modern PostgreSQL deployments, enabling real-time data synchronization, partial replication. What began as a low-level decoding API in PostgreSQL 9.4 has now matured into a powerful feature, allowing for fine-grained control over what gets replicated and where.
In this talk, we’ll trace the journey of logical decoding and replication in PostgreSQL, from its early adoption through extensions like pglogical, to the robust native features introduced in recent PostgreSQL releases. We’ll dive into how these capabilities have empowered change data capture (CDC), zero-downtime migrations, and real-time analytics pipelines.
We’ll also explore how innovations in the ecosystem, particularly the work of Multi-master replication is shaping the future of distributed PostgreSQL. With features like out-of-box asynchronous logical replication, automated DDL propagation, and eliminating the traditional limitations of read-only replicas or single-writer systems.
Key takeaways:
- Understand the architecture and internals of logical decoding
- Compare native and extension-based logical replication
- Discover what's next: DDL replication, performance tuning, and multi-master replication | Hari Kiran |
| From Dev to Prod: Securing Postgres the Right Way | Is your Postgres database really secure, or just “working”? Why do security issues keep showing up after launch? Many teams rely on defaults until an incident proves otherwise.
This session tackles common Postgres security blind spots developers face in real systems. We’ll walk through practical techniques to secure access, data, and operations without slowing delivery and enhance the security posture of your application.
Key Takeaways:

1. Least-privilege roles, schema isolation, Role design and permission boundaries
2. Protecting data at rest and in transit
3. Safe extension and function usage
4. New Postgres enhancements around security and observability
   Join me to turn security into a design habit, not an afterthought. Looking forward to engaging with you. Let’s make the Postgres world a little more fun and secure!! | Sakshi Nasha |
   | Vacuuming Enhancements in PostgreSQL 18: Faster, Smarter, More Predictable | PostgreSQL 18 delivers one of the most significant sets of VACUUM and ANALYZE improvements in years, making maintenance faster, more predictable, and easier to tune. This session highlights the key changes and explains how they automatically alleviate common pain points in real-world workloads, backed by field experience.
   We’ll cover:
   Asynchronous I/O (AIO): Overlaps reads with processing to reduce heap-scan delays and speed up VACUUM.
   Dynamic autovacuum scaling: Adjust autovacuum_max_workers on the fly without restarts for elastic maintenance.
   Earlier autovacuum triggers: Use autovacuum_vacuum_max_threshold and hard caps to prevent bloat on large tables.
   Eager freezing: Shortens future anti-wraparound VACUUMs automatically.
   Explicit tail shrinking: Reclaims unused space at the end of tables without blocking operations.
   Recursive VACUUM/ANALYZE: Handles inheritance-based partitions seamlessly and avoids redundant ANALYZE for declarative parents.
   Improved observability: Real-time cost-delay attribution (track_cost_delay_timing), per-backend I/O/WAL stats, and byte-level I/O metrics for proactive tuning.
   | Shashikant Shakya |
   | Move Less, Move Faster: Speeding Up Citus Cluster Scaling | Scaling a distributed Postgres cluster often isn’t limited by “adding a VM”, it’s limited by how long it takes to rebalance data safely. In this talk, I’ll give a minimal mental model of how Citus distributes data (shards, placements, and coordinator/worker roles), then explain why cluster scaling can feel painfully slow: data movement is expensive, and concurrency is constrained by safety and resource limits.
   We’ll then look at two concrete steps toward faster elastic scaling:
   Shard rebalancing improvements that increase parallelism and reduce bottlenecks.
   Snapshot-based node addition, where a new worker starts as a clone of an existing one, dramatically reducing how much data needs to be copied during rebalancing.
   Attendees will come away with a clearer way to reason about scaling time, plus actionable guidance for running scale-out/scale-in events safely. | Muhammad Usama |
   | LISTEN Carefully: How NOTIFY Can Trip Up Your Database | LISTEN/NOTIFY is a powerful and elegant PostgreSQL feature for asynchronous communication between backend components. It allows lightweight data transfer and instant notification updates without the need for a separate message bus.
   However, hidden within this simplicity and elegance is a surprising hazard: NOTIFY can cause unexpected statement and lock timeouts that seem to come out of nowhere. The reason for this is that each NOTIFY call obtains a cluster-wide exclusive lock to serialize notifications. Under high concurrency, seemingly innocuous code can end up causing performance bottlenecks and confusing backend errors—especially once traffic scales to levels difficult to replicate in development or on your laptop.
   In this talk, we'll walk through a real-world scenario involving a trigger using NOTIFY to alert other systems LISTENing for changes made to a high-traffic table. We'll do a deep dive into the problems caused, the investigation of the symptoms, and a solution for fixing the issue in production.
   You'll leave this talk equipped with an understanding of this wonderfully useful feature, along with its potential risks and what you can do to mitigate them. | Jimmy Angelakos |
   | Where Does My INSERT Go? A Logical Replication Story | What really happens to a single INSERT in PostgreSQL once it enters the system? In this talk, we trace the complete lifecycle of one tuple as it travels through PostgreSQL’s logical replication pipeline. Starting at the executor, we watch the tuple become a WAL record, explore what changes when wal_level=logical, and reveal how the logical decoding layer reconstructs row-level changes from low-level WAL fragments. We’ll step through the inner workings of the ReorderBuffer, explain how replication slots guarantee durability, and show how output plugins convert decoded changes into a logical stream ready for subscribers.
   On the receiving side, we follow the apply worker as it processes transactions, resolves ordering, handles conflicts, and replays the change into the subscriber database. By the end, you’ll have a clear mental model of each stage—from WAL generation to apply—and a deeper understanding of how PostgreSQL reliably moves data through logical replication.
   Whether you run logical replication, build CDC pipelines, or simply want to understand the internals behind one of PostgreSQL’s most powerful features, this talk will give you a guided, intuitive, and highly practical look behind the scenes. | Hamid Akhtar |

📌 This session is a part of a series, learn more here!