Ashutosh Bapat
Microsoft
LEARN, CONNECT, BUILD
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
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!
18 June, 2026 | 6:00 AM - 12:00 PM (UTC) Coordinated Universal Time
Topic: Open Source
Language: English
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 Jun 16-18, 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 1 below. In the meantime, you can catch up on last year’s talks at https://aka.ms/posette-playlist.
Learn more about POSETTE 2026 at https://posetteconf.com/2026/
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 |
Speakers
Already registered and need to cancel? Cancel registration
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.