This event is part of the POSETTE 2026 Series.
Click here to visit the Series Page where you could see all the upcoming and on-demand events.
LEARN, CONNECT, BUILD
Microsoft Reactor
Join Microsoft Reactor and engage with developers live
Ready to get started with AI and the latest technologies? Microsoft Reactor provides events, training, and community resources to help developers, entrepreneurs and startups build on AI technology and more. Join us!
LEARN, CONNECT, BUILD
Microsoft Reactor
Join Microsoft Reactor and engage with developers live
Ready to get started with AI and the latest technologies? Microsoft Reactor provides events, training, and community resources to help developers, entrepreneurs and startups build on AI technology and more. Join us!
Go back
POSETTE: An Event for Postgres 2026 – Livestream 3
17 June, 2026 | 3:00 PM - 9:00 PM (UTC) Coordinated Universal Time
- Format:
Livestream
Topic: Open Source
Language: English
| 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 |
Already registered and need to cancel? Cancel registration