Build a Knowledge Graph in Azure HorizonDB with AI Functions and Apache AGE
Knowledge graphs appear in every AI architecture diagram, every conference keynote and every AI strategy deck. Yet the most common question we hear from customers and engineers alike is: "What does a knowledge graph actually do for me?" That is a fair question, and one worth answering clearly, because most teams already have a knowledge graph problem and do not realize it. The connections your relational tables cannot surface Picture this: five incident tickets land over a week. One says the auth service returned 503s after an API gateway update, which broke checkout. Another says the payment service lost connectivity to fraud detection through a DNS failure. A third says auth got rate-limited by that same API gateway after a config change. Each ticket makes sense on its own. But no one in your postmortem can answer: "What upstream services most commonly trigger failures that reach checkout?" That question requires tracing relationships across tickets, teams, services, and root causes. Your relational tables store the facts. They do not store the connections between them. That is a knowledge graph problem. What becomes queryable once you have a knowledge graph Once you build a graph from those tickets, every node is an entity (a service, a team, an incident) and every edge is a relationship (CAUSED_FAILURE_IN, OPERATES_ON, INVOLVES). The graph does not just store data differently. It makes a new class of questions answerable: What is the most common upstream cause of checkout failures? Which team resolves the most cross-service incidents? Show me every cascading failure chain that touched the payment service in the last 90 days. What is the timeline of incidents involving the same shared service? Each of these questions can be answered with a single Cypher query, without nested subqueries, recursive CTEs, or manually correlating data across spreadsheets. Why graph-augmented RAG needs a knowledge graph first Traditional RAG retrieves chunks of text by vector similarity. It works well when the answer lives in a single document. It falls apart when the answer requires connecting facts across multiple documents. Ask "does this contract conflict with existing obligations?" and vector search returns a relevant clause. But it cannot follow links across regions, obligation types, and counterparties to prove a real conflict. Graph-augmented RAG combines vector search, semantic ranking, and graph traversal into one retrieval pipeline. The graph provides the structural context that vector search alone cannot: the actual chain of cause and effect, not just the five most similar paragraphs. But here is the catch most people miss: you cannot run graph-augmented RAG without a knowledge graph. And building the graph has always been the hard part. That is exactly what the new tutorial solves. Building a knowledge graph in five steps inside Azure HorizonDB We published a hands-on tutorial on Microsoft Learn that takes you from raw incident tickets to a connected, queryable knowledge graph. No external NLP pipelines. No separate graph database. Just SQL. Here is the pipeline: Extract entities and relationships from unstructured text with azure_ai.extract(). The LLM parses services, teams, root causes, and relationship triples in one SQL call. Deduplicate entities with azure_ai.generate() using structured JSON output. "API gateway," "api-gateway," and "the gateway service" collapse into one canonical node. Load into an Apache AGE graph using Cypher MERGE in PL/pgSQL loops. The tutorial builds service nodes, team nodes, incident hub nodes, all six relationship types, and a timeline chain linking incidents chronologically. Query with Cypher traversals. Variable-length path patterns like *1..3 trace cascading failure chains up to three hops deep. Visualize results in the PostgreSQL extension for VS Code, which renders Cypher output as an interactive node-edge graph. The tutorial walks through every SQL statement, explains the tricky parts (like why EXECUTE format() is needed for parameterized Cypher, and how CROSS JOIN LATERAL expands team-service pairs correctly), and shows the exact output at each step. The same pipeline applied to any domain The tutorial uses incident tickets to keep things concrete. But the pipeline applies to any domain: Domain Key Entities Question It Answers Contract intelligence Parties, clauses, obligations Does this new vendor contract conflict with existing obligations? E-commerce product catalog Products, categories, customers, orders What do customers who bought X typically buy next? Fraud detection Accounts, transactions, devices, IP addresses Which accounts are connected through shared devices and circular transfers? Healthcare clinical data Patients, medications, conditions, providers Does this new prescription conflict with existing medications? Codebase dependency analysis Tables, functions, views, triggers If I alter this table, which downstream views and functions break? Supply chain Suppliers, components, facilities Which tier-2 suppliers are single points of failure? Research knowledge base Papers, authors, concepts What evidence chain supports this treatment for condition X? Data lineage and ETL Sources, transformations, dashboards If this source schema changes, which dashboards break? Identity and access management Users, groups, roles, resources Which users have transitive access to production through nested groups? Regulatory compliance Regulations, controls, systems If this regulation changes, which controls need updating? Customer 360 Customers, interactions, campaigns What sequence of touchpoints leads to churn for enterprise accounts? Insurance claims Claimants, policies, events, providers Which claims share overlapping parties or event timelines? M&A due diligence Companies, IP assets, contracts, liabilities What hidden liabilities are linked to this acquisition target? In every case, the shape is the same: azure_ai.extract() discovers the entities, azure_ai.generate() deduplicates them, and AGE stores and traverses the graph. Get started Tutorial: Build a knowledge graph from unstructured text using AI Functions and Apache AGE Knowledge graph enhanced search: Graph-augmented RAG patterns for Azure HorizonDB Solution accelerators: GraphRAG Legal Research Copilot, GraphRAG with Docker and AI Agents We would love to hear what you build. Share your feedback on the PostgreSQL Hub developer forum. Thank you!Last Call: Join Live the PostgreSQL Community at POSETTE: An Event for Postgres 2026 (T‑1 week)
In just one week, the PostgreSQL community gathers again for one of the most anticipated global moments of the year: POSETTE: An Event for Postgres 2026. From June 16–18, this free and fully virtual event brings together PostgreSQL contributors, engineers, architects, and practitioners across 4 livestreams, 44 talks, and 50 speakers. But you might be wondering, why should I participate in POSETTE during the livestreams? Why join it live? Explore the schedule and choose your livestreams on the official site: Join POSETTE: An Event for Postgres 2026 Why joining live makes all the difference Yes, every talk will be available afterward. But the real value of POSETTE: An Event for Postgres 2026 happens while it is unfolding live. Be part of the virtual hallway track Participating live gives you access to the #posetteconf Discord channel, where attendees and speakers interact in real time, asking questions, sharing perspectives, and comparing approaches. This is where conversations extend beyond the talks and where ideas are challenged and refined collectively. Learn and validate your thinking in real time POSETTE is not just about listening. It is about sharpening how you think about PostgreSQL: Are you partitioning effectively? Are you approaching replication with the right mental model? Are your performance strategies aligned with how PostgreSQL actually behaves? Joining live means you can test those ideas immediately with people who build and run PostgreSQL systems at scale. Connect with practitioners solving the same problems A recurring insight from POSETTE participants is how often they discover others facing the same challenges, whether around scaling, performance, or operability. That shared experience often leads to the most valuable takeaways: not just what works, but why. What makes this year’s speakers worth your time POSETTE: An Event for Postgres 2026 brings together a diverse set of voices: PostgreSQL core contributors Engineers and architects working on production systems Specialists in performance, replication, and security Developers shaping how PostgreSQL is used in modern applications Azure Database for PostgreSQL and Azure HorizonDB engineers and experts These are practitioners who have built, debugged, and scaled real systems, and who are ready to share what they learned. Learn directly from the POSETTE speakers who are shaping PostgreSQL Bruce Momjian: understanding PostgreSQL from the inside out Read Bruce Momjian’s interview Bruce Momjian, a co-founder and core member of the PostgreSQL Global Development Group, has spent decades helping people understand how PostgreSQL really works. His session on the write-ahead log (WAL) reflects that same focus: taking something fundamental but often misunderstood and making it approachable. If you want to move beyond “using” PostgreSQL and start truly understanding its internals, how durability, recovery, and replication actually function, this is a rare opportunity to learn directly from someone who has helped build the system. Chris Ellis: making PostgreSQL practical for developers Read Chris Ellis’s interview Chris Ellis focuses on how to turn PostgreSQL’s extensive feature set into practical design choices. His session on design patterns highlights a reality many developers face: PostgreSQL offers powerful primitives, but knowing how to combine them effectively is what makes the difference. His work consistently centers on simplifying application architecture by using the database well, rather than pushing complexity into application code. Chun Lin Goh: understanding performance in real environments Read Chun Lin Goh’s interview Chun Lin Goh brings a cloud architecture and observability perspective to PostgreSQL performance. His session on performance degradation in burstable environments shows how the database behaves under real-world infrastructure constraints. This is especially relevant if you run PostgreSQL in cloud environments, where system behaviour, not just query design,can have a major impact. Derk van Veen: lessons from real-world partitioning Read Derk van Veen’s interview Derk van Veen’s work is grounded in hands-on experience operating PostgreSQL at scale. His partitioning session focuses not just on how to do things right, but also on what can go wrong,and why. Partitioning decisions often look simple early on but have long-term consequences. Learning from real mistakes and trade-offs is what makes these sessions so valuable. Hari Kiran: thinking deeply about replication Read Hari Kiran’s interview Hari Kiran’s session explores logical decoding and replication, two foundational aspects of how PostgreSQL systems scale and integrate with other systems. If your work involves distributed systems, data pipelines, or event-driven architectures, understanding these mechanics is essential. Jimmy Angelakos: uncovering subtle behavior Read Jimmy Angelakos’s interview Jimmy Angelakos focuses on practical, often overlooked aspects of PostgreSQL behavior. His session on NOTIFY highlights how features that seem simple on the surface can introduce complexity in real systems. These are exactly the kinds of nuances that can save hours or days of debugging in production. Sakshi Nasha: securing PostgreSQL for production Read Sakshi Nasha’s interview Sakshi Nasha’s work emphasizes security and production readiness. Her session on securing PostgreSQL reflects a broader shift: as PostgreSQL becomes central to more systems, security needs to be built in from the start. Her perspective is especially relevant for teams moving from development environments into production systems. Taiob Ali: connecting community and real-world usage Read Taiob Ali’s interview Taiob Ali brings a strong community-driven perspective to PostgreSQL, shaped by experience as both a practitioner and an advocate. Sessions like his often help bridge the gap between concepts and how PostgreSQL is actually used across different teams and environments. Xuneng Zhou: an independent perspective from the ecosystem Read Xuneng Zhou’s interview As an independent PostgreSQL hacker, Xuneng Zhou represents a perspective deeply rooted in the open source ecosystem itself. That viewpoint often brings a focus on fundamentals, experimentation, and how PostgreSQL evolves over time, valuable context for anyone who wants to understand not just where PostgreSQL is today, but where it is heading. This is more than a conference POSETTE: An Event for Postgres 2026 is a shared moment for the PostgreSQL community. It is an opportunity to: Learn from practitioners and contributors Challenge assumptions and refine your thinking Understand where PostgreSQL is heading next Stepping into the livestream is not just about attending talks, it is about participating in that moment. Your next step: join live If PostgreSQL is part of your work, or becoming central to it, the best way to experience POSETTE: An Event for Postgres 2026 is live. Pick the sessions that matter to you. Add the livestreams to your calendar. Join the discussion as it happens. Start here: Check out the POSETTE schedule to figure out which livestreams & which talks are for you. For any other answer you may still have, don't forget to take a look at the Ultimate Guide to POSETTE: An Event for Postgres 2026 See you live at POSETTE Whether you are exploring PostgreSQL internals, building modern applications, or scaling production systems, POSETTE: An Event for Postgres 2026 is where those conversations come together. See you at POSETTE on 16-18 June 2026.Introducing Azure HorizonDB - PostgreSQL
Call AI models directly from SQL, build durable vector pipelines inside the database, and deliver high-accuracy similarity search at massive scale with DiskANN and AI re-ranking, all without leaving PostgreSQL. Debug and optimize queries faster with the Azure HorizonDB VS Code extension. Visualize execution plans, let Copilot generate fixes, and clone production data to test environments in seconds. Charles Feddersen, PostgreSQL Partner Director PM, shares how to put all of it to work on Azure. Same hardware, same zone, same PostgreSQL version. 4,200 TPS self-managed vs. 11,000+ on Azure HorizonDB. The separation of storage and compute layers make the difference. See how it works. Chunking. Embeddings. Vector storage. All running as a durable background task inside PostgreSQL with AI Pipelines in Azure HorizonDB, no external orchestration needed. Check it out. Visual query execution plans. Copilot-generated fixes. The Azure HorizonDB VS Code extension brings all of it into the editor. Get it now. QUICK LINKS: 00:00 — Azure HorizonDB features 00:57 — Open-source PostgreSQL 02:24 — How it works 03:37 — Performance 04:51 — Enterprise-ready security 05:34 — Memory & storage work together 06:29 — AI Model Management + AI Functions 08:24 — AI Pipelines 09:50 — DiskANN + AI Re-ranking 10:50 — VS Code Extension + Data Cloning 12:31 — Wrap up Link References Check out our blog at https://aka.ms/azurepostgresblog Unfamiliar with Microsoft Mechanics? As Microsoft’s official video series for IT, you can watch and share valuable content and demos of current and upcoming tech from the people who build it at Microsoft. Subscribe to our YouTube: https://www.youtube.com/c/MicrosoftMechanicsSeries Talk with other IT Pros, join us on the Microsoft Tech Community: https://techcommunity.microsoft.com/t5/microsoft-mechanics-blog/bg-p/MicrosoftMechanicsBlog Watch or listen from anywhere, subscribe to our podcast: https://microsoftmechanics.libsyn.com/podcast Keep getting this insider knowledge, join us on social: Follow us on Twitter: https://twitter.com/MSFTMechanics Share knowledge on LinkedIn: https://www.linkedin.com/company/microsoft-mechanics/ Enjoy us on Instagram: https://www.instagram.com/msftmechanics/ Loosen up with us on TikTok: https://www.tiktok.com/@msftmechanics Video Transcript: - The Postgres you know and love is now even more supercharged on Azure with the latest platform optimizations and AI for enterprise apps all made possible with the new cloud-native Postgres service, Azure HorizonDB. Now, we’ll go deep on its ultra fast performance at high scale, the built-in resiliency across different availability zones, along with major new built-in AI-centric features, leveraging DiskANN, as well as integrated AI model management, where you can provision models or bring your own from Microsoft Foundry, plus a built-in AI pipeline that automatically chunks and processes data in real time as it’s ingested into the database. And finally, a brand new VS code extension with AI-powered query development and debugging as you build your apps and more. And today I’m joined once again by Charles Feddersen who leads the Postgres efforts on Azure. Welcome back to the show. - Thanks Jeremy, it’s good to be back and we’ve got a lot to get through today. - Yeah, so the new HorizonDB service in Azure is our newest managed Postgres service where we also have Azure database for Postgres, and we’re actively making deep contributions in the Postgres project as well. - Yeah, so Microsoft has been actively supporting Postgres on Azure for about nine years now, and our approach has always been to keep the Postgres, you know, and love for its portability and ecosystem and make Azure the best place to run your Postgres workloads. You know, and as you mentioned, we are a major contributor to open source Postgres. In Postgres 19, Microsoft Committers modified over 64,000 lines of code, which represents about 8% of all changes in this version. And we made about 340 commits. These improvements cover both new functionality and also improvements based on our own learnings of running Postgres at a massive scale on Azure. We also host the largest virtual Postgres community conference in the world called POSETTE, which is now in its fifth year. Because we understand the core Postgres engine so well, it’s not unusual for our core committers on the team to work with our customers to help debug and resolve issues that they might be having as well. - Right, and I remember last time you were on, we discussed how you were shipping major versions of Postgres on Azure within weeks of their releases. - Yeah, and now we’ve effectively eliminated that delay. There is now zero cloud lag in waiting to leverage the latest features when using Postgres on Azure. We ship the new major version on the same day in Azure. - So that’s a big deal, there’s no lag, same day access. Why don’t we move back though to our newest managed Postgres service HorizonDB. How does that then change the game for anyone who’s running Postgres services now on Azure? - Yeah, so HorizonDB brings cloud scale performance built-in resilience and AI ready capabilities to Postgres without changing how you build or run your apps. How this works is we’ve completely decoupled compute and storage to improve performance, scale and availability. At the compute layer, it runs the Postgres engine, fully compatible so existing apps and tools just work. At the storage layer, we built a new and highly optimized log service for transactions where we can sustain a commit latency of typically under one millisecond. That log service is paired to a new shared storage platform, which natively stores data across availability zones for resilient storage by default. We can attach multiple read replicas to the storage and the primary can fail over to any of these replicas in less than five seconds, in the event of an outage. This gives you read scale without replication latency. Ultimately, HorizonDB lets you run any Postgres workload from new AI apps to large scale enterprise systems with the performance, resilience and scale of Azure already built in. - All right, so you said performance. Let’s dig deeper there. Everybody loves a performance story, so can you prove it? - Yeah, so one of the big challenges with self-managed Postgres is that enabling high availability, especially across cloud zones, often comes with a performance cost. With HorizonDB, we introduced a new quorum commit protocol that let you durably commit across zones before flushing to disk, so you get both resilience and high performance. Now to show this in action, I’ve got a split screen, HorizonDB on the right and self-managed Postgres on the left. This is the same Postgres version on the same hardware with the same high availability setup in the same Azure region. And I’ll kick both off and then go ahead and let them run. And as you can see clearly HorizonDB is delivering about three times more transactions per second. This gain comes directly from the storage architecture, and now that it’s finished, we can see that self-managed Postgres on the left delivered over 4,200 transactions per second. And HorizonDB had more than 11,000 with much lower latency. Performance was a core design principle for HorizonDB from the beginning, and it’s something that you’ll see directly in your applications. - Okay, so performance is ultra fast, and we know this is built for both enterprises and developers, and we know enterprises love security. So what’s different there? - Yeah, so security of course is foundational. It spans everything from network isolation and identity to data protection. Just like performance, it’s been a core focus from day one. And we’re building on the proven enterprise capabilities of Azure database for Postgres to deliver it out of the box like Entra ID integration, where you can enable identity-based access, so users connect securely without managing passwords or private endpoints to lock down access. So the database is only reachable over your private network with no public exposure and of course encryption at rest where data is automatically encrypted on the disk. All of this is available from day one, so you get strong enterprise ready security without any extra setup. - Okay, and bringing this back to our developers who are watching the built-in AI centric features with HorizonDB now also make it easier to build AI apps. - Yeah, and this is an area that we’re really leaning into. Postgres was already popular and chat with your data use cases accelerated that adoption because it natively supports vectors for similarity search. Our focus is on making intelligent retrieval and generative AI work on a massive scale with high accuracy and efficiency. To do that, we’ve rethought how memory and storage work together in the database so that more IO traffic moves to disk letting you take advantage of much larger storage capacity using Microsoft’s disk accelerated nearest neighbor or DiskANN technology. This quantize a vector-based graph in memory and maps it to a full precision graph stored on disk, which significantly reduces memory requirements while still delivering fast higher quality similarity search across your data. - And speaking of generative AI responses, we’ve also made it easier for the database to work directly with AI models. - Yeah, we have, and this starts with AI model management, which automatically registers a set of models with your instance of HorizonDB. It’s really simple. So here’s my HorizonDB, and I’ll just select the enable managed models then confirm. And what this does behind the scenes is it automatically registers a few AI models for use. Once the provisioning is complete, you can see the AI model management blade in the portal with the GPT, text embedding and re-ranking models listed. And you can also bring your own models where you register them through the database directly. - So now you can use models effectively with Postgres without extra manual provisioning configuration. So, how would you interact with them? - Yeah, this is where AI functions come in. These are a set of SQL functions that you interact directly with AI models. The Azure AI extension in HorizonDB provides functions that you can invoke using SQL to leverage AI models. So let me show you a couple. For example, you can use the generate function to produce a response from a prompt. In this case, I’ll say summarize the following customer reviews in two to three sentences, and then I’ll run it and you can see the response is generated as a SQL result that I could use in my app. Alternatively, the extract function is designed to pull specific entities from unstructured text into a structured form that you can then store and query. You can see here that I’m going to use an array to ask for the main product features along with the customer sentiment from my database. Now, we’ll let that run for a moment and we can see the response of producers for each item in the catalog. - And this is just one scenario that you showed with querying, but I can imagine another case where you might say, use data transformation where the results are written back into the database. - Yeah, absolutely. And when you do that, obviously the retrieval time for those results stored in the database is incredibly fast and you’re saving on your tokens as well. - That’s really great to see. So another challenge that we hear a lot of times is around building and maintaining AI pipeline. So we’re making that easier too. - So this is where AI pipelines in HorizonDB extend AI model management and AI functions even further. Today, most generative AI apps rebuild the same steps, chunking, creating embeddings, backfilling data, often in fragile external pipelines. With AI pipelines, all of this is built directly into Postgres. So you can see here that I’ve created a pipeline using the create pipeline function in the AI extension. This chunks the data in a database in real time as it’s added. It will then create embeddings for those chunks using the embedding model that the AI model management enabled for us. And these are ultimately stored in a table. So I can then go ahead and run this, and then if I count the records in the output table, you can see that it’s increasing. And this is all happening asynchronously in the background so that it’s not blocking or really having any real performance impact on my transactional workload. But the best thing about these pipelines is that they’re durable. And this means that I could pause it. And you can see here that the row count stops increasing, even if the workload continues and I can resume it, think of it as a reliable background task. And if my server fails over, it’s no problem, the AI pipeline fails over as well and it just keeps running. - So all that pipeline complexity then just moves into the database and kind of reduces the complexity and runs reliably. - Exactly, and building on this, we can now also use the rank function to re-rank search results with an AI model. Earlier I talked about how DiskANN improved similarity search, but that’s just the first step. With rank, we can apply a model like Cohere to refine the top results and improve overall relevance. Let me show you, I’ve got two identical queries here. One just uses an index and the other wraps the same query in our rank function to improve the relevance of results. If I run the first query for the headphones with the highest playtime and good calling, you can see the results seem pretty good. And these aren’t bad with a few showing around 40 hours. But when I run the rank query that applies the AI ranking model, the top most results are definitely more relevant to my search. Here, there are headphones with 60 or more hours, and the top ranked model has a hundred. - And this is really powerful. So you basically started out with fast similarity search, then used AI to make the results even more relevant. But why don’t we move beyond the database itself and look at what we’ve done then to help with the building experience of Postgres workloads on HorizonDB? - Sure, and this is one of my favorite additions. We’ve built a new VS code extension that brings familiar Postgres tools into a modern AI powered experience. As someone who spent years working in database tools, this is something that I really wish I’d had. It makes debugging and development a lot more easy. So here we’re in VS code and on the left you can see I’m using the Postgres extension. Now this works with any Postgres, but when you connect to Postgres on Azure, you get even deeper integration. So let’s look at an Azure server, and if I right click, you can see a number of server management features like network configuration, backups, and even start stop built in with a single click. And if I right click on tables, one of the most recent additions is object properties. But now let’s run a query. This is a little slower than we’d expect. So I open the new visual query execution plans to debug. It’s easy to identify the Inefficient query operator, and I can click on that to debug further. But the best part is that Copilot can fix it for me. Here, I’ll just click on the Copilot button in the query plan and it gets to work. The Copilot generates the fix for me, and it’s really that simple. Now I want to test this fix in a non-prod server, and that’s easy to. For that, I’ll show you a first look at the new built-in data cloning. I’ll go back up to the server and right click and I can clone it with all my data. And that just takes a moment to validate my solution. - And that’s a real shift. You got the same familiar Postgres experience, but now with AI and platform capabilities that really improve how you build and run apps. So what’s next? - Yeah, so we’ve covered a lot today, but this is just the start. We’re continuing to push the boundaries of what you can do with Postgres on Azure. So here’s a lot more coming. - So what’s the best way then for everyone watching to get started with Azure HorizonDB? - Yeah, so, you know, you can go try it for yourself. It’s in preview now and it’s easy to get started with everything that I demoed. The VS code extension is available in the VS code marketplace. And of course, to stay current, check out our blog at aka.ms/azurepostgresblog. - Thanks so much for joining us today, Charles, and of course, keep checking back to Microsoft Mechanics for the latest tech updates, and we’ll see you again next time.Introducing Durable Functions in PostgreSQL
By Abe Omorogbe, Senior PM | Pino De Candia, Principal Software Engineer | TJ Green, Principal Software Engineer Postgres will happily store your data, run your queries, and scale with you for years. But the moment you need to do more with that data, such as running multi-step transformation, scheduling nightly rollups, generating embeddings or waiting on an approval, you hit a wall. Postgres has no built-in way to run long-lived, fault-tolerant work. That's why we built pg_durable, a new open-source PostgreSQL extension that brings durable execution directly into the database. With pg_durable, Postgres doesn’t just store your data, it runs long-lived, fault-tolerant workflows on it, with built-in retries, parallelism, scheduling, and recovery. Instead of stitching together PL/pgSQL functions or building external orchestration systems, you can now define and run resilient workflows entirely in your database, backed by Postgres' durability and high availability. And on Azure HorizonDB, pg_durable also powers AI pipelines, enabling production-ready data and AI workflows, end-to-end, right inside the database. In this post, we'll cover: The hidden trap: blocking background work What pg_durable is and the DSL that drives it How this engine powers AI pipelines on HorizonDB Sample patterns worth exploring Getting started on HorizonDB, on your laptop, and in VS Code 🚀 Want to try it out? pg_durable ships in Azure HorizonDB, Microsoft's new PostgreSQL cloud service. The HorizonDB Preview is the fastest way to try pg_durable and AI pipelines together. Get started in HorizonDB → pg_durable visualization The hidden trap: blocking background work Most Postgres teams eventually reach a point where they need to run critical tasks on their data: transformations, nightly aggregations, database maintenance workflows, embedding jobs, or multi-step business processes. So, they do the natural thing and try to keep that work inside Postgres. They end up on a journey of increasing complexity and maintenance burden. First, just run the task as a function in your database You cram the whole workflow into one PL/pgSQL function: loop, transform, call APIs, write results, return. It looks simple until you have to run it in production. One connection stays tied up the whole time. Everything runs inside one big transaction, with long locks and no visibility into partial progress. If the connection drops or the database restarts, the whole run is gone. No per-step retries. No parallelism. No scheduling. No clean way to pause for human input. When it fails, you move it outside You push the workflow into an external service: a job queue, polling workers, state tables, step coordination, retry logic, crash-recovery sweeps, and cleanup jobs. What started as a few background tasks turns into a full distributed system. Before you’ve even touched the business logic, you’re building and operating infrastructure just to coordinate work that’s still fundamentally tied to your data. Both paths are workarounds for the same missing primitive: durable, asynchronous background work that lives where your data lives. That's the gap pg_durable fills. What pg_durable actually is pg_durable is a Postgres extension that consists of a DSL (Domain specific language) and the duroxide runtime hosted in a Postgres background worker. You describe a workflow as a small SQL expression, call df.start(...), and get an instance ID back immediately. The work runs off to the side in a background worker, so it never blocks your connection or transaction, and you can check progress later with df.status() and df.result(). The execution state lives in Postgres, which means it benefits from the database’s durability, HA, backups, and recovery. Additionally, the workflow definition does not have to live in the database: your application can send it to df.start(...) over a regular Postgres connection. 2: pg_durable orchestration of worker and schema Because execution is asynchronous, pg_durable automatically breaks a workflow into discrete steps. Each step runs in its own session and transaction, commits its progress, and hands off to the next instead of keeping one giant transaction open. Steps are checkpointed in Postgres and recovered by deterministic replay, so workflows survive crashes, restarts, and failovers and resume where they left off. If a step fails, only that step retries. The whole thing is expressed through a tiny DSL of composable operators: Operator Meaning ~> Sequential. run this, then that & Parallel. fan out, wait for all | Race. fan out, take the first to finish ?> / !> Conditional. if / else @> Loop. repeat durably, survive restarts |=> Capture a step's result into a variable (reuse with $) Advanced Functions df.if() Conditional branch df.loop() Repeat statements df.join() Execute in parallel, wait for all df.http() To call an allowlisted endpoint df.wait_for_schedule() For cron-style timing df.wait_for_signal() Pause for an external event Read more about all operators and functions in pg_durable Without pg_durable vs. with pg_durable The hand-rolled version of "run three aggregations in parallel, then refresh a dashboard with retries and crash recovery" usually means 300+ lines of queue tables, polling workers, state-machine rows, per-step retry logic, crash-recovery sweeps, and cleanup jobs. Plus, the runbook to operate it. The pg_durable version: SELECT df.start( 'SELECT count(*) FROM users' & 'SELECT count(*) FROM orders' & 'SELECT sum(amount) FROM orders' ~> 'REFRESH MATERIALIZED VIEW metrics', 'refresh-dashboard' ); You write the SQL. pg_durable owns the queue, the state, the coordination, the retries, and the crash recovery. Two ways to use pg_durable 1: Use pg_durable directly (works on Azure HorizonDB or any Postgres 17) Enable it and start orchestrating: CREATE EXTENSION pg_durable; SELECT df.start($$ SELECT 'Hello, durable world!' AS message $$); -- returns an instance ID immediately; the worker runs it asynchronously From there you compose: sequential pipelines, conditional branches, races for timeout-or-result, variable passing between steps, human-in-the-loop approvals, scheduled maintenance all in SQL, close to the data, with no new infrastructure. This is the "just use Postgres" answer to a problem teams usually solve by leaving Postgres. Because it's open source under the permissive PostgreSQL License, you can clone the repo and run it on your laptop, your server, or any cloud. 2: AI pipelines (HorizonDB capability) On HorizonDB, pg_durable becomes the foundation for something even more approachable: a managed, declarative AI pipeline surface in the azure_ai extension. pg_durable gives you the durable execution engine, while the ai.* API gives you an AI-shaped model of sources, steps, sinks, and triggers that compile into a durable graph. Traditional app-tier embedding pipelines fail in predictable ways: a transient API error mid-batch with no shared checkpoint, a worker that crashes after writing chunks but before marking the parent row processed, no clean way to re-embed just the rows that changed. Move that logic into HorizonDB and the source, the steps, the sink, and the run history are all SQL, protected by the same transactions, backups, and PITR (point-in-time recovery) your data already has. A complete chunk → embed AI pipeline is one definition: SELECT ai.create_pipeline( name => 'ai_pipeline', source => ai.table_source(table_name => 'documents_ai_pipeline'), steps => ARRAY[ ai.chunk(input => 'content'), ai.embed(model => 'default-embedding', input => 'chunk_text', dimensions => 1536) ], trigger => 'on_change', sink => ai.table_sink('documents_ai_pipeline_output') ); SELECT ai.run('ai_pipeline'); Each AI step becomes a durable node, so if ai.embed() fails, ai.chunk() doesn’t run again. And with trigger => 'on_change', the pipeline runs automatically as rows change, embedding only what’s new. Add a DiskANN index on the resulting table, and you have production-ready vector search end to end, entirely inside the database. Where pg_durable fits and where it doesn't If you've used external orchestrators such as Temporal or Airflow, your first reaction is probably: why would I put control flow in my database? Fair question. pg_durable isn't trying to be a universal orchestrator. Reach for pg_durable when the workflow is tightly coupled to Postgres state. The rows it reads and writes live in the same database, it benefits from the database's own durability, backups, and PITR, and you'd rather not stand up a separate system to coordinate work that never leaves the data tier. Think: embedding pipelines, ETL jobs, scheduled maintenance, and queue-style background jobs. Reach for a dedicated orchestrator when the workflow's center of gravity is outside Postgres, fanning across heterogeneous services, or running arbitrary application logic that does not map cleanly to SQL steps, branching, loops, or HTTP calls. Get started On Azure HorizonDB CREATE EXTENSION IF NOT EXISTS pg_durable; -- Execute a simple SQL query as a durable function SELECT df.start($$ SELECT 'Hello, durable world!' AS message $$); -- Returns: a1b2c3d4 (8-character instance ID) -- Get result of a specific instance SELECT df.result(<ID>); That's it: submit, walk away, inspect. Read the documentation for more details. In VS Code, with the PostgreSQL extension A dense one-liner of ~>, &, and |=> is precise once it clicks, but the learning curve is real so flatten it with tooling. Install the PostgreSQL extension for VS Code from the Marketplace: Connect to HorizonDB or your local Postgres directly from the extension Let Copilot write the SQL. The pg-durable-sql skill turns a plain-English description ("every night, archive orders older than 90 days") into correct pg_durable syntax. Run it and watch it. The extension renders pg_durable workflows and azure_ai pipelines as live graphs, definition and each run, so you can see every step, its timing, and exactly where a failure happened. Authoring, execution, run visualization, and inspection in one window and the same tooling works against any Postgres, not just HorizonDB. On your laptop Prefer to run it yourself? Clone microsoft/pg_durable, use the Codespace prebuild or VS Code Dev Container, and add the extension on any Postgres 17. Sample patterns worth exploring The scenario guide has a full catalog of scenarios; however, these are the three I would start with. ETL Pipeline: a multi-step data transformation where each step must be completed before the next begins. Failures should stop the pipeline. SELECT df.start( 'DELETE FROM target WHERE loaded_at < now() - interval ''7 days''' -- Step 1: Cleanup old ~> 'UPDATE staging SET processed_at = now() WHERE processed_at IS NULL' -- Step 2: Mark staging ~> 'INSERT INTO target (data, source_id) SELECT data, source_id FROM staging WHERE processed_at IS NOT NULL', -- Step 3: Load 'etl-pipeline' -- Label for easy identification ); If the database restarts mid-backfill, it picks up from the last checkpointed batch, not row zero. See full example Scheduled Data Sync: poll an external API or run a job on a schedule (hourly, daily, every 30 minutes). The job should run forever and survive restarts. (See full example): -- Scheduled sync: fetch data every 30 minutes (runs forever) SELECT df.start( @> ( -- @> creates an eternal loop -- Fetch from external API (df.http( 'https://httpbingo.org/json', 'GET' ) |=> 'response') -- Store the response ~> 'INSERT INTO external_data_sync (data) VALUES ($response::jsonb)' -- Wait for next scheduled run ~> df.wait_for_schedule('*/30 * * * *') -- Cron: every 30 minutes ), 'scheduled-data-sync' ); Human-in-the-loop approval: auto-apply routine changes, pause the risky ones until a person signals approval (See full example): SELECT df.start( 'SELECT amount > 10000 AS needs_review FROM invoices WHERE id = 42' |=> 'risky' ?> ( df.wait_for_signal('invoice-42') ~> 'UPDATE invoices SET status = ''paid'' WHERE id = 42' ) !> 'UPDATE invoices SET status = ''paid'' WHERE id = 42', 'invoice-approval' ); The workflow simply waits minutes or days until a reviewer releases it with the matching signal, then resumes. The community is already running with it pg_durable launched as open source and the community is already kicking the tires. The project was a top article on Hacker News on launch day and 1.7K stars on GitHub within its first few days of initial launch. Also Franck Pachot (PostgreSQL community veteran) published an independent walkthrough, Getting Started with pg_durable: durable workflows inside PostgreSQL within days of release. The repo is actively developed, and the maintainers are reading every issue and PR. If you want improvements in our DSL ergonomics, say so. If you want an operator that doesn't exist yet, open an issue. If you've got a scenario we haven't covered, send a PR. The syntax, the docs, and the rough edges all get better when people who run Postgres in production push back. So, clone it, and build something real. If you find rough edges, open an issue or send a PR at microsoft/pg_durable. We think you'll be surprised by how much it can take. Learn more pg_durable on GitHub Durable Functions on HorizonDB AI pipelines on HorizonDBSELECT * FROM build2026_sessions WHERE postgres = true;
Microsoft Build 2026 is around the corner, and this year it’s shaping up to be a big one for PostgreSQL experts and enthusiasts. If you’re a developer working with Postgres, or just love exploring new database technology, there's plenty to get excited about. Microsoft’s new cloud-first evolution of PostgreSQL, Azure HorizonDB, alongside sessions featuring Azure Database for PostgreSQL, will highlight how Postgres is powering the next wave of AI-driven applications. A new horizon in Postgres Build 2026 arrives at a time when the role of databases in modern apps is evolving rapidly. From enabling AI model integration to scaling seamlessly across the cloud, PostgreSQL developers today are dealing with more complex demands than ever. That’s why Azure HorizonDB – Microsoft’s new cloud-native PostgreSQL service – is generating so much buzz ahead of Build. What is Azure HorizonDB? In short, it’s a reimagined version of PostgreSQL designed for cloud-scale performance and AI-era workloads. Azure HorizonDB, introduces a distributed architecture that decouples compute and storage, delivering sub-millisecond latencies and three times the throughput of self-managed Postgres at massive scale. It aims to preserve Postgres’s beloved features and SQL ecosystem while adding next-generation capabilities: built-in vector indexing for high-speed AI/ML retrieval, the ability to run AI models and vector operations directly in the database, and multi-zone replication for resilience. For Postgres developers, this means less time stitching together external data stores or machine learning services – and more time building powerful apps on a unified platform that’s both familiar and built for the future. The bottom line: Microsoft Build 2026 is an ideal opportunity for developers to see Azure HorizonDB in action, learn best practices for modern PostgreSQL architectures, and understand how to leverage Postgres in new scenarios like generative AI and multi-agent applications. Read on for a rundown of sessions covering these topics, complete with what you’ll learn from each one. Top sessions for PostgreSQL databases on Azure Below are key sessions tailored for PostgreSQL users and those interested in Azure HorizonDB, with session types and highlights of what you’ll gain by attending. 🎤 Breakout: From Rows to Reasoning: Designing Databases for AI Apps and Agents (BRK223, 45 min, in-person and digital options) Discover how to architect databases that can power tomorrow’s intelligent applications. This technical breakout will show how AI-ready databases can move beyond plain transactions. You’ll see live demos of integrating transactional, analytical, and vector data in one unified platform, with Azure’s new database capabilities, including Azure HorizonDB. Learn how to simplify your stack by eliminating separate analytics engines or vector stores. The session will highlight patterns that reduce data movement and latency so your apps can efficiently reason over live data with minimal complexity. 🧪 Hands-on lab: Create Advanced Postgres-Powered Agentic Apps with Azure HorizonDB (LAB511, 75 min, in person and digital options) Roll up your sleeves and get hands-on building a real multi-agent AI application with Postgres. In this advanced lab, you’ll create a production-ready AI agent powered by Azure HorizonDB as an all-in-one data, search, and intelligence layer. Experiment with retrieval-augmented generation (RAG) by combining semantic vector search (DiskANN) with traditional SQL queries right inside the database. Implement hybrid search and agent workflows without resorting to external vector databases or glue code – thanks to HorizonDB’s built-in vector indexing and in-database AI model capabilities. This lab is perfect for developers who want to experience how HorizonDB can simplify your stack and boost performance for AI-driven apps. Multiple hands-on labs are offered to suite your schedule. 💻 Demo: Simplify App Dev with Cloud-Native PostgreSQL in Azure HorizonDB (DEM364, 25 min, in-person and digital options) See how to cut your development time and complexity with built-in AI and search features in Postgres. This fast-paced demo shows how Azure HorizonDB helps eliminate the need for separate search engines and AI services by pulling those capabilities straight into PostgreSQL. Expect to learn how you can run hybrid vector + keyword queries using SQL, integrate AI models directly from within the database, and apply full-text search (BM25) and semantic ranking to get smarter results. If you’re eager to deliver intelligent apps faster, with fewer moving parts, this session will show how HorizonDB simplifies your architecture without sacrificing performance. ⚡Lightning Talk: Cloud-Native PostgreSQL, Rebuilt for Scale: Azure HorizonDB (LTG413, 15 min, in-person only) Get a rapid-fire introduction to the architecture behind HorizonDB’s eye-popping performance. This short talk dives into how HorizonDB re-architects core PostgreSQL to deliver effortless scale out and blazing speed. Learn how decoupled compute and storage, predictive caching, and multi-region replication combine to achieve sub-millisecond query latencies and 3× higher throughput than standard Postgres. If you care about performance tuning and high-scale database design, don’t miss this quick primer on the tech under HorizonDB’s hood. 👥 Interactive Table Talk: Scaling PostgreSQL for AI Apps: Patterns and Tradeoffs (TT622, 45 min, in-person only) Bring your questions and ideas to this collaborative discussion. In this open round-table session with community and Microsoft experts, you’ll explore architecture patterns for scaling PostgreSQL to meet the demands of agent-based and AI-driven applications. Discuss real-world strategies for handling vector embeddings in Postgres, unifying relational and document data, integrating with AI models, and more. Compare the trade-offs between different scaling approaches – from monolithic to microservices, sharding strategies, and new technologies like HorizonDB – and learn where each design shines or struggles in production. Come ready to share your experiences and learn from others in the room. ▶️ On-Demand: Smarter PostgreSQL Migrations to Power Modern, Intelligent Apps (OD822, 30 min, digital only) Planning to migrate to Postgres or move your databases to Azure? Start here. This on-demand session focuses on new tools and proven strategies to migrate large-scale databases to Azure Database for PostgreSQL quickly and safely. You’ll see AI-assisted migration tools in action that minimize downtime and risk when moving terabytes of data. Just as importantly, you’ll learn how migrating to Azure unlocks advanced capabilities – from boosted performance and enhanced security to AI-ready features – helping you turn your newly migrated data into intelligent apps and services. On-demand session will be available to stream on the first day of Build. Meet the team: PostgreSQL expert meetups If you’re attending Build in person, stop by the Expert Meetup (EMU) area and head to the relational cloud databases booth. This is your chance to talk directly with the engineers and product teams behind PostgreSQL on Azure. Bring your questions about architecture decisions, scaling patterns, migrations, AI workloads, or anything else on your mind. Whether you want to sanity-check a design, dig deeper into something you saw in a session, or give direct feedback, the EMU space is designed for exactly that convo. How to get the most out of Build (and what to do next) With so much great content lined up, how do you decide where to start? It really depends on what you’re most excited about: Curious about AI and agentic apps: Start with From Rows to Reasoning, then go deeper with the Simplify App Dev with HorizonDB demo or get hands-on at the Azure HorizonDB labs to see how these ideas work in practice. Performance and scale are your focus: The short Lightning Talk on HorizonDB’s cloud-native architecture and the Table Talk on scaling Postgres will both provide unique insights and pro tips for running Postgres at massive scale. Planning a migration to PostgreSQL on Azure: Watch the Smarter PostgreSQL Migrations on-demand session to learn how to migrate large workloads with minimal downtime, and the benefits you can unlock after moving to Azure. Looking for real answers to your specific questions: Make time for the PostgreSQL Expert Meetup area to connect directly with the team. No matter which sessions you choose, Build 2026 promises to be an exciting event for the PostgreSQL developer community. Browse the session catalog, save the sessions that match your interests, and we’ll see you at Build.Introducing PostgreSQL Hub for Azure Developers
PostgreSQL Hub for Azure Developers is live. A centralized destination with curated sample apps, tutorials, videos, structured learning pathways, and a community space to connect with Microsoft and ecosystem experts. Whether you're building your first Postgres app or scaling AI agents on Azure, this hub has you covered.Ultimate Guide to POSETTE: An Event for Postgres, 2026 edition
POSETTE: An Event for Postgres 2026 is back for its 5th year: free, virtual, and unapologetically all about Postgres. No travel budget required and no jet lag involved. Just your laptop, a decent internet connection, and curiosity. This year the POSETTE 2026 schedule has 4 livestreams (16-18 June) with 44 talks at ~25 minutes each—covering everything from query performance and partitioning to Postgres 19 features, extensions, and use cases. Which is awesome but also a bit of work to figure out which talks are for you. Hence this ultimate guide post. Every talk will land on YouTube afterward (un-gated, of course) so if you miss anything you care about, you can watch it later. But if you can catch a livestream in June, do it. That’s when the “virtual hallway track” happens on Discord—where you can ask the POSETTE speakers questions and compare notes with other attendees. Meeting other attendees who have the same weird Postgres problems you do can be reassuring somehow. And yes, there will be swag. This guide is your cheat sheet: I’ve categorized and tagged all 44 talks so you don’t have to read 44 abstracts back-to-back. In this post you'll get: “By the numbers” summary Map of the 44 talks 2 Keynote sessions 23 Postgres core talks 11 Postgres ecosystem talks 8 Azure Database talks Why participate on the virtual hallway track on Discord A big thank you to our amazing speakers Join us for POSETTE 2026 & mark your calendars Official POSETTE 2026 Trailer “By the numbers” summary for POSETTE 2026 Here’s a quick snapshot of what you need to know about POSETTE this year: 3 days 16-18 June 2026 4 livestreams In Americas & EMEA time zones but of course you can watch from anywhere 44 talks All free, all virtual 2 invited keynotes Driving Postgres forward at Microsoft (Livestream 1), and Postgres 19 Hackers Panel: What’s In, What’s Out, & What’s Next (Livestream 2) 25 minutes Average length per talk ~1100 minutes Total minutes in POSETTE 2026 talks 50 speakers POSETTE 2026 speakers include PostgreSQL hackers and contributors, users, application developers, PG community members, Azure engineers, & Azure customers 6 keynote speakers Affan Dar & Charles Feddersen (Livestream 1); and Álvaro Herrera, Heikki Linnakangas, Melanie Plageman, & Thomas Munro (Livestream 2) 19 countries Speakers reside in 19 different countries 23 companies Speakers hail from 23 different companies 17.6% CFP acceptance rate 42 talks selected from 238 submisssions 75% general Postgres talks 33 talks are not cloud-specific at all, they’re about the Postgres technology & ecosystem 25% Azure-related talks 11 of 44 talks feature Azure Database for PostgreSQL or Azure HorizonDB 1 organizing company Organized by the Postgres team at Microsoft, in partnership with AMD 17 languages Published talk videos will have captions available in 17 languages, including English, Czech, Dutch, French, German, Hindi, Italian, Japanese, Korean, Polish, Portuguese, Russian, Spanish, Turkish, Ukrainian, and Chinese Simplified & Chinese Traditional Map of the 44 talks To help you quickly navigate all 44 talks, here’s a map of the high-level categories and detailed topics. : A map of the POSETTE 2026 talks—high-level categories and detailed tags to help you find what you care about 2 Keynote sessions Affan Dar and Charles Feddersen lead the PostgreSQL engineering and product teams at Microsoft, In this keynote, they’ll walk through how Microsoft is contributing to Postgres, both upstream in the open source project and in the cloud database service they build on top of it. Driving Postgres forward at Microsoft, by Affan Dar & Charles Feddersen (Azure Database for PostgreSQL, Azure HorizonDB, VS Code, Dev tools, community, Postgres hacking, open source, PosetteConf, livestream-1) Want to understand how Postgres features get decided? This keynote panel with 4 PostgreSQL committers & hackers will peel back the curtain. You’ll hear what made it into Postgres 19, what didn’t (and why), and get a sneak peek into a few of the things in the oven for Postgres 20. Postgres 19 Hackers Panel: What’s In, What’s Out, & What’s Next, by Álvaro Herrera, Heikki Linnakangas, Melanie Plageman, & Thomas Munro (Postgres 19, Postgres hacking, panel, open source, collaboration, multithreading, livestream-2) 23 Postgres core talks Data Modeling JSON in PostgreSQL - evil data type or just needs to be tamed?, by Boriss Mejias (JSON, performance, data modeling, livestream-1) PostgreSQL Design Patterns, by Chris Ellis (data modeling, SQL, PG use cases, livestream-1) Graph Data Exploring property graphs with SQL/PGQ in PostgreSQL, by Ashutosh Bapat (SQL/PGQ, graph data, data modeling, Postgres 19, livestream-4) LISTEN/NOTIFY LISTEN Carefully: How NOTIFY Can Trip Up Your Database, by Jimmy Angelakos (LISTEN/NOTIFY, PG use cases, triggers, livestream-4) Performance Maintaining Large Tables in PostgreSQL, by Sarat Balijepalli (WAL, performance, scaling Postgres, vacuum, autovacuum, statistics, partitioning, monitoring, livestream-3) My Postgres partitioning cookbook, by Derk van Veen (partitioning, PG use cases, data modeling, performance, livestream-4) PostgreSQL 17 vs 18: Side‑by‑Side Performance Wins in Real‑World Queries, by Divya Bhargov (performance, PG use cases, livestream-3) Vacuuming Enhancements in PostgreSQL 18: Faster, Smarter, More Predictable, by Shashikant Shakya (vacuum, async IO, monitoring, performance, livestream-4) PG Internals Linux and PostgreSQL in the Multiverse of Connections, by Josef Machytka (Linux, PG internals, connection pooling, livestream-2) pg_stats: How Postgres Internal Stats Work, by Richard Yen (statistics, pg_stats, PG internals, query planner, livestream-2) Postgres isn’t slow, your storage is, by Sai Srirampur (storage, IO, performance, livestream-3) PostgreSQL queues done right with PgQ, by Alexander Kukushkin (queues, PG internals, extensions, livestream-2) random_page_cost in Postgres - why the default is 4.0 and should you lower it?, by Tomas Vondra (PG internals, IO, performance, livestream-1) The Wonderful World of WAL, by Bruce Momjian (WAL, PG internals, replication, livestream-3) What's new with constraints in Postgres 18, by Gülçin Yıldırım Jelínek (constraints, data modeling, livestream-2) Postgres Hacking Fuzzing PostgreSQL, by Adam Wolk (PG internals, testing, Dev tools, libpq, security, livestream-1) Journey of developing a performance optimization feature in PostgreSQL, by Rahila Syed (Postgres hacking, PG internals, performance, WAL, replication, livestream-4) The Hitchhiker’s Guide to PostgreSQL Hacking: Don’t Panic, Just Start Small, by Xuneng Zhou (Postgres hacking, PG internals, community, livestream-2) Replication Past, Present, and Future: Logical Decoding and Replication in PostgreSQL, by Hari Kiran (replication, logical decoding, PG internals, livestream-4) Where Does My INSERT Go? A Logical Replication Story, by Hamid Akhtar (replication, PG internals, WAL, livestream-4) Security From Dev to Prod: Securing Postgres the Right Way, by Sakshi Nasha (security, roles, PG use cases, extensions, monitoring, livestream-4) From trust to Tokens: A Short History of PostgreSQL Authentication, by Murat Tuncer (authentication, security, livestream-2) PostgreSQL vs. SQL Server: Security Model Differences, by Taiob Ali (security, authentication, SQL Server, roles, livestream-1) 11 Postgres ecosystem talks Analytics pg_lake: Postgres as a lakehouse, by Marco Slot (pg_lake, extensions, OLAP, data warehouse, Iceberg, DuckDB, analytics, livestream-2) Apache AGE Querying & Visualizing Graphs in Postgres with Apache AGE, by Christian Miles (Apache AGE, graph data, data visualization, SQL/PGQ, Azure HorizonDB, livestream-1) Autotuning Building safety tooling for risk-free AI tuning of Postgres: Fast cars need fast brakes, by Mohsin Ejaz (autotuning, AI, performance, monitoring, livestream-2) Change Data Capture Building Event-Driven Systems with PostgreSQL Logical Replication and Drasi, by Diaa Radwan (Drasi, replication, WAL, CDC, livestream-3) Citus Move Less, Move Faster: Speeding Up Citus Cluster Scaling, by Muhammad Usama (Citus, extensions, performance, scaling Postgres, livestream-4) Dev Tools An MCP for your Postgres DB, by Pamela Fox (MCP, AI, Python, Dev tools, livestream-1) pgcov: Bringing Real Test Coverage to PostgreSQL Code, by Pavlo Golub (testing, Postgres hacking, Dev tools, extensions, CI/CD, livestream-3) PostgreSQL Tooling Across AI Editors and Agents, by Matt McFarland (Dev tools, VS Code, Cursor, AI, data visualization, Apache AGE, graph data, Azure, MCP, Copilot, livestream-1) Django PostgreSQL Generated Columns by Example, by Paolo Melchiorre (app dev, Django, generated columns, livestream-2) Kubernetes Quorum-Based Consistency for Cluster Changes with CloudNativePG Operator, by Jeremy Schneider & Leonardo Cecchi (CloudNativePG, Kubernetes, PG use cases, livestream-3) Performance Modelling Postgres Performance Degradation on Burstable Cloud Instances, by Chun Lin Goh (performance, burstable, compute, QA, livestream-4) 8 Azure Database for PostgreSQL & Azure HorizonDB talks AI-related talks From Queries to Agents: The Next Era of Data Retrieval on PostgreSQL, by Abe Omorogbe (AI, MCP, Azure Database for PostgreSQL, graph data, Apache AGE, Azure HorizonDB, livestream-3) Production RAG at Scale with Azure Database for PostgreSQL, by Julia Schröder Langhaeuser & Paula Santamaría (Azure Database for PostgreSQL, AI, RAG, PG use cases, livestream-3) AMD Choose the Right Azure Infrastructure to Improve Postgres Performance by Over 60%, by Andrew Ruffin (AMD, performance, Azure, compute, Azure Database for PostgreSQL, livestream-1) Azure HorizonDB Why we built Azure HorizonDB for PostgreSQL, by Dingding Lu (Azure HorizonDB, scaling Postgres, livestream-3) Flexible Server pg_duckdb in Action: Accelerating Analytics on Azure Database for PostgreSQL, by Nitin Jadhav (DuckDB, Azure Database for PostgreSQL, extensions, OLAP, analytics, performance, livestream-4) The Rise of PostgreSQL as the Everything Database, by Varun Dhawan (Postgres history, extensions, graph data, Apache AGE, Azure Database for PostgreSQL, DuckDB, Citus, livestream-3) What I’ve Learned Teaching Postgres to 200+ field engineers at Microsoft, by Paula Berenguel (training, Azure, Postgres skilling, livestream-1) Oracle to Postgres Migrating VLDBs from Oracle to Azure Database for PostgreSQL, by Adithya Kumaranchath (migration, Azure Database for PostgreSQL, Oracle to Postgres, livestream-2) Why participate in the virtual hallway track on Discord If you’ve checked out the schedule and plan to watch some of the talks, you might still be wondering: why join live—and why bother with the virtual hallway track on Discord? Here’s how a few of last year’s attendees described the experience: “Very impressed by all the speakers and content I am absolutely shattered as there was so much great content in all the talks over the past 3 days but I have probably learnt more in these sessions than I could have in months of reading up.” “Want to let y’all know how much I got from this onine conference, the speakers were excellent, well-prepared and well-presented. The hosts were informative, engaging, & amusing. The discord hallway channel made me feel connected. I learned a lot and found some new inspiration. I’ll be back next year!” “I have no idea how I’m going to summarise all the interesting stuff for coworkers.” The common thread: the live, shared experience—being able to ask questions, compare notes, and learn alongside other people in real time. How to join the virtual hallway track Head to the #posetteconf channel on Discord (on the Microsoft Open Source Discord) That’s where speakers and attendees hang out during the livestreams—it’s where you can ask questions, share reactions, and just say hi Big thank you to our amazing speakers Every great event starts with great talks—and great talks start with great speakers. Want to learn more about the people behind these talks? Visit the POSETTE 2026 Speaker page Click a speaker’s bio to see their written interview (if available) If a speaker has been a guest on the Talking Postgres podcast in the past, then you’ll find a link to their episode there, too Join us for POSETTE 2026! Mark your calendars I hope you join us for POSETTE 2026. Consider yourself officially invited. As part of the talk selection team, I’m definitely biased—but I truly believe these speakers and talks are worth your time. I’ll be hosting Livestream 1 and you’ll find me in the #posetteconf Discord chat. I hope to see you there. And please: tell your Postgres friends, so they don’t miss out! 🗓️ Add the livestreams to your calendar Livestream 1: Tue 16 June, 8am–2pm PDT (UTC-7) [ register for updates ] and/or [ add to calendar ] Livestream 2: Wed 17 June, 8am–2pm CEST (UTC+2) [ register for updates ] and/or [ add to calendar ] Livestream 3: Wed 17 June, 8am–2pm PDT (UTC-7) [ register for updates ] and/or [ add to calendar ] Livestream 4: Thu 18 June, 8am–2pm CEST (UTC+2) [ register for updates ] and/or [ add to calendar ] Watch last year’s POSETTE 2025 talks in advance: And if you want to get ready, you can watch talks from the POSETTE 2025 playlist on YouTube anytime, anywhere. Lots of solid, useful, and evergreen Postgres talks in there. “Official Trailer” for POSETTE 2026 is on YouTube To help more developers, community members, and Postgres users discover POSETTE 2026, our team created this short video trailer. Take a peek and share it with friends as an invitation of sorts. We’re trying to make sure that people don’t miss their opportunity to be part of the livestreams and ask questions on the discord during the conference (as well as watch the talks on YouTube after the event is over.) Watch and share the trailer: Official Trailer for POSETTE: An Event for Postgres 2026 Acknowledgements & Gratitude I’ve already thanked the 50 amazing speakers above. In addition, thanks go to Silvano Coriani, Cornelia Biacsics, Aaron Wislang, and My Nguyen for reviewing parts of this post before publication. I also want to thank the team at AMD for their partnership and support of POSETTE this year! And of course, big thank you to the POSETTE 2026 organizing team and POSETTE talk selection team—without you, there would be no POSETTE! Figure 3: Visual invitation to join the virtual hallway track for POSETTE 2026 on the Microsoft Open Source Discord, so you can chat with the speakers & others in the Postgres communityNovember 2025 Recap: PostgreSQL on Azure
Hello Azure Community, November was an exciting month for PostgreSQL on Azure, packed with announcements at Microsoft Ignite 2025. In this recap, we’ll walk you through the highlights from features recaps to deep-dive sessions so you can catch up on everything you might have missed. If you couldn’t join us live, here are some of the key sessions now available on demand: Modern data modern apps: Innovation with Microsoft Databases AI-assisted migration: The path to powerful performance on PostgreSQL Azure HorizonDB: Deep Dive into a New Enterprise-Scale PostgreSQL The blueprint for intelligent AI agents backed by PostgreSQL Nasdaq Boardvantage: AI-driven governance on PostgreSQL and Microsoft Foundry We also introduced major updates, including Azure HorizonDB preview with AI capabilities and new features for Azure Database for PostgreSQL that make migrations faster, deployments smarter, and performance more predictable. The blog is organized into the following sections: Azure HorizonDB (Preview) Azure Database for PostgreSQL feature announcements Azure HorizonDB: AI features & developer tools Photo Gallery from Ignite Azure HorizonDB (Preview) If it’s not obvious, the introduction of Azure HorizonDB is a big deal. This brand-new, fully managed PostgreSQL service is built for mission-critical workloads and modern AI applications, bringing cloud-native scale, ultra-low latency, and deep Azure integration in one powerful offering. Here are some of the features that we offer with Azure HorizonDB: Scale-out compute architecture supporting up to 3,072 vCores across primary and replica nodes. Auto-scaling shared storage that handles databases up to 128 TB, while achieving sub-millisecond multi-zone commit latencies. Breakthrough throughput up to 3× higher than open-source PostgreSQL for transactional workloads, powered by our storage innovations. Learn more about Azure HorizonDB in our detailed blog. Azure Database for PostgreSQL feature announcements We introduced a wave of new capabilities focusing on performance, analytics, security and AI-assisted migration for Azure Database for PostgreSQL. Among the key general availability announcements were PostgreSQL 18, Fabric mirroring, Elastic clusters, and support for Parquet in the azure_storage extension. We also unveiled several exciting preview features, including Intel and AMD v6-series SKUs, the pg_duckdb extension, and enhanced tooling for Oracle-to-PostgreSQL migrations. All these updates are captured in our blog post explore the full list and learn more. Azure HorizonDB: AI features & developer tools Azure HorizonDB isn’t just built for enterprise-scale workloads it’s also designed to power next-generation AI applications. At Ignite, we introduced advanced AI capabilities including DiskANN with Advanced Filtering, built-in AI model management, and Microsoft Foundry integration. DiskANN Advanced Filtering reduces query latency by up to 3×, depending on filter complexity. AI Model Management enables developers to set up semantic operators directly within the PostgreSQL environment, simplifying AI workflows. Microsoft Foundry Integration adds a PostgreSQL connector, allowing Foundry agents to interact with HorizonDB securely using natural language instead of SQL. General Availability of PostgreSQL extension for VS Code We announced the general availability of the PostgreSQL extension for VS Code, making development faster and more intuitive. The PostgreSQL extension for VS code has now over 300K downloads from the Visual Studio Marketplace! This extension makes it easier for developers to seamlessly interact with any PostgreSQL databases. To learn more about these AI features in Azure HorizonDB, check out our blog post. Photo Gallery from Microsoft Ignite Ignite 2025 brought a lot of great sessions, announcements, and hands-on demos. Here’s a quick photo recap of some key moments from technical deep dives to product launches to hearing real world impact from our amazing customer speakers. POSETTE CFP Now Open We are excited to announce that the Call for Proposals (CFP) for POSETTE: An Event for Postgres 2026 is now open! We’re inviting speakers, practitioners, educators, and community contributors to share their knowledge through talks and demos. If you’re passionate about PostgreSQL, open-source innovation, or building resilient data systems, we’d love to see your submission. CFP Link: https://posetteconf.com/2026/cfp/
