Microsoft Blog for PostgreSQL articles

Get started faster in the PostgreSQL extension for VS Code

jane-yoon — Fri, 07 Aug 2026 18:50:43 GMT

The PostgreSQL extension for Visual Studio Code now includes a Get Started landing page that helps you discover key features, access helpful resources, and become productive faster after connecting to a server.

The image below shows the Get Started landing page, highlighting quick-action cards, learning resources, and featured updates available after you connect to a server.

Quick Actions

Each entry point applies to the database you have selected, so whatever you click picks up from the connection you just made.

Explore additional resources to navigate to PostgreSQL documentation

View at your Convenience

The landing page is shown only after a new server connection is added. Users who do not wish to see this page can disable it by clearing the "Show this page after adding a new connection" option at the bottom of the landing page.

Open the landing page anytime: Right-click any server in the connections tree and choose Get Started.

Try it out

Head over to PostgreSQL for Visual Studio Code and spin up a new server connection, or right-click a server you already have and choose Get Started.

Your feedback helps us improve. If you have ideas, suggestions, or resources you’d like to see included, reach out to AskAzurePostgreSQL@microsoft.com and help shape the experience for the PostgreSQL community.

AI-assisted Oracle-to-PostgreSQL schema conversion in Visual Studio Code

adityaduvuri — Fri, 07 Aug 2026 15:27:13 GMT

By AI Omar Rajawat, Pranay Lohia, Gautam Juneja, Vikas Nimmagadda, Anil Dogra, Aditya Duvuri

We’re seeing significant interest in migrating database workloads from Oracle to Azure Database for PostgreSQL. Historically, schema conversion has been one of the most technically challenging and expensive steps in that journey, demanding specialist knowledge of both engines and stretching migration timelines before a single row of data moves. Recent advances in AI-assisted schema conversion are changing that, turning what used to be a long, manual effort into a faster, more accessible, and lower-cost proposition. This post looks at what that shift means in practice for teams moving to Azure Database for PostgreSQL flexible server.

Oracle schema conversion is where the complexity of translating schema and code objects to PostgreSQL becomes visible. Packages, procedures, triggers, custom types, and dependencies built up over years must be mapped to PostgreSQL-compatible definitions while preserving the relationships that make the schema work.

Generally available since May 2026, the feature is built into the PostgreSQL extension for Visual Studio Code, published by Microsoft. It helps teams convert Oracle schema and code objects — tables, views, constraints, packages, procedures, functions, and triggers — into PostgreSQL-compatible definitions for Azure Database for PostgreSQL flexible server, with no separate conversion utility to install and no disconnected workflow to manage.

It brings schema discovery, conversion, compile validation, and review into one project-based experience. Teams can connect to Oracle, select schemas, and configure a Microsoft Foundry connection in the same project. The extension then translates Oracle-specific constructs, compiles and syntax-checks converted DDL into scratch schemas on Azure Database for PostgreSQL flexible server and surfaces unresolved items as review tasks that teams can work through with GitHub Copilot agent mode.

Why schema conversion deserves a better workflow

Traditional conversion tools can produce a useful first pass, but the long tail of the process is rarely solved by generating replacement DDL alone. Teams still need clear answers to practical questions: What converted successfully? What needs attention? Which Oracle constructs require a PostgreSQL design decision? Which items should be reviewed first?

We designed the schema conversion experience around those questions. The goal is not to hide complexity behind a single score. It is to help teams make steady progress while keeping the work visible and reviewable.

What the schema conversion experience provides

The experience guides teams through a schema conversion project rather than a collection of separate scripts. It discovers the selected Oracle schemas and converts both the relational model and the code that runs on it: tables, indexes, sequences, primary key, unique, check and foreign key constraints, views and materialized views, synonyms, and Oracle object types — along with the PL/SQL that is usually the hardest part of the migration. Packages and package bodies, package-level state, standalone procedures and functions, and triggers are translated into PostgreSQL functions, procedures, and trigger functions.

Oracle-specific constructs are mapped to PostgreSQL equivalents rather than dropped or stubbed out. REF CURSOR and SYS_REFCURSOR become PostgreSQL refcursor; CLOB and BLOB columns become text and bytea ; and NUMBER and VARCHAR2 are mapped by precision and length to their closest PostgreSQL types. Oracle date functions such as ADD_MONTHS, LAST_DAY, MONTHS_BETWEEN, and TRUNC are resolved through the orafce extension, which the project detects and flags for you before deployment. Every converted definition is compiled against scratch schemas on Azure Database for PostgreSQL flexible server, so the deployment script you end up with is an organized, dependency-ordered set of PostgreSQL SQL artifacts that has already been proven to build.

Objects that still require human judgment are surfaced as review tasks. Teams can inspect the source and converted definitions side by side, work through the remaining items, and use GitHub Copilot agent mode for guided assistance — keeping automation and human review in the same workflow.

How it works: the system architecture

Under the hood, the conversion engine follows one principle — the language model is a single, bounded stage; it never has the first or the last word. Deterministic steps decide what the model sees and what it is allowed to produce.

Deterministic in. Rule-based extraction reads the Oracle DDL and metadata, then a dependency-graph decomposition splits the estate into bounded, dependency-ordered chunks — so every object is converted in the context that keeps it correct.
Bounded conversion. A tiered model strategy through the Microsoft Foundry connection translates each chunk with structured, contract-wrapped input and output. Even very large PL/SQL packages are split and converted member by member, so nothing is trusted as a monolith.
Deterministic out. Converted objects pass through review, then compile-and-verify against scratch schemas on Azure Database for PostgreSQL flexible server, and finally dependency-ordered deploy assembly. Unresolved items become review tasks, and every object carries a per-object audit trail.

A continuous-improvement loop closes the system: the engineering team maintains a versioned regression suite of supported conversion patterns, and an executable benchmark tracks regressions as the pipeline evolves.

Proven in production

The approach has been exercised on real enterprise estate. Across representative production runs totaling more than 60,000 schema objects; conversion reached roughly 98% overall — with several schemas converting at a full 100%. The hardest tail, PL/SQL package members, now compiles at 96% across more than 20,000 members thanks to targeted coverage and a resilient compile stage.

Conversion outcome and review status are separate measures. Objects that convert and compile cleanly are safe to deploy as they are; the rest are deliberately routed into a prioritized review queue rather than silently accepted. In a representative single-schema run, no object ended in a hard conversion failure, and a cleanly generated object can still involve a PostgreSQL design decision. That is the workflow operating as intended: automation absorbs the volume, and review tasks to keep the remaining judgment calls visible, ordered, and auditable.

Measured, not asserted: the SchemaBench eval

Quality is verified by running it. SchemaBench, the evaluation framework, deploys each converted schema to a live PostgreSQL database and probes real behavior — whether constraints still fire and whether objects still resolve — rather than comparing DDL text. It scores seven weighted dimensions: semantic fidelity, structure, constraints, completeness, performance, target idioms, and maintainability, behind hard gates. On the e-commerce benchmark, the strongest model scored 96.1 overall with 100% semantic fidelity and a ~98% behavioral-probe pass rate. Every failure a migration hits becomes a permanent regression test the next run has to pass.

Learn more: Oracle to Azure Database for PostgreSQL schema conversion overview

Faster, Safer Version Upgrades for Databases with Large Objects

varun-dhawan — Wed, 05 Aug 2026 00:50:15 GMT

By Varun Dhawan, Ilan Benschikovski, and Alexander Kukushkin - Azure PostgreSQL, Microsoft

Faster, Safer Upgrades for Databases with Large Objects

TL;DR: We improved major version upgrades for PostgreSQL databases with very high large-object counts. For upgrades targeting PostgreSQL 15 and later, large-object metadata is now handled more efficiently, reducing memory/temp-space pressure and helping previously risky upgrades complete more reliably.

Why this matters

Some PostgreSQL workloads store documents, images, PDFs, scanned files, or attachments as large objects (LOBs). In normal operations this is fine. But during a major version upgrade, very high LOB counts could make the schema dump step slow, memory-heavy, or fail.

This improvement is about making that upgrade path safer and more predictable for Azure Database for PostgreSQL flexible server customers.

What changed?

During a major version upgrade, PostgreSQL uses pg_upgrade, which internally runs pg_dump to move schema and metadata into the new version.

For databases with millions of large objects, the older upgrade path handled large-object metadata one object at a time. That created high memory and temporary-space pressure during the schema dump phase.

This fix changes the upgrade path. Instead of processing large-object metadata one object at a time, PostgreSQL now transfers that metadata in bulk. The actual large-object data is not changed; only the upgrade metadata handling is improved.

Why this is different

This improvement builds on upstream PostgreSQL work that makes large-object metadata handling more efficient during upgrades. We brought that benefit into Azure Database for PostgreSQL flexible server for supported PostgreSQL 15+ upgrade targets, so customers with large-object-heavy workloads can benefit without waiting for a future PostgreSQL major version.

Before vs after

Area	Before	After
Metadata handling	One operation per large object	Bulk metadata transfer
Memory/temp pressure	Grew heavily with LOB count	Much flatter and more predictable
High LOB counts	Risk of OOM or temp-space failure	Completes more reliably for PostgreSQL 15+ targets
Customer workaround	`vacuumlo` + scale-up often needed	Less reliance on LOB-specific workarounds for PostgreSQL 15+ targets

In plain English: the upgrade no longer has to carry paperwork for every large object one by one. It moves the metadata in bulk, which makes the upgrade faster, safer, and less likely to fail at very high LOB counts.

The numbers

We tested upgrades from PostgreSQL 13 with large-object counts ranging from 10M to 500M. The older path is represented by PostgreSQL 13 → 14. The improved path is represented by PostgreSQL 13 → 15.

Note: These figures come from a multi-database test where large objects were spread across 100 databases. Because pg_dump runs per database, single-database workloads with the same total large-object count may see different runtimes.

Cap

Illustration: Bar chart comparing major version upgrade runtime for the older and improved large-object paths. At 10 million large objects, runtime drops from 48 to 16 minutes; at 20 million, from 62 to 18 minutes; and at 30 million, from 161 to 21 minutes.Illustration: Bar chart showing upgrade speedup at increasing large-object counts. The improved path is 3× faster at 10 million large objects, 3.4× faster at 20 million, and 7.6× faster at 30 million.

Outcome summary

Large objects	Older path	Improved path	What changed
10M	48 min	16 min	3x faster
20M	1h 02m	18 min	3.4x faster
30M	2h 41m	21 min	7.6x faster
50M	Failed at higher scale	26-30 min	Now completes
100M	Failed	54 min	Now completes
500M	Failed	4h 01m	Now completes

Key takeaway: this is not just faster. At higher LOB counts, the improvement changes the outcome from upgrade fails to upgrade completes.

Illustration: Line chart showing runtime for the improved upgrade path from 10 million to 500 million large objects. Runtime increases from 16 minutes at 10 million to 54 minutes at 100 million and 4 hours 1 minute at 500 million, with all tested upgrades completing successfully.

Who benefits from this?

You should care if your database stores large binary content using PostgreSQL large objects.

Workload pattern	Why it matters
Document management	PDFs, contracts, scans, and archived files
Attachment-heavy apps	Files stored inside PostgreSQL instead of external storage
Legacy apps using `lo` APIs	LOBs may have accumulated for years
Image/archive systems	Millions of binary objects can build up quietly
Previous upgrade failures	Failures during schema dump may map to this scenario

Copy/paste: check your large-object count

Run these checks in each database you plan to upgrade.

1. Count large objects in the current database

-- Count PostgreSQL large objects in the current database SELECT current_database() AS database_name, count(*) AS large_object_count FROM pg_largeobject_metadata;

2. Check large-object storage footprint

-- Estimate large-object data and metadata size SELECT pg_size_pretty(pg_total_relation_size('pg_largeobject'::regclass)) AS large_object_data_size, pg_size_pretty(pg_total_relation_size('pg_largeobject_metadata'::regclass)) AS large_object_metadata_size;

3. Understand ownership and ACL shape

-- Inspect large-object metadata shape SELECT count(*) AS total_large_objects, count(lomacl) AS large_objects_with_custom_acl, count(DISTINCT lomowner) AS distinct_large_object_owners FROM pg_largeobject_metadata;

4. Find top large-object owners

-- Top large-object owners SELECT lomowner::regrole AS owner, count(*) AS large_object_count FROM pg_largeobject_metadata GROUP BY lomowner ORDER BY large_object_count DESC LIMIT 10;

What should I do before my next major version upgrade?

If your situation is...	Recommended action
Target is PostgreSQL 15 or later	Target PostgreSQL 15 or later to benefit from improved large-object metadata handling.
Target is PostgreSQL 14 or earlier	Prefer PostgreSQL 15+ where possible; very high LOB counts may still hit older-path limitations.
Very large or unusual database	Restore a copy and rehearse the upgrade before production.
Suspected orphan LOBs	Consider `vacuumlo` only after testing. It can delete valid LOBs if your app uses custom references.
Any major version upgrade	Keep healthy free space and leverage pre-upgrade validation checks to validate extension/schema compatibility first.

Bottom line

If large objects were making your PostgreSQL upgrade risky, this improvement makes the upgrade path safer and more predictable. For large-object-heavy databases, upgrades targeting PostgreSQL 15 and later now show faster runtime, lower memory/temp-space pressure, and successful validation up to 500M large objects.

Learn more

Top 10 Performance Optimization Techniques for Azure Database for PostgreSQL Flexible Server

anugya-sinha — Mon, 03 Aug 2026 21:21:23 GMT

Introduction

Performance optimization is one of the most common challenges faced by organizations running business-critical workloads on Azure Database for PostgreSQL flexible server. As your workloads grow it’s common to encounter high CPU utilization, storage bottlenecks, autovacuum issues, excessive temporary file generation, and connection saturation.

The good news is that Azure PostgreSQL flexible server provides several built-in capabilities to help optimize performance, improve scalability, and reduce operational overhead. This article explores ten practical techniques that can significantly improve database performance and reliability.

1. Choose the Right Compute SKU

Performance starts with selecting the appropriate compute tier.

Azure PostgreSQL flexible server offers:

Pricing tier	Target workloads
Burstable	Designed for workloads that don't require full CPU performance continuously. Best suited for proof-of-concept environments, and development builds. Not recommended for production workloads.
General Purpose	Provides a balance between CPU and memory with scalable I/O throughput, making it suitable for most production workloads. Examples include servers for hosting web applications, mobile apps, and enterprise applications.
Memory Optimized	Suitable for high-performance database workloads that require in-memory performance for larger buffer cache sets, and higher concurrency. Examples include servers for processing real-time data and high-performance transactional or analytical apps.

Learn more about Compute Tiers here.

2.Enable and Use Query Store

Query Store is one of the most powerful performance tools available.

Query Store automatically captures the following and keeps them available for review:

Query execution statistics

Runtime metrics

Wait event information

Historical execution trends

It organizes the data into time windows, so you can spot database usage patterns. Data for all users, databases, and queries is stored in a database named azure_sys in the Azure Database for PostgreSQL instance.
It’s generally recommended to monitor query store from Azure tools, KQL, etc.
Learn more about Query store here.
You can also view some useful scenario for query store and some Best Practices for Query store

3.Leverage Built-In PgBouncer Connection Pooling

PostgreSQL uses a process-per-connection model, which means every connection consumes memory and CPU resources.

Azure PostgreSQL flexible server provides built-in PgBouncer support for eligible SKUs . PgBouncer allows multiple application sessions to reuse open backend connections and significantly reduces overhead.

Benefits include:

Lower memory consumption

Faster connection handling

Improved application scalability

Reduced CPU overhead

Learn more about PgBouncer here

4.Use Azure Troubleshooting Guides

One underutilized feature is the built-in troubleshooting experience available directly in the Azure portal.

Guides are available for:

CPU troubleshooting

Memory troubleshooting

IOPS analysis

Temporary files

Autovacuum monitoring

Autovacuum blockers

These tools provide actionable recommendations and visualizations without requiring external monitoring solutions.
Learn more about Troubleshooting Guides here.

5. Monitor and Tune Autovacuum

Autovacuum is critical for maintaining PostgreSQL performance.

Without proper vacuuming:

Dead tuples accumulate

Table bloat increases

Statistics are not refreshed regularly

Query performance degrades

Transaction ID wraparound risks emerge

Use Azure's built-in Autovacuum Monitoring TroubleshootingGuides to identify:

Vacuum lag

Blocked autovacuums

Table bloat

Inefficient cleanup operations

Azure now also offers adaptive tuning capabilities to optimize maintenance behavior.
Learn more about Autovacuum tuning here

6.Optimize Storage and IOPS Planning

Many performance incidents originate from insufficient storage planning rather than inefficient SQL.

In Azure PostgreSQL flexible server:

Storage and baseline IOPS are closely related. Learn more here.

Larger storage allocations provide higher baseline IOPS.

Auto-grow prevents storage-related outages
Note: Storage can only be scaled up and will always be double in size.
SSDv2 auto-grow will allow customized growth settings in future release.

For write-heavy workloads, monitoring storage utilization and IOPS is essential.

Best practice:

Enable Storage Auto-Grow

Monitor Read/Write IOPS regularly

Scale storage proactively

7.Investigate Temporary File Generation

Large sorts and hash operations that exceed available memory spill to disk and generate temporary files.

Symptoms include:

Sudden Latency Spikes

Increased IOPS

Slower query execution

Azure TroubleshootingGuides provide dedicated temporary-file analysis capabilities that help identify offending queries.

Frequent temp file generation often indicates:

Missing indexes

Undersized work_mem

Large sorting operations

8.Use Intelligent Tuning

Azure PostgreSQL flexible server includes Intelligent Tuning capabilities.

The service continuously observes workload behavior and automatically optimizes parameters related to write operations.

Examples of tuning include:

checkpoint_completion_target

max_wal_size

min_wal_size

bgwriter settings

This reduces administrative effort while helping maintain consistent performance.
Learn more about Intelligent Tuning here.

9.Optimize Checkpoints and Write Workloads

Checkpoint spikes frequently appear in escalations involving high IOPS and latency.

Aggressive checkpoint activity can:

Generate excessive disk writes

Increase latency

Consume IOPS capacity

Monitoring checkpoint behavior and ensuring WAL parameters are properly configured can significantly improve write-intensive workloads. Azure intelligent tuning can assist in this area as well.

10.Metric Monitoring

Optimization should always be data-driven.

You should track the following:

CPU utilization

Memory pressure

Active Connections

Oldest Query

IOPS consumption

Combining Azure Metrics, Query Store, and PostgreSQL statistic views allows teams to distinguish between normal workload spikes and true performance degradation.

PostgreSQL statistics views provide valuable workload insights. For example, pg_stat_activity can be used to identify long-running or blocking queries, pg_stat_user_tables helps track dead tuples, vacuum activity, and statistics refreshes, while pg_stat_statements (if enabled) help identify the most resource-intensive queries by execution time and frequency.

Learn more about Metric here

Conclusion

Performance optimization in Azure Database for PostgreSQL flexible server is not just about changing a few parameters and hoping for better results. It requires a structured approach that combines workload understanding, proactive monitoring, proper sizing, query optimization, and platform-native capabilities.

By leveraging Query Store, PgBouncer, Intelligent Tuning, Autovacuum Monitoring, Azure Metrics, and Troubleshooting Guides, you can significantly improve database efficiency while reducing operational effort.

References

Compute Options - Azure Database for PostgreSQL | Microsoft Learn
Query Store in Azure Database for PostgreSQL Flexible Server - Azure Database for PostgreSQL | Microsoft Learn
PgBouncer in Azure Database for PostgreSQL Flexible Server - Azure Database for PostgreSQL | Microsoft Learn
Autovacuum Tuning - Azure Database for PostgreSQL | Microsoft Learn
Intelligent Tuning in Azure Database for PostgreSQL Flexible Server - Azure Database for PostgreSQL | Microsoft Learn

AI-Powered Retrieval in PostgreSQL with Azure HorizonDB

FranckPachot — Tue, 28 Jul 2026 18:08:05 GMT

Developers need flexible, efficient item searches by description. Using a Wikipedia movie dataset, I started with full-text search, then created embeddings for descriptions, and performed semantic searches. Queries combined text or similarity searches with filters. Common questions arose: How to update embeddings as data changes? How to avoid reprocessing all data? How to make AI calls more efficient? I prefer to keep business logic in the app and data manipulation in SQL, but triggers and stored procedures complicate this.

This post explores keeping retrieval workflows inside the database, using data, indexes, filters, and rules already in place. Instead of external workers, I want SQL abstractions to handle operations like generating and maintaining embeddings as part of the data model. I begin with relational data, using BM25 text search, generating embeddings with AI Model Management (AIMM) and AI Functions, storing them with pgvector, indexing them with DiskANN, and integrating AI into PostgreSQL. Then I define an AI pipeline to maintain consistency without extra procedural code.

The goal is to keep AI processing close to data with declarative SQL. I used a Kaggle movies dataset with 30,000 entries over 11 years, importing a subset for simplicity. Each file has title, description, director, country, year, and ID.

HorizonDB and AI extensions

I've run this on HorizonDB preview, where I enabled pg_textsearch, pg_vector, DiskANN, and azure_ai extensions:

postgres=> select name, current_setting(name) from pg_settings where name in ('server_version', 'azure.extensions') ; name | current_setting ------------------+----------------------------------------------- azure.extensions | pg_diskann,vector,pg_textsearch,azure_ai server_version | 17.9 (Azure HorizonDB (81895d42565)(release)) (2 rows)

I downloaded and unzipped the dataset files in the current directory:

\! curl -L -o movies-dataset-2016-2026.zip https://www.kaggle.com/api/v1/datasets/download/lakshyaupadhyaya/wikipedia-movies-dataset-2016-2026 \! unzip -o movies-dataset-2016-2026.zip \! rm movies-dataset-2016-2026.zip

I created a table where I can load this data and add embeddings later:

postgres=> drop table if exists wikipedia_movies ; DROP TABLE postgres=> create table wikipedia_movies ( year int, id bigint, title text, description text, directed_by text, written_by text, produced_by text, starring text, cinematography text, edited_by text, release_date text, country text, language text, primary key (year, id) ); CREATE TABLE postgres=> create index on wikipedia_movies (country) ; CREATE INDEX

I loaded data from 2026 using a one-liner that prepends the year from the filename.

postgres=> \copy wikipedia_movies from program 'awk ''FNR>1{print substr(FILENAME,1,4)","$0}'' {2026..2026}.csv' with (format csv) COPY 852

Some rows have a NULL description. I updated them with the title so every row has something meaningful to embed or search, and make sure the description cannot be null:

postgres=> update wikipedia_movies set description = format('Title: %s', title) where description is null ; UPDATE 22 postgres=> alter table wikipedia_movies alter column description set not null ; ALTER TABLE

So far, there's nothing AI-specific here. It's simply PostgreSQL functioning as it always does: storing structured data, enforcing keys, and allowing me to load, clean, and query using SQL.

Try full-text search first

Before generating embeddings for similarity search, I started with lexical search. Azure Database for PostgreSQL supports pg_textsearch, which provides BM25-based full-text search and scoring.

postgres=> create extension if not exists pg_textsearch; CREATE EXTENSION postgres=> create index wikipedia_movies_description_idx on wikipedia_movies using bm25 (description) with (text_config = 'english') ; NOTICE: BM25 index build started for relation wikipedia_movies_description_idx NOTICE: Using text search configuration: english NOTICE: Using index options: k1=1.20, b=0.75 NOTICE: BM25 index build completed: 852 documents, avg_length=35.95 CREATE INDEX

Then I can search the descriptions:

postgres=> select description <@> 'Spanish tragicomedy autofiction from 2026' as score, title, description from wikipedia_movies where country = 'Spain' and year = '2026' order by score limit 2 ; score | title | description --------------------+------------------+------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------ -17.06686845421791 | Bitter Christmas | Bitter Christmas (Spanish: Amarga Navidad) is a 2026 Spanish tragicomedy film written and directed by Pedro Almodóvar. It stars Bárbara Lennie and Leonardo Sbaraglia alongside Aitana Sánchez-Gijón, Victoria Luengo, Patrick Criado, Milena Smit, and Quim Gutiérrez. It incorporates elements of autofiction. -5.273793399333954 | Aida, the Movie | Aida, the Movie (Spanish: Aída y vuelta) is a 2026 Spanish comedy film directed by Paco León serving as a meta-sequel to the sitcom Aída. (2 rows) Time: 31.024 ms

This is the appropriate initial step. When the query includes terms found in the text, BM25 provides search and scoring capabilities. It is transparent, efficient, and easy to combine with relational filters. Nevertheless, lexical search has its limitations. It works best when the query vocabulary matches the data. But what if the user searches by concept rather than exact words? Or if the query is in French while the descriptions are in English? In such situations, embeddings help capture the semantic meaning of the description rather than its words. They do not replace BM25 but serve as an additional signal for retrieval.

AI Model Management

AI Model Management (AIMM) includes pre-provisioned models, so manual registration is not required, and I've just enabled the managed model:

Once successfully enabled, I can see three registered models, which are used by default by the AI functions:

Without AIMM, you would need to bring your own model, or deploy an OpenAI model in Azure AI Foundry, and register it:

postgres=> create extension if not exists azure_ai ; CREATE EXTENSION postgres=> select model_registry.model_add('default-embedding',...) ; model_add ------------------------------------------------------------------------ Model 'default-embedding' (text-embedding-3-small) added successfully. (1 row) Time: 40.762 ms

Generate embeddings manually

I created a vector column and generated embeddings directly from the movie descriptions.

postgres=> create extension if not exists azure_ai ; CREATE EXTENSION postgres=> create extension if not exists vector; CREATE EXTENSION postgres=> alter table wikipedia_movies add column embedding vector(1536), alter column embedding set storage external -- (it's the default) ; ALTER TABLE postgres=> update wikipedia_movies set embedding = azure_openai.create_embeddings( input => description, dimensions => 1536 )::vector(1536) ; INFO: Using user-assigned managed identity authentication method. UPDATE 852 Time: 200905.958 ms (03:20.906)

This approach invokes the embedding service separately for each row. These calls are visible if you set client_min_messages to 'log'. Making external service calls asynchronously for each row is not optimal. Performance could be improved by batching the requests into a more complex query:

postgres=> with numbered as ( select year, id, description, (row_number() over() - 1) / 100 as batch_num from wikipedia_movies ), batched AS ( select array_agg(year) as years, array_agg(id) as ids, array_agg(description) as texts, batch_num from numbered group by batch_num ), embedded AS ( select unnest(years) as year, unnest(ids) as id, azure_openai.create_embeddings( input => texts, dimensions => 1536 ) as emb from batched ) update wikipedia_movies t set embedding = e.emb::vector(1536) from embedded e where t.year = e.year and t.id = e.id ; UPDATE 852 Time: 10892.871 ms (00:10.893)

This is precisely where an abstraction is needed to simplify and optimize embedding generation. I will add that later.

After setting the vectors in the table, I can proceed to add a DiskANN index.

postgres=> CREATE EXTENSION IF NOT EXISTS pg_diskann ; CREATE EXTENSION postgres=> CREATE INDEX wikipedia_movies_embedding_idx ON wikipedia_movies USING diskann (embedding vector_cosine_ops) ; CREATE INDEX Time: 5369.375 ms (00:05.369)

This allows me to perform a semantic query in French on English descriptions while continuing to filter using standard SQL:

postgres=> select azure_openai.create_embeddings( input => 'une comédie amère sur le thème de l''auto-fiction' )::vector(1536) <=> embedding as score, title, description from wikipedia_movies where country = 'Spain' and year = '2026' order by score limit 2 ; score | title | description -------------------+------------------+-------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- 0.692949073279717 | Bitter Christmas | Bitter Christmas (Spanish: Amarga Navidad) is a 2026 Spanish tragicomedy film written and directed by Pedro Almodóvar. It stars Bárbara Lennie and Leonardo Sbaraglia alongside Aitana Sánchez-Gijón, Victoria Luengo, Patrick Criado, Milena Smit, and Quim Gutiérrez. It incorporates elements of autofiction. 0.757078099513101 | Cool Books | Cool Books (Spanish: Casi todo bien)[1] is a 2026 Spanish comedy-drama film directed by Andrés Salmoyraghi and Rafael López Saubidet and written by López Saubidet and Ricardo Uhagón Vivas. It stars Marcel Borràs and Silma López alongside Lorenzo Ferro, Julián Villagrán, Secun de la Rosa, and Adelfa Calvo. (2 rows) Time: 269.598 ms

The query goes beyond simple token matching: it searches based on the description's meaning across different languages, while PostgreSQL continues to enforce relational filters on the year and country.

The execution plan shows a filtered scan through the DiskANN index:

QUERY PLAN ----------------------------------------------------------------------------------- Limit (actual time=1.622..1.642 rows=2 loops=1) -> Custom Scan (DiskANNFilteredScan) (actual time=1.620..1.639 rows=2 loops=1) Strategy: Filter(BitmapHeapScan) -> Vector Rows Retrieved: 2 count TIDs Collected: 31 count Planning Time: 250.003 ms Execution Time: 1.789 ms (7 rows) Time: 283.231 ms

This approach is efficient: the "country" predicate leverages the b-tree index for pre-filtering, narrowing the search to 31 rows identified by their TID—tuple identifiers stored in the b-tree leaf nodes. The Approximate Nearest Neighbors search then considers only this pre-filtered list when navigating the vector index, finding the best candidates, and subsequently retrieving the top two. Although I could have used pgvector's HNSW index instead of DiskANN, it lacks pre-filtering capabilities.

I now face a maintenance issue: the embeddings remain correct only until the next insert or update of the description. In SQL, I expect indexes to be maintained synchronously by the database rather than by the application, but embedding generation is a step in between.

Embedding becomes a pipeline

For a one-time load, manually running the UPDATE is sufficient. However, for regular applications, this approach isn't practical. I don't want to remember to run an embedding update whenever new movies arrive, nor do I want an extra worker polling the table, additional queues, retry loops, or extra status tables that can cause data to get out of sync. Instead, I prefer the embedding workflow to be directly linked to the data, with AI pipelines in the AI Functions. A pipeline consists of a source, steps, a trigger, and a sink. In this case, the source is the movie table, the step is embedding generation, the trigger is an on_change event, and the sink is the same table with the embeddings stored as a column within each row’s description.

postgres=> SELECT ai.create_pipeline( name => 'movie_embeddings', source => ai.table_source('wikipedia_movies'), steps => ARRAY[ ai.embed( model => 'default-embedding', input => 'description', dimensions => 1536 ) ], trigger => 'on_change', sink => ai.table_sink( 'wikipedia_movies', on_conflict => ARRAY['year', 'id'], on_conflict_action => 'DO UPDATE SET embedding = EXCLUDED.embedding' ) ); NOTICE: trigger "_ai_pipeline_movie_embeddings_trigger" for relation "public.wikipedia_movies" does not exist, skipping create_pipeline -------------------------------------------------- Pipeline 'movie_embeddings' created successfully (1 row)

The AI pipeline is configured to insert embeddings into a sink table, with an on-conflict clause that updates the existing row rather than inserts a new one when the key already exists. When the sink table is the source table, this always leads to an insert conflict because the row already exists when the pipeline runs, making it an update. The pipeline creates an internal batch from the source, generates embeddings, and writes them back with ON CONFLICT DO UPDATE. The trigger verifies whether the pipeline is already running in the same transaction to prevent an infinite recursion when it writes back to the same table.

I can validate my pipeline by updating all embeddings for each description using the AI model and requesting a backfill:

postgres=> select ai.backfill('movie_embeddings') ; NOTICE: table "_ai_batch_d03946bdb634_chunks" does not exist, skipping backfill ----------------------------------------------------------- Pipeline 'movie_embeddings' completed: 852 rows processed (1 row) Time: 10653.393 ms (00:10.65)

This was as quick as my batching query because the default batch size is 100.

Under the hood: triggers and batches

I like to understand what is executed behind the abstraction. The call to ai.create_pipeline() has created an internal trigger on my table:

This trigger function is called after each INSERT or UPDATE statement, not after individual rows, and runs the pipeline if it's not already active. The FOR EACH STATEMENT option ensures it triggers once per DML statement rather than per row, enabling batching. By default, it behaves like my previous ai.backfill(), updating all embeddings regardless of description changes. Interestingly, it calls ai.run() instead of ai.backfill(), which can operate incrementally if a tracking column exists in the source table.

Only process what changed: incremental pipelines

Without an incremental_column specified in the pipeline, it replicates the source table as its batch table and re-embeds all data each time. Generating embeddings again for the unchanged description is inefficient. To prevent this, I should add a timestamp column to indicate each row's last modification time and configure the pipeline to use it as a watermark:

postgres=> -- add the tracking column alter table wikipedia_movies add column updated_at timestamptz not null default clock_timestamp() ; postgres=> -- function to set the update_at to now() create or replace function update_timestamp() returns trigger as $$ begin new.updated_at = clock_timestamp(); return new; end; $$ language plpgsql ; postgres=> -- trigger to call the function on insert or update create trigger wikipedia_movies_updated before insert or update on wikipedia_movies for each row execute function update_timestamp() ;

Lots of PostgreSQL examples use now() to set the update time, but now() returns the time when the transaction began, not the time when the update occurred, so using it for an incremental approach could miss the changes if a concurrent session ran the pipeline between those two in Read Committed isolation. I use clock_timestamp() which gets the time after the verification that no concurrent pipeline is running.

Now I can re-create the pipeline with the incremental column defined:

postgres=> select ai.drop_pipeline( 'movie_embeddings' ); drop_pipeline ------------------------------------- Pipeline 'movie_embeddings' dropped (1 row) postgres=> select ai.create_pipeline( name => 'movie_embeddings', source => ai.table_source( 'wikipedia_movies', incremental_column => 'updated_at' ), steps => ARRAY[ ai.embed( model => 'default-embedding', input => 'description', dimensions => 1536 ) ], trigger => 'on_change', sink => ai.table_sink( 'wikipedia_movies', on_conflict => ARRAY['year', 'id'], on_conflict_action => 'DO UPDATE SET embedding = EXCLUDED.embedding' ) ); NOTICE: trigger "_ai_pipeline_movie_embeddings_trigger" for relation "public.wikipedia_movies" does not exist, skipping create_pipeline -------------------------------------------------- Pipeline 'movie_embeddings' created successfully (1 row)

When using incremental_column => 'updated_at', the batch records the last execution time as a checkpoint, so the next run only processes rows with an updated_at value higher than that checkpoint.

The next run will then process all rows again:

postgres=> select ai.run('movie_embeddings'); NOTICE: table "_ai_batch_ef762cbb918f_chunks" does not exist, skipping run ----------------------------------------------------------- Pipeline 'movie_embeddings' completed: 852 rows processed (1 row) Time: 12231.656 ms (00:12.232)

However, a new execution will process only incrementally:

postgres=> select ai.run('movie_embeddings'); run ----------------------------------------------------- Pipeline 'movie_embeddings': no new rows to process (1 row) postgres=> update wikipedia_movies set description = description || ' (film Français)' where country = 'France' ; NOTICE: table "_ai_batch_9769bddf6224_chunks" does not exist, skipping UPDATE 7 Time: 477.686 ms postgres=> select ai.run('movie_embeddings'); run ----------------------------------------------------- Pipeline 'movie_embeddings': no new rows to process (1 row) Time: 33.692 ms

The 7 updated rows have been handled by the trigger, which set the checkpoint timestamp, ensuring that the next run has no further processing to perform.

I loaded only 2026 movies to save AI model tokens. I insert more movies from previous years and specific countries:

\copy wikipedia_movies from program 'awk ''FNR>1{print substr(FILENAME,1,4)","$0",,"}'' {2016..2025}.csv' with (format csv) where description is not null and country like '%France%' COPY 1730 Time: 24935.910 ms (00:24.936)

The insert has automatically generated 1730 embeddings from the model. The new rows are immediately accessible and can be retrieved using a new query.

postgres=> select azure_openai.create_embeddings( input => 'a movie based on a novel from A. Camus' )::vector(1536) <=> embedding as score, year, title, country from wikipedia_movies order by score limit 2 ; score | year | title | country --------------------+------+------------------+----------------- 0.4765376989279472 | 2025 | The Stranger | France, Belgium 0.5485678715584099 | 2024 | An Ordinary Case | France (2 rows) Time: 448.648 ms

The result includes the newly inserted movies from previous years. The index remains strongly consistent when the “embedding” column is modified, and the AI pipeline ensures this consistency also applies to changes in the “description” column. It behaves exactly like indexes in SQL: transparent to the application, consistent in the database.

More AI functions

Generating the embeddings is not the only feature of AI functions. Previously I've updated the description for the movies that didn't have one, simply putting the title in it. However, I can use generate() to get a real description:

postgres=> \x Expanded display is on. postgres=> select azure_ai.generate(format( 'Write a short description for the movie %s, directed by %s', title, directed_by )), title from wikipedia_movies where description like 'Title: %' limit 3 ; -[ RECORD 1 ]--------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- generate | Billie Eilish – Hit Me Hard and Soft: The Tour (Live in 3D) is a concert film directed by James Cameron and Billie Eilish, capturing the energy and emotion of Eilish’s live tour in immersive 3D. Blending striking visuals with powerful performances, the film brings audiences into the heart of the show and offers a vivid celebration of her music and stage presence. title | Billie Eilish – Hit Me Hard and Soft: The Tour (Live in 3D) -[ RECORD 2 ]--------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- generate | Border 2 is an upcoming Indian war drama directed by Anurag Singh. Serving as a sequel to the iconic film Border, it is expected to bring a powerful story of patriotism, courage, and sacrifice, set against the backdrop of military conflict. title | Border 2 -[ RECORD 3 ]--------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- generate | *February* (2022) is a drama film directed by Kamen Kalev. The story follows a quiet man through different stages of his life, using minimal dialogue and striking imagery to reflect on solitude, routine, and the passage of time. title | (February 2022)

The generate() function doesn't simply repeat the title. Using the title and director as context, it generates a richer description that can be stored in the table, indexed with BM25, embedded for semantic search.

Instead of generating text from structured column, with the generate() function, I can do the opposite: create new columns from the description with the extract() function:

postgres=> select azure_ai.extract( description, array['genre'] ), title from wikipedia_movies limit 3 ; -[ RECORD 1 ]-------------------------------------- extract | {"genre": "coming-of-age romantic drama"} title | 18th Rose -[ RECORD 2 ]-------------------------------------- extract | {"genre": "drama"} title | Animol -[ RECORD 3 ]-------------------------------------- extract | {"genre": "documentary film"} title | The Best Summer

Like embeddings, extracted attributes or additional columns could be maintained automatically through an AI Pipeline when descriptions change.

Another function, azure_ai.rank(), can use the re-ranker model on the set of candidates (AIMM installed the Cohere Rerank model).

Hybrid search in one query

Once the table has both a BM25 index and embeddings, there is no need to choose between lexical and semantic retrieval. For many real applications, the best answer is to get candidates from both approaches and combine them to retrieve the best overall score.

A classic way to combine them is Reciprocal Rank Fusion:

postgres=> with semantic as ( select year, id, rank() over ( order by embedding <=> azure_openai.create_embeddings( input => 'space opera produced or directed by luc besson', dimensions => 1536 )::vector(1536) ) as r from wikipedia_movies where year between 2016 and 2026 ), lexical as ( select year, id, rank() over ( order by description <@> 'space opera produced or directed by luc besson' ) as r from wikipedia_movies where year between 2016 and 2026 ) select m.year, m.title from wikipedia_movies m join semantic s using (year, id) -- Join both result sets (full join to keep all) full join lexical l using (year, id) -- Reciprocal Rank Fusion (RRF): order by coalesce(1.0 / (60 + s.r), 0) + coalesce(1.0 / (60 + l.r), 0) desc limit 5 ; NOTICE: pg_diskann: Filter selectivity too high (1.0000), skipping filtered vector scan year | title ------+--------------------------------------------- 2017 | Valerian and the City of a Thousand Planets 2025 | Dracula 2016 | Ballerina 2024 | Meanwhile on Earth 2016 | The Warriors Gate (5 rows) Time: 410.727 ms

The data and filters remain relational, with both BM25 and vector search options available. Ranking is handled through SQL, embeddings are synchronized through a pipeline, and reranking can be delegated to an AI model when additional precision is required. The notable aspect isn't just PostgreSQL's ability to invoke AI models, but that the entire retrieval workflow, from indexing and filtering to ranking and reranking, remains close to the data and can be expressed declaratively in SQL.

Conclusion

This example started with a simple retrieval problem: searching movie descriptions, combining lexical and semantic relevance, and keeping embeddings synchronized as data changes. Along the way, it used AI Functions, BM25 full-text search, vector embeddings, DiskANN indexes, and AI Pipelines, all from within PostgreSQL.

Those capabilities are part of a broader set of multi-model features in HorizonDB, including built-in AI models and functions, graph queries with Apache AGE, and durable workflow execution. What interested me here was not any individual feature, but how they fit together around the data. Search, embeddings, indexing, and synchronization can be expressed in SQL and managed alongside the application data they depend on.

AI applications still need models, prompts, and business logic in the application layer. But retrieval remains a critical foundation. By combining relational data, keyword search, vector search, and automated embedding pipelines within a single PostgreSQL database, HorizonDB reduces the infrastructure required to keep that foundation accurate, consistent, and up to date.

If you'd like to try these capabilities yourself, visit the PostgreSQL Hub for sample applications, learning paths, and solution accelerators. The PostgreSQL Developer Forum is also the best place to share feedback, ask questions, and participate in the community.

TLS Certificate Pinning and Best Practices in Azure Database for PostgreSQL

TameikaL — Fri, 24 Jul 2026 20:02:19 GMT

TLS certificate pinning in Azure Database for PostgreSQL

Transport Layer Security (TLS) encrypts data in transit between client applications and the server and authenticates the service endpoint in client-server authentication.

Azure Database server certificates are issued by well-known trusted public Certificate Authorities (CAs), including Microsoft-issued certificates, and are validated by clients during the TLS handshake. Customers do not manage certificates on the server side.

Certificate pinning is a client-side security technique where an application restricts trust to a specific certificate, for example by thumbprint, public key, or CA, rather than relying solely on the default OS or platform trust store. The trust store contains pre-installed root CAs and may also include additional certificates configured by the client. During standard TLS validation, the client will trust any server certificate that chains to one of those root CAs.

Why detecting TLS certificate pinning is not possible by design

Certificate pinning is entirely client-side logic. The server has no visibility into whether pinning is configured on the client. From the server’s perspective, the client either completes the TLS handshake or aborts it. The server never sees:

Which certificate(s) the client trusts
Whether the client is comparing root CA, intermediate CA, leaf certificate or SPKI hash
Whether the trust decision was static or dynamic

What the server can see is TLS handshake failure patterns, TLS protocol, and cipher negotiation.

Why certificate pinning is risky

While certificate pinning was historically used to reduce the risk of man-in-the-middle attacks, it introduces significant operational fragility in cloud environments, particularly during certificate rotations.

Server certificates and certificate authorities (CAs) must be rotated periodically to maintain security and compliance. In Azure Database for PostgreSQL, when certificate pinning is used, clients bind trust to a specific certificate or CA. As a result, any change to the server certificate chain—including CA updates—can cause connection failures, even when the new certificates are fully valid and secure.

One of the most common complications during certificate rotations is certificate pinning.

Recommended TLS certificate trust model for Azure PostgreSQL

Instead of pinning, adopt a CA‑based trust model that allows certificates to change safely.

Trust root CAs, not individual certificates.

Configure clients to use standard TLS validation against Azure-documented root CAs, rather than restricting trust to specific certificates or a narrowly scoped set of certificate authorities. Avoid configurations that effectively implement certificate pinning—such as trusting only a single certificate, public key, or limited CA set—unless explicitly required.

Maintain a flexible and up-to-date trust store

Clients rely on a trust store, key store, or equivalent certificate bundle to validate server certificates during TLS negotiation.

Include the appropriate root and intermediate certificate authorities (CAs) required to validate the server certificate chain
Ensure that trust stores are periodically reviewed and updated in line with provider guidance and announced certificate authority changes

For the current TLS certificates visit the Azure Database for PostgreSQL documentation.

Use certificate validation modes that rely on standard CA-based trust rather than pinning

For PostgreSQL client configurations, prefer:

sslmode=verify-ca
- Validates the server certificate chain against trusted CAs
sslmode=verify-full
- Verifies CA and hostname match

These modes ensure that clients validate the server certificate chain against trusted CAs, and in stricter modes, verify hostname identity. They do not imply certificate pinning by themselves. They rely on standard CA-based trust.

Configurations only become rigid when trust is narrowly restricted, such as to a single certificate or limited CA set, often through custom or overly constrained trust stores. This effectively introduces certificate pinning.

When properly configured, these modes authenticate the service endpoint and protect against spoofing, while remaining resilient to certificate rotations.

Maintain a combined CA during certificate rotations

Azure may rotate root or intermediate CAs over time. When Azure announces a CA rotation:

Add newly required root CAs to the client trust store before the rotation begins.
Retain existing trusted root CAs until the transition is fully complete.
Avoid removing older root certificates prematurely.
If specific rotation guidance includes updates related to intermediate CAs, follow the service-specific instructions provided for that rotation.

This combined CA approach, using both the current and upcoming certificate authorities during the transition window, allows clients to continue validating the server certificate chain without interruption.

As you review your current client configurations, ensure your applications rely on CA-based trust, avoid overly restrictive certificate configurations such as certificate pinning, and are prepared to handle routine certificate rotations without disruption.

For a deeper dive, see the full article: TLS Certificate Pinning in PostgreSQL and MySQL: Risks, Rotations, and Best Practices.

Monitoring and using pg_repack in Azure Database for PostgreSQL flexible server

janvithac — Mon, 20 Jul 2026 14:19:52 GMT

In this post: we will walk through how to configure and use the pg_repack extension in Azure Database for PostgreSQL flexible server. We will also cover how to run pg_repack on a table, monitor the progress during execution, and validate the results after the repack operation is completed.

Why Monitor pg_repack During Execution?

While running pg_repack is straightforward, administrators often need visibility into what is happening behind the scenes, especially when working with large tables in production environments.

Monitoring the operation provides several benefits:

Verify that pg_repack is actively running and has not stalled.
Identify the current phase of the operation, such as table copying, index rebuilding, or final table swap.
Understand resource usage and the impact on the database.

Before you start:

Before performing this lab, ensure the following prerequisites are met:
Azure Resources:

An active Azure subscription
An Azure Database for PostgreSQL flexible server instance

Database Requirements:

A table with a PRIMARY KEY or UNIQUE NOT NULL index (required by pg_repack)

Linux Machine:

I have used an Ubuntu Linux Virtual Machine
SSH connectivity to the VM using PuTTY

Configuring and using pg_repack in Azure Database for PostgreSQL

Step 1: Allow list and create the pg_repack Extension

Before using pg_repack, the extension must be allowlisted and created in the target database. Navigate to your Azure Database for PostgreSQL flexible server and add pg_repack to the allow list of extensions. Once the server configuration is updated, connect to the database and create the extension.

Step 2: Create and connect to a Linux Virtual Machine

Since pg_repack is a client-side utility, a Linux virtual machine was created to install and run the pg_repack client against Azure Database for PostgreSQL flexible server.

Step 3: Connect to the Linux Virtual Machine

Before running pg_repack, I connected to the Linux virtual machine that would be used to install and execute the pg_repack client.

In the Azure portal, navigate to the Linux Virtual Machine.
Open PuTTY and enter the VM's IP Address.
Select SSH (Port 22) as the connection type and click Open.
Enter the VM username and password when prompted.
After successful authentication, a terminal session is established

The following output confirms that the connection was successful and that the Ubuntu operating system is ready for further configuration.

Step 4: Update Package Repositories on the Linux Virtual Machine

Before installing the pg_repack client, update the package repositories on the Ubuntu virtual machine to ensure the latest package information is available. Please run the following command and provide the password for the linux virtual machine when prompted.

sudo apt update

Step 5: Download the pg_repack

Important: If you face any version mismatch issue or errors then you can use the below command to resolve

After preparing the test environment and generating table bloat, the next step was to download the pg_repack source code to the Linux virtual machine.
The git clone command downloads the pg_repack source code from the official GitHub repository to the Linux virtual machine. This source code is later used to build and install the pg_repack client utility required to perform table reorganization operation. After downloading the repository, the cd pg_repack command changes the current directory to the downloaded project folder.

git clone https://github.com/reorg/pg_repack.git
cd pg_repack

Step 6: Install PostgreSQL Client Packages

After updating the package repositories, the next step was to install the PostgreSQL client packages on the Linux virtual machine. The PostgreSQL package installs the PostgreSQL client tools, including psql, which is used to connect to Azure Database for PostgreSQL flexible server.

sudo apt install postgresql postgresql-contrib

When the command is executed, Ubuntu displays a summary of the packages that will be installed along with their dependencies. To proceed with the installation, type Y and press Enter.

Step 7: Connect to Azure Database for PostgreSQL flexible server

After installing the PostgreSQL client packages on the Linux virtual machine, the next step is to establish a connection to the Azure Database for PostgreSQL flexible server using the psql client. Please update the following command with your server details and execute it and enter your PostgreSQL server user password to establish the connection. Note: Make sure your Linux machine network is allowed to connect on your Azure Database for PostgreSQL flexible server.

psql -h <Hostname> -p 5432 -U <username> postgres

Step 8: Create a Test Database

After successfully connecting to Azure Database for PostgreSQL flexible server, a dedicated database was created to perform the pg_repack lab activities as shown below:

Step 9: Connect to the Newly Created Database

After creating the repack_lab database, connect to it before proceeding with the pg_repack activities.

\c repack_lab

Step 10: Create a Sample Table for pg_repack Testing

After connecting to the repack_lab database, I created a sample table that would be used throughout the lab to test the functionality of pg_repack.

CREATE TABLE test_table (
id SERIAL PRIMARY KEY,
name TEXT,
created_at TIMESTAMP DEFAULT NOW()
);

Step 11: Insert Sample Data into the Test Table

After creating the test_table, the next step was to populate it with sample data. This helps simulate a realistic workload and provides enough records to demonstrate how pg_repack works. The following command was used to insert 100,000 rows into the table:

INSERT INTO test_table(name)
SELECT md5(random()::text)
FROM generate_series(1,100000);

Step 12: Create an Index on the Test Table

After populating the test_table with 100,000 records, an index was created as shown below:

CREATE INDEX idx_test_name
ON test_table(name);

Step 13: Check the Initial Table Size

Before generating table, bloat and running pg_repack, it is useful to capture the current size of the table. This serves as a baseline for comparing storage consumption before and after the repack operation.

SELECT pg_size_pretty(pg_total_relation_size('test_table'));

Step 14: Generate Table Bloat Using UPDATE Operations

To demonstrate how pg_repack reorganizes a table and reclaims unused space, the next step was to generate table bloat by repeatedly updating all rows in the table. The following command was executed multiple times:

UPDATE test_table
SET name = md5(random()::text);

Step 15: Disable Autovacuum on the Test Table

To clearly observe table bloat and demonstrate the effectiveness of pg_repack, autovacuum was temporarily disabled on the test table. This prevents Azure Database for PostgreSQL flexible server from automatically cleaning up dead tuples generated by the previous UPDATE and DELETE operations.

ALTER TABLE test_table
SET (autovacuum_enabled = false);

Step 16: Analyze Live and Dead Tuples Before Running pg_repack

After generating table bloat through multiple UPDATE and DELETE operations and disabling autovacuum, the next step was to measure the number of live and dead tuples in the table.

Step 17: Execute pg_repack to Reorganize the Table

The pg_repack utility was executed against the test table to reclaim unused space and reorganize the table structure. The pg_repack utility reorganizes tables and indexes online while minimizing locking and application downtime. Unlike VACUUM FULL, pg_repack performs the reorganization in the background and requires only a brief lock during the final table swap operation.

Command executed:

pg_repack \
--host=myflexibleserver.postgres.database.azure.com \
--port=5432 \
--username=dbadmin \
--dbname=repack_lab \
--table=test_table \
--jobs=2 \
--no-kill-backend \
--no-superuser-check

Monitoring pg_repack Execution

Once the pg_repack operation was initiated, the next step was to monitor its execution and identify the activities being performed by the utility in the background:

To track active pg_repack sessions, the following query was executed:

SELECT
pid,
usename,
application_name,
state,
wait_event_type,
wait_event,
now() - query_start AS running_for,
query
FROM pg_stat_activity
WHERE application_name ILIKE '%repack%'
OR query ILIKE '%repack%'
ORDER BY query_start;

After starting the pg_repack operation, I monitored the active sessions by querying the pg_stat_activity system view. This helped me understand the current stage of the operation and verify that the process was executing successfully. The query returned multiple sessions created by pg_repack, indicating that the utility was actively processing the table.

Session 1 - Lock Acquisition

LOCK TABLE public.test_table IN SHARE UPDATE EXCLUSIVE MODE

This session acquired a SHARE UPDATE EXCLUSIVE lock on the target table. This lock prevents conflicting schema changes while still allowing normal read and write operations during most of the repack process.

Session 2 - Temporary Repack Table Creation

SELECT 'repack.table_24861'::regclass::oid

At this stage, pg_repack was working with an internal temporary table created to hold the reorganized data. This table acts as a replacement for the original table during the repack operation.

Session 3 - Creating Primary Key Index

CREATE UNIQUE INDEX index_24869
ON repack.table_24861 USING btree(id)

This session shows pg_repack rebuilding the primary key index on the new table structure.

Session 4 - Creating Secondary Index

CREATE INDEX index_24873
ON repack.table_24861 USING btree(name)

This indicates that additional indexes are being recreated on the temporary table to match the original table definition.

Based on the output, the operation had successfully moved past the initialization phase and was actively rebuilding indexes on the temporary table. This is one of the final stages before pg_repack performs the table swap and completes the reorganization process.

Conclusion

In summary, monitoring pg_repack execution is essential for ensuring a smooth and efficient table reorganization process. Proper visibility into progress and resource consumption helps administrator complete maintenance tasks confidently while maintaining optimal database performance and availability.

References

Microsoft Defender CSPM Assessments for Azure Database for PostgreSQL Flexible Server - GA

TameikaL — Fri, 17 Jul 2026 20:18:23 GMT

As security and regulatory requirements evolve, proactively monitoring and assessing database security posture becomes just as important as detecting active threats. Maintaining a secure and compliant database environment requires continuous visibility into security gaps and configuration drift from established security baselines.

We're excited to announce the general availability of Microsoft Defender for Cloud Security Posture Management (Defender CSPM) assessments for Azure Database for PostgreSQL Flexible Server. These built-in assessments continuously evaluate PostgreSQL server configurations against PostgreSQL-specific security best practices, helping organizations identify vulnerabilities and misconfigurations and prioritize them based on the risk they pose.

The assessments provide actionable recommendations to help customers strengthen their security baseline, prioritize remediation efforts, and support compliance requirements. Findings are surfaced directly in Microsoft Defender for Cloud, enabling security and operations teams to proactively improve the security posture of their PostgreSQL workloads.

An initial set of PostgreSQL-focused assessments is included at launch, covering areas such as network security, auditing controls, and operational resilience. Additional assessment coverage is planned for future releases.

If you already have Microsoft Defender CSPM enabled on subscriptions that contain Azure Database for PostgreSQL flexible servers, no additional setup is required. Assessments are automatically available, provided a risk score and integrated into the existing Defender experience, making it easier to continuously monitor security posture and maintain alignment with organizational and industry security standards.

You can view assessment recommendations in the Azure portal on the resource blade of your Azure Database for PostgreSQL flexible server or the main Defender for Cloud experience, and the Microsoft Defender portal.

Learn more

Microsoft Defender CSPM assessments for Azure Database for PostgreSQL Flexible Server .

What is Microsoft Defender Cloud Security Posture Management?

Enable Defender CSPM

Microsoft Defender Azure Data Security Recommendations

June 2026 Recap: Azure Database for PostgreSQL

karlaescobar — Thu, 16 Jul 2026 19:06:43 GMT

POSETTE 2026
Features 💡
Azure PostgreSQL Learning Bytes 🎓
- Generate a pgBadger report from Server Logs

POSETTE 2026

We hosted POSETTE: An Event for Postgres 2026 in June! This year marked our 5th annual event featuring 50 speakers and a total of 44 talks. PostgreSQL developers, contributors, and community members came together to share insights on topics covering everything from AI-powered applications to deep dives into PostgreSQL internals. If you missed it, you can catch up by watching the POSETTE livestream sessions. If this conference sounds interesting to you and want to be part of it next year, don’t forget to subscribe to POSETTE news.

Features 💡

Chaos Studio Workspaces for Azure Database for PostgreSQL Flexible Server – Public Preview

Chaos Studio Workspaces now support Azure Database for PostgreSQL Flexible Server in Public Preview. You point a Workspace at a subscription or resource group, and Chaos Studio discovers your Flexible Server instances and recommends a PostgreSQL zone-down failover Scenario. The Scenario requires a Flexible Server with High Availability enabled. Running the Scenario simulates an availability-zone outage, drives an HA failover, and produces a Scenario report of exactly what happened.

Read more here: https://aka.ms/ChaosStudioPostgreSQL

Try it today: https://aka.ms/chaos-portal

Microsoft Defender Security Assessment for Azure Database for PostgreSQL - General Availability

Microsoft Defender security posture assessments for Azure Database for PostgreSQL Flexible Server are now generally available. Built-in assessments continuously evaluate PostgreSQL configurations against PostgreSQL-specific security best practices, helping identify vulnerabilities and misconfigurations with actionable remediation guidance. Customers can use these assessments to strengthen their security baseline, prioritize remediation efforts, and support compliance requirements.

Assessments are automatically available for servers already protected by Microsoft Defender for Cloud Security Posture Management (CSPM), with no additional setup required. An initial set of assessments is available today, with additional coverage planned for future releases to help strengthen the security posture of PostgreSQL workloads.

DROP CAST Support added

Custom casts can be useful when applications need to convert between data types in a way that matches their business logic or migration requirements.

Previously, while you could create custom casts, it wasn’t possible to drop them once they were no longer needed. With this update, you can now use the PostgreSQL DROP CAST command to clean up unused or obsolete casts, making it easier to manage schema customizations over time.

Example:

CREATE CAST (bigint AS text) WITH INOUT; … DROP CAST IF EXISTS (bigint AS text);

Latest PostgreSQL minor versions: 18.4, 17.10, 16.14, 15.18, 14.23

Azure Database for PostgreSQL now supports the latest PostgreSQL minor versions: 18.4, 17.10, 16.14, 15.18, and 14.23. These updates are applied automatically during planned maintenance windows, helping keep your databases current with the latest PostgreSQL community fixes and reliability improvements, with no manual action required.

This release includes fixes across query correctness, planner behavior, replication, backup and restore tooling, logical replication, foreign data wrapper behavior, and timezone data, improving overall stability and correctness of database operations.

For details about the minor release, see the PostgreSQL announcement.

Azure PostgreSQL Learning Bytes 🎓

Generate a pgBadger report from Server Logs

Need a quick workload readout from PostgreSQL logs? Use pgBadger with Azure PostgreSQL Server Logs.

Fast path: Server logs → Download '.log' files → Generate pgBadger report

Before collecting logs, set log_line_prefix in Server parameters:

%m user=%u db=%d pid=%p:

Then enable Server logs > Capture logs for download, download the .log files for the time window you want to analyze, place them in a local folder, and run:

FOLDER=<logs-folder-name> pgbadger -f stderr \ --prefix '%m user=%u db=%d pid=%p:' \ ./$FOLDER/*.log \ -o ./$FOLDER/pgbadger-report.html

Open the generated report:

start ./$FOLDER/pgbadger-report.html

This gives you a quick HTML report for query activity, connection patterns, events, lock waits, and workload spikes - without setting up a storage account, BlobFuse mount, or JSON extraction pipeline.

💡Tip: Start with one or two hourly log files first. Confirm the report looks right, then expand the log analysis window.

Learn more: Log Insights in Minutes: A Simpler pgBadger Workflow

PostgreSQL on Azure: Two services, one future-proofed ecosystem

charlesfeddersenMS — Tue, 14 Jul 2026 15:00:00 GMT

At Microsoft Build 2026, the Azure Databases team announced the public preview of Azure HorizonDB, a new powerhouse for PostgreSQL in the cloud. It’s a fully managed, PostgreSQL-compatible cloud database service that delivers sub-millisecond latency, rapid read scale-out, and seamless integration with Microsoft Foundry to empower teams to build secure, compliant and high-performing applications with confidence. At the same event, we also announced several enhancements to the existing managed PostgreSQL offering, Azure Database for PostgreSQL flexible server, boosting performance, analytics and security, and expanding tooling for migration scenarios.

Where there was one, now there’s two

Now our customers have two strong options to choose from. Azure Database for PostgreSQL remains a reliable, cost-effective, fully open-source compatible workhorse for most users’ everyday needs. Azure HorizonDB is the new PostgreSQL-compatible service with an elastic scale-out architecture built on a highly optimized shared storage system that unlocks 3x faster OLTP performance and other cloud-native advantages for the most demanding workloads.

With this new service, you might be wondering which service is the best fit. Let’s take a closer look at these options and explore where they align and differ and what you might want to consider when making your choice.

Azure Database for PostgreSQL: Enterprise ready, managed open source

Microsoft is one of the largest contributors to the open-source Postgres project and has also invested heavily in PostgreSQL managed services on Azure. Microsoft engineers have authored or co-authored hundreds of code commits and provided extensive reviews, and, to date, have made more than 345 commits and changed more than 64K lines of code for PostgreSQL 19. In the cloud, Azure Database for PostgreSQL is built on the open-source ecosystem, sharing the same extensions and experience that developers and DBAs know and love. Patching, backups, scaling, and monitoring are all simple, one-click operations. If you have an app that already uses a PostgreSQL database, in another cloud or on-premises, migrating to Azure for the added benefits is an easy lift and shift.

Inside Azure Database for PostgreSQL

Azure Database for PostgreSQL is a mature, feature-rich service already battle-tested by thousands of applications and being used by Fortune 500s across sectors.

Enterprise-grade performance: Compute tiers can scale up to 192 vCores with features like read replicas and elastic clusters, which is based on the open-source Citus extension and unique to this class of service, make it easy to right-size workloads and optimize performance by offloading read-heavy traffic or sharding data across nodes.

Reliability and security: Backed by Azure’s robust infrastructure, Azure Database for PostgreSQL comes equipped with high availability and zone-redundant options, point-in time restore and security features, including data encryption, network isolation, and Entra ID for enterprise identity.

Frictionless migrations: Migrating existing PostgreSQL workloads to Azure Database for PostgreSQL is very straightforward thanks to built-in migration tooling. We’ve even launched AI-assisted tooling for Oracle to PostgreSQL migrations in VS Code, which leverages GitHub Copilot AI to handle app and schema conversions and pre-migration validations.

From incorporating cutting-edge hardware, horizontal scaling and Microsoft Fabric and Microsoft Foundry integrations, to supporting 90+ open-source extensions and counting, we continue to optimize the service to meet the needs of our customers building on open-source Postgres.

Azure HorizonDB: Next-gen engine to build what’s next

Azure HorizonDB was designed and purpose-built to meet the needs of modern AI-native applications and large-scale enterprise migrations. Shireesh Thota, Azure Databases CVP, describes it as the database of choice for workloads that need “a lot of storage, want really fast latencies and significantly higher IOPS.” The service offers faster throughput than open-source PostgreSQL and rapid compute scale-out to support the performance and availability needs of your most demanding applications.

Inside Azure HorizonDB

Azure HorizonDB is where performance meets possibility, empowering teams to build intelligent apps to scale, modernize, and innovate without compromise.

Cloud-tuned performance: The cloud-native architecture of Azure HorizonDB fully decouples compute and storage, enabling users to scale database resources independently. The service can support deployments up to 3,072 vCores and 128 TB of shared storage for a single workload, and provides a single endpoint for read replicas with transparent load balancing to deliver massive read throughput seamlessly to the application.

Reliability and security: Azure HorizonDB comes standard with features to support production-level, mission-critical enterprise workloads. Built-in multi-availability zone (AZ) replication reduces failover time to less than 5 seconds, and native integration with Microsoft Entra ID and private endpoint networking ensures Azure HorizonDB meets the Azure-standard enterprise-grade security from day one.

Tailored for AI and next-gen apps: Azure HorizonDB provides an extensive set of AI features for building modern applications. In comparison to similar PostgreSQL services in the cloud, IDC described Azure HorizonDB as having "fewer moving parts and a straighter path to AI features.” Azure HorizonDB ships with Microsoft’s latest version of DiskANN vector indexing, which includes advanced filtering that delivers up to 3x faster vector search than traditional pgvector indexes. It also comes with built-in AI Model Management for native integration to Microsoft Foundry models, AI Functions to invoke models from SQL, and AI Pipelines to provide durable orchestration of data modification.

Developer productivity: Along with building the best Postgres service, Microsoft is committed to delivering the best Postgres developer tools to the entire community. The Microsoft PostgreSQL extension for Visual Studio (VS) Code makes the coding environment Postgres-aware to help optimize queries, schemas and query performance using AI.

Azure HorizonDB is the next-generation of PostgreSQL on Azure for mission-critical, high-throughput, and data-intensive workloads. For everything else, Azure Database for PostgreSQL remains a strong choice.

Making your selection

Adopting technology should always be driven by a real need. Having two choices is great, but it raises the logical question: “which one is right for me and when?”

Choose Azure Database for PostgreSQL when:

You’re migrating existing Postgres databases as-is. You can migrate seamlessly to Azure Database for PostgreSQL with minimal tweaks or reconfigurations.

You require full open-source compatibility, including rapid adoption of new community versions. Azure Database for PostgreSQL now ships major versions on the same day as the community release.

You want to start now and decide later. Azure Database for PostgreSQL is generally available in 60+ regions today. Later, if your project requires greater scale, you can upgrade to Azure HorizonDB, and the migration process will be quick and easy.

Choose Azure HorizonDB when:

You’re migrating tier-1 workloads to the cloud that already have critical scale, performance, and availability requirements. Up to 128 TB of storage and 3,072 vCores for a single workload makes Azure HorizonDB the ideal destination for these workloads.

You anticipate requirements that go beyond Azure Database for PostgreSQL’s capabilities. Azure HorizonDB expands on the capabilities of Azure Database for PostgreSQL, so you’ll be future proofed for scale and reliability.

You are focused on building next-gen intelligent apps. Azure HorizonDB is optimized for building new AI applications, enabling developers to ship faster with fewer moving parts.

Both services are built on the core Postgres engine, and upgrading to Azure HorizonDB is easy. If your scenario changes, your toolkit can change too. Azure offers the managed service to support you either way.

Choose the cloud with the deepest Postgres expertise

The PostgreSQL ecosystem on Azure is richer than ever. With both Azure Database for PostgreSQL and Azure HorizonDB, Azure covers the spectrum from steady, everyday workloads to cutting-edge, innovative ones. Whether you’re in a two-person startup or a Fortune 500 enterprise, PostgreSQL on Azure can meet your business’ needs.

Now is the perfect time to make a move to Postgres on Azure:

Learn more about Azure Database for PostgreSQL

Learn more about Azure HorizonDB

From RAG to agents: Build AI pipelines inside Azure HorizonDB

abeomor-msft — Thu, 02 Jul 2026 16:52:43 GMT

By Abe Omorogbe, Navya Teja Gajula, Binnur Gorer, B Harsha Kashyap, Krishnakumar Ravi (KK) from Microsoft PostgreSQL AI team

If you’ve ever shipped a RAG app, this will feel familiar. Your data lives in Postgres. But the pipeline that turns that data into vectors lives somewhere else, spread across external services, queues, and retry logic. And when the embedding API hiccups mid-batch? That’s a 2 a.m. production incident. You didn’t set out to build your own embedding service. You just wanted to search your documents.
And RAG is only the beginning. The moment AI works on your data: extraction, summarization, reranking, keeping embeddings fresh, or powering agent, you’re back to stitching together more services, queues, and glue code, all outside the database.

AI pipelines in Azure HorizonDB (Preview) removes that entire stack. Define your workflows steps like chunking, embeding, extracting, and generating in SQL, and HorizonDB runs them as AI pipelines next to your data. No orchestrator. No glue code. Just Postgres.

In this post we'll cover:

The external-orchestrator issue that every AI on Postgres team eventually hits
What AI pipelines are, and the four-part anatomy that makes them click
Use cases worth trying: semantic search, knowledge extraction, content generation, smarter reranking, and always-fresh embeddings
How to watch your pipelines run as live graphs in VS Code
How to spin up HorizonDB and run your first pipeline today

🚀 Try it on Azure HorizonDB. AI pipelines are built into Microsoft's new PostgreSQL cloud service, no extra infrastructure to stand up. Write ai.create_pipeline(...), call ai.run(...), and it runs. Get started in HorizonDB →

AI preprocessing runs outside the database, far from your data

The standard way to get data into a vector store looks reasonable on a whiteboard: a service reads source rows, calls an embedding API, and writes chunks back to Postgres. However, some interesting issues often occur in production.

The embedding API fails mid-batch, and there's no shared checkpoint showing which rows were completed. You rerun the job, and the extra API calls increases cost.
A worker crashes after writing chunks but before flipping the parent row's processed flag. Now your embeddings are quietly inconsistent, and nobody knows.

Every one of these is the same missing primitive: durable, checkpointed execution that lives where your data lives. External orchestrators can do it, but now you're operating a second service just to feed the first one.

AI pipelines move that logic into HorizonDB itself. The source, the steps, the sink, and the full run history are all SQL protected by the same transactions, backups, and point-in-time restore your data already has. The database is already where your data commits. It's a natural place for the pipeline to live too.

Anatomy of an AI pipeline in HorizonDB

AI Pipeline in HorizonDB, the steps are optional and can be adjusted as needed.

A pipeline has four parts:

Source: where rows come from. A table_source(...) over a HorizonDB table, optionally with an incremental_column so the pipeline skips rows it already processed.
Steps: the AI operations that transform each row, in order. Each step appends columns to the in-flight batch.
Sink: where results land, ready for use by your AI apps or agent.
Trigger: 'on_change' (run automatically when source rows change) or 'manual' (run only when you call ai.run()).

Those four parts give the pipeline its shape. The steps are where you define the AI work itself, using composable building blocks:

Step	What it does
ai.chunk()	Split long text into overlapping chunks
ai.embed()	Generate vector embeddings
ai.extract()	Pull structured fields out of text with an LLM
ai.generate()	Generate text from a prompt (i.e content generation, classify, summarize and more)
ai.rank()	Score documents against a query

How the pieces fit together. The ai.* API gives you the AI pipeline shape: sources define where data comes from, steps define the AI work to perform, sinks define where results land, and triggers define when the pipeline runs. Under the covers, HorizonDB turns that definition into a durable execution graph, where each step can be checkpointed, retried, and resumed if something fails.

Built on open source. That durability isn't magic, every AI pipeline compiles down to a graph that runs on pg_durable, Microsoft's open-source durable-execution engine for PostgreSQL (built on the duroxide Rust runtime). The ai.* API is the AI-shaped surface (sources, steps, sinks, triggers) and pg_durable is the general-purpose engine underneath that handles checkpointing, retries, and crash recovery. So, your pipelines stand on a transparent, inspectable foundation you can read, and run on any Postgres 17 & 18. No black box, no lock-in.

Use case 1: Semantic search over your data

This is one of the most popular use cases. Turn a table of documents into searchable vectors, durably, and keep them fresh as the data changes. That last part matters: in production, documents are edited, added, and deleted constantly, and every change needs the right chunks and embeddings updated without reprocessing the entire corpus or leaving stale vectors behind. With AI pipelines, HorizonDB can track those incremental updates for you. Chunk the body, embed each chunk, and land the result in a DiskANN-indexed table.

-- Define the pipeline: source -> chunk -> embed -> sink. SELECT ai.create_pipeline( name => 'rag_pipeline', source => ai.table_source(table_name => 'documents'), steps => ARRAY[ ai.chunk(input => 'content', chunk_size => 512, overlap => 64), ai.embed(model => 'default-embedding', input => 'chunk_text', dimensions => 1536) ], trigger => 'on_change', -- re-embed automatically as rows change sink => ai.table_sink('rag_pipeline_output') ); -- Run it SELECT ai.run('rag_pipeline'); -- Search your data SELECT chunk_text, embedding <=> azure_openai.create_embeddings('text-embedding-3-small', 'how does vector search work?')::vector AS distance FROM rag_pipeline_output ORDER BY distance LIMIT 3;

That's the entire ingestion layer; chunking, embedding, checkpointing, retries, and sink writes in one definition. Because trigger => 'on_change', the pipeline updates embeddings whenever source rows change, processing only what is new or modified instead of redoing the whole corpus. Your vectors stay in sync with your data, and your ingestion work stays efficient as the dataset grows. Point a query at the DiskANN index and you've got production semantic search without a single line of application glue.
That's the whole loop: define, run, inspect. The embedding service you were about to build the queue, the workers, the retry logic, the checkpoint table, the 2 a.m. production incident doesn't happens.

Why it's better than an external service: a failure in ai.embed() never re-runs ai.chunk(), each step is a durable node. If the database restarts mid-run, it resumes from the last checkpointed batch, not row zero.

Use case 2: Turn unstructured text into structured metadata

Support tickets, contracts, product reviews, research papers are full of structure that's locked inside unstructured documents. ai.extract() pulls named fields out of text and merges them into the metadata JSONB column, so you can filter and aggregate on things an LLM read for you.

SELECT ai.create_pipeline( name => 'extraction_pipeline', source => ai.table_source(table_name => 'documents'), steps => ARRAY[ ai.chunk(input => 'content'), ai.extract( input => 'chunk_text', data => ARRAY['topics: string - the main topics discussed', 'entities: string - named people, products, or places'] model => 'my-gpt' -- optional, the default model when AI model management is activate ) ], sink => ai.table_sink('extraction_pipeline_output') ); SELECT ai.run('extraction_pipeline'); -- Now query the structured fields the LLM extracted: SELECT doc_id, metadata->'topics' AS topics, metadata->'entities' AS entities FROM extraction_pipeline_output;

You describe each field as a label: description string in the ai.extract step, and HorizonDB does the rest durably, in bulk, with the same retry-and-resume guarantees.

Each field is a label, either a bare name like product, or the detailed form name: type - description (for example `sentiment: number - sentiment score from 1 to 5`). HorizonDB does the rest, durably, in bulk, with the same retry-and-resume guarantees.

Use case 3: Summarize and rewrite content at scale

ai.generate() runs an LLM prompt against every row, perfect for bulk summarization, classification, tone normalization, or generating titles. Because it's a pipeline, "summarize 4 million documents" becomes a job that survives restarts instead of a script you have to monitor overnight.

SELECT ai.create_pipeline( name => 'summary_pipeline', source => ai.table_source(table_name => 'documents'), steps => ARRAY[ ai.chunk(input => 'content'), ai.generate( input => 'chunk_text', system_prompt => 'Create a concise summary in 50 words or fewer.' model => 'my-gpt' -- optional, the default model when AI model management is activate ) ], sink => ai.table_sink('generation_pipeline_output') ); SELECT ai.run('summary_pipeline'); -- Now query the generated text: SELECT doc_id, left(generated_text, 100) AS summary_preview FROM generation_pipeline_output WHERE generated_text IS NOT NULL LIMIT 5;

Swap the system_prompt and the same shape becomes a classifier ("Label this ticket as billing, bug, or feature request"), a translator, or a headline generator. The instruction goes in system_prompt; the result lands in generated_text.

Use case 4: Keep embeddings fresh, and re-embed cleanly when the model changes

This is where AI pipelines become especially useful. In a real AI app, two things change constantly: your data and your model. AI pipelines are designed to handle both changes directly.

Your data changes. Set incremental_column and an on_change trigger, and the pipeline only embeds new or changed rows, automatically, forever, until you pause or drop it.

SELECT ai.create_pipeline( name => 'rag_pipeline', source => ai.table_source( table_name => 'documents', incremental_column => 'updated_at' -- only process what changed ), steps => ARRAY[ ai.chunk(input => 'content'), ai.embed(model => 'default-embedding', input => 'chunk_text', dimensions => 1536) ], trigger => 'on_change', sink => ai.table_sink('rag_pipeline_output') );

Your model changes. Bump the model or the dimensions, then run a single, resumable backfill, no migration script, no babysitting:

TRUNCATE rag_pipeline_output; SELECT ai.backfill('rag_pipeline');

The backfill runs as one durable instance. If the database restarts mid-backfill, it picks up from the last checkpointed batch instead of starting over. The painful "re-embed everything" migration becomes a one-liner you can actually trust.

Watch your pipelines run as live graphs in VS Code

A pipeline you can see is a pipeline you can trust. Install the PostgreSQL extension for VS Code, connect to HorizonDB, then right-click your database and open Pipelines & Workflows → AI Pipelines.

AI Pipelines in HorizonDB

Select any run and the center pane renders the execution as a color-coded graph:

Blue 🔵 : source and sink (where data enters and exits)
Green 🟢 : processing steps (chunk, embed, extract, generate, rank)
Pink 🟣 : external model and service calls

For each run you can read the status (completed, running, failed), the run ID for traceability, start time and duration for performance, and a link back to the pipeline definition. When a run fails, open the graph and jump straight to the step where execution stopped, no log spelunking.

Get Started: Try It Now

We have a few demoes of AI pipelines in action:

Resource	Link
Microsoft Build AI Pipeline Demo	Simplify app dev with cloud-native PostgreSQL in Azure HorizonDB \| DEM364
Microsoft Build AI Pipeline GitHub	AI Pipelines Demo GitHub Repo \| DEM364
Microsoft Mechanic Demo	AI Pipeline Demo on Microsoft Mechanic
Documentation	AI pipelines on HorizonDB

Enabling AI pipelines takes minutes: enable to azure_ai, pg_durable, vector and pg_diskann extensions and you can get started.

-- On Azure HorizonDB — the extensions are built in. CREATE EXTENSION IF NOT EXISTS pg_durable; CREATE EXTENSION IF NOT EXISTS azure_ai; CREATE EXTENSION IF NOT EXISTS vector; CREATE EXTENSION IF NOT EXISTS pg_diskann;

That's it, your PostgreSQL database can now run AI pipelines

Learn more

MS Learn AI pipelines on HorizonDB:

Azure HorizonDB Preview

pg_durable on GitHub (open source)

MS Learn Durable Functions on HorizonDB

Scalable vector search with DiskANN

PostgreSQL extension for VS Code

Log Insights in Minutes: A Simpler pgBadger Workflow

varun-dhawan — Thu, 30 Jul 2026 18:18:19 GMT

Sometimes the fastest way to understand a PostgreSQL workload is not another dashboard. It is a good log report.

pgBadger is a PostgreSQL log analysis tool that turns raw PostgreSQL logs into an interactive HTML report. It helps summarize query activity, connection patterns, errors, temporary files, lock waits, autovacuum activity, and more.

Earlier guidance for generating pgBadger reports from Azure Database for PostgreSQL Flexible Server focused on exporting logs through Diagnostic Settings, storing them in a storage account, and then using tools such as BlobFuse and jq to extract PostgreSQL log lines from JSON files.

That workflow is still useful when customers centralize logs across multiple servers. However, if you are already using the Server logs feature in Azure Database for PostgreSQL Flexible Server, there is a much simpler path.

In this post: You’ll learn how to generate a pgBadger HTML report from Azure Database for PostgreSQL Flexible Server by downloading native PostgreSQL .log files directly from the Azure portal. No storage account, BlobFuse mount, or JSON extraction required.

Fast path

Configure log_line_prefix.
Enable Server logs for download.
Download the PostgreSQL .log files.
Run pgBadger with the matching prefix.
Open pgbadger-report.html.

Why use this workflow?

With Server logs, you can download native PostgreSQL .log files directly from the Azure portal and run pgBadger locally.

Older path	Simpler path in this blog
Diagnostic Settings → Storage account → BlobFuse → JSON extraction → pgBadger	Server logs → Download `.log` files → pgBadger

Area	Older Diagnostic Settings workflow	Server logs workflow
Export path	Diagnostic Settings to storage account	Download `.log` files directly from the portal
Format	JSON payloads need extraction	Native PostgreSQL `.log` files
Extra tooling	BlobFuse and `jq` JSON parsing	None
Best suited for	Centralized or multi-server logging	Quick per-server analysis
Outcome	Flexible, but more setup	Faster path to pgBadger

Recommended: Use the Server logs workflow when you want a fast, low-friction way to generate a pgBadger report from one Azure Database for PostgreSQL Flexible Server.

When should you use this workflow?

Use this workflow when...	Use Diagnostic Settings when...
You need a quick report for one Flexible Server.	You centralize logs from many servers.
You want to run pgBadger locally.	You need long-term retention or workspace-level querying.
You want to avoid JSON extraction.	You already have automated log export pipelines.

Before you start

A machine where you can install or run pgBadger.
A working Perl runtime.
Git Bash on Windows, so the multi-line shell commands work as shown.
Portal access to your Azure Database for PostgreSQL Flexible Server.
Permission to update server parameters and enable Server logs.

Important: pgBadger can only analyze what PostgreSQL logs capture. To populate query timing and slow-query sections in the report, enable log_min_duration_statement before collecting logs. Logs collected before that change will not include duration data.

Workflow overview

Task	Type	Rough effort
Install or prepare pgBadger	One-time setup per analysis machine	5–10 minutes
Configure `log_line_prefix`	One-time setup per server	2–3 minutes
Enable Server logs	One-time setup per server	2–3 minutes
Download logs and run pgBadger	Repeatable	2–5 minutes

Install or prepare pgBadger on the machine where you will analyze logs.
Configure log_line_prefix so pgBadger can parse each log line.
Enable Server logs, so PostgreSQL logs are available for download.
Download the logs and run pgBadger locally.

💡Pro tip: Start with a narrow log window first. Use one or two hourly log files, confirm the report looks right, and then expand the analysis window if needed.

Step 1: Install pgBadger

Before generating a report, you need pgBadger available on the machine where you plan to analyze the downloaded PostgreSQL log files. Run this on a Linux VM, WSL, or another Linux-based environment where you can install packages.

Note: Azure Cloud Shell may work for quick testing, but package installation and build-tool availability can vary by session. For repeatable analysis, use a Linux VM, WSL, or another environment you control.

Copy and run

sudo apt-get update && sudo apt-get install -y git perl make gcc && \
git clone https://github.com/darold/pgbadger.git && \
cd pgbadger && \
perl Makefile.PL && \
make && \
sudo make install && \
pgbadger -V

What good looks like: The install command completes successfully and pgbadger -V returns the installed pgBadger version.

Step 2: Configure `log_line_prefix`

This is a one-time server configuration step.

The log_line_prefix parameter controls the beginning of each PostgreSQL log line. pgBadger uses this prefix to extract useful fields such as timestamp, user, database, and process ID.

In the Azure portal, open your Flexible Server and go to Server parameters. Search for:

Parameter

log_line_prefix

Set this value

%m user=%u db=%d pid=%p:

Then select Save.

In Server parameters, confirm that the custom value is saved for log_line_prefix.

Figure 1: Set log_line_prefix so pgBadger can correctly parse timestamp, user, database, and process ID from each log line.

Prefix tokens

Token	Meaning
`%m`	Timestamp with milliseconds
`%u`	Username
`%d`	Database name
`%p`	Process ID

After this change, log lines should look like this:

Example log line

2026-06-22 19:00:00.070 UTC user=pgadmin db=highcpu pid=3805603: LOG: statement: SELECT 1 FROM pg_extension WHERE extname='pg_stat_statements'

The matching pgBadger prefix for this log format is:

Matching pgBadger prefix

%m user=%u db=%d pid=%p:

You will use this same value later in the pgBadger command.

What good looks like: The server parameter is saved, and new PostgreSQL log lines begin with timestamp, user, database, and process ID fields that match the pgBadger prefix.

Step 3: Enable Server logs for download

This is also a one-time setup step.

In the Azure portal, open your Flexible Server and go to Server logs. Enable:

Portal setting

Capture logs for download

Set the retention period based on how long you want logs to remain available for download. For example, a 7-day retention period keeps logs available for download for 7 days.

In Server logs, enable Capture logs for download and choose the retention window.

Figure 2: Enable Capture logs for download and set a retention period long enough to cover the analysis window you want to inspect.

What good looks like: After Server logs are enabled, hourly PostgreSQL log files appear in the Server logs blade and can be downloaded from the Azure portal.

Once enabled, hourly log files appear in the Server logs blade. The files are named by date and hour, for example:

Example log files

postgresql_2026_06_22_19_00_00.log
postgresql_2026_06_22_20_00_00.log

Step 4: Download and organize the logs locally

From the Server logs page, select the .log files for the time window you want to analyze and download them.

For example, to analyze activity between 19:00 and 21:00 UTC, download:

Example files to download

postgresql_2026_06_22_19_00_00.log
postgresql_2026_06_22_20_00_00.log

On your local machine, create a folder for that analysis window. A simple convention is to use the Mon-DD format.

Folder name

Jun-22

Place the downloaded .log files inside that folder. Your local folder structure should look like this:

Folder structure

pgbadger-13.1/
  pgbadger
  Jun-22/
    postgresql_2026_06_22_19_00_00.log
    postgresql_2026_06_22_20_00_00.log

Step 5: Generate the pgBadger report

Open Git Bash from the folder where pgBadger is located. For example, if pgBadger is inside the pgbadger-13.1 folder, open Git Bash from that folder.

#	Action	Command
1	Set the folder	`FOLDER=Jun-22`
2	Confirm files	`ls -lh ./$FOLDER`
3	Run pgBadger	Use the full command below.

Copy and run

FOLDER=Jun-22

ls -lh ./$FOLDER

perl -X ./pgbadger -f stderr \
  --prefix '%m user=%u db=%d pid=%p:' \
  ./$FOLDER/*.log \
  -o ./$FOLDER/pgbadger-report.html

Command breakdown

Part of command	Purpose
`perl -X ./pgbadger`	Runs pgBadger and suppresses non-critical Perl warnings.
`-f stderr`	Parses PostgreSQL stderr log files.
`--prefix '%m user=%u db=%d pid=%p:'`	Matches the `log_line_prefix` set on the server.
`./$FOLDER/*.log`	Analyzes every `.log` file in the selected folder.
`-o ./$FOLDER/pgbadger-report.html`	Writes the HTML report into the same folder.

When the command completes successfully, you should see output like this:

Expected output

Parsed 12134249 bytes of 12134249 (100.00%), queries: 26684, events: 83
LOG: Ok, generating html report...

What good looks like: pgBadger finishes parsing the logs and creates pgbadger-report.html in the selected folder.

Step 6: Open the report

Open the generated report:

Copy and run

start ./$FOLDER/pgbadger-report.html

The report opens in your default browser. The final report is created here:

Generated report path

Jun-22/pgbadger-report.html

What the report can show

The pgBadger report gives you a quick view into the workload shape for the selected log window. For example, in a sample run across two hourly log files, pgBadger summarized:

Total number of queries.
Number of unique normalized queries.
Query traffic over time.
Events such as errors and fatal messages.
Session and connection patterns.

Once the report opens, start with Global Stats to confirm the time range, total queries, normalized queries, and query peak.

Figure 3: Start with Global Stats to validate the selected time range, total query count, normalized query count, and query peak.

Query volume and normalized queries

Many raw queries can often reduce to a smaller number of normalized query patterns. This helps identify whether the workload is spread across many different query shapes or dominated by a smaller set of repeated statements.

Example: In this sample run, 26,684 queries reduced to 59 normalized query shapes. That suggests the workload is mostly a small set of repeated statements, which can help focus tuning effort.

Traffic patterns

The SQL Traffic section helps identify spikes, quiet periods, and workload changes over time.

Figure 4: Use SQL Traffic to identify query spikes, quiet periods, and workload changes during the selected log window.

Figure 5: Review the query breakdown to compare read vs. write volume and query-type distribution for the selected Server logs window.

For example, if the report shows a steady baseline followed by a sharp spike, that spike can be correlated with application activity, batch jobs, synthetic tests, or operational events during the same time window.

Query duration

If query duration shows 0 ms or the slow query sections are empty, it usually means duration logging was not enabled when the logs were collected.

In that case, pgBadger can still show query counts and events, but it cannot calculate the slowest queries, total execution time, average duration, or maximum duration.

To unlock those timing sections, enable log_min_duration_statement, collect fresh logs, and rerun pgBadger.

What pgBadger cannot infer from missing logs

pgBadger reports are only as complete as the log data you provide. If PostgreSQL did not log duration, lock waits, temporary files, or autovacuum activity during the selected time window, pgBadger cannot reconstruct those details later.

To analyze...	Enable before collecting logs
Slow queries	`log_min_duration_statement`
Lock waits	`log_lock_waits`
Temporary files	`log_temp_files`
Autovacuum activity	`log_autovacuum_min_duration`

Repeatable copy/paste block

Reusable command block

Change only FOLDER for each new analysis window.

Copy and run

FOLDER=Jun-22

ls -lh ./$FOLDER

perl -X ./pgbadger -f stderr \
  --prefix '%m user=%u db=%d pid=%p:' \
  ./$FOLDER/*.log \
  -o ./$FOLDER/pgbadger-report.html

start ./$FOLDER/pgbadger-report.html

For another date, change only this line:

Update this value

FOLDER=Jun-22

Examples:

Example folder values

FOLDER=Jun-23
FOLDER=Jul-01
FOLDER=Aug-15

Optional: Improve report quality

pgBadger can only analyze the information captured in PostgreSQL logs.

The default logs may be enough for query frequency, connection activity, and errors. For deeper performance troubleshooting, consider enabling additional logging parameters based on your scenario.

Scenario	Parameter	Suggested value	Notes
Slow query analysis	`log_min_duration_statement`	`1000`	Logs statements slower than 1 second.
Short controlled test	`log_min_duration_statement`	`0`	Logs every statement. Use carefully.
Lock troubleshooting	`log_lock_waits`	`on`	Helps identify lock waits.
Temporary file analysis	`log_temp_files`	`0`	Logs all temporary files.
Autovacuum visibility	`log_autovacuum_min_duration`	`0`	Useful during focused analysis.

Useful parameters include:

Recommended logging parameters

log_lock_waits = on
log_temp_files = 0
log_autovacuum_min_duration = 0

To capture query durations, configure:

Duration logging

log_min_duration_statement = 1000

This logs statements that run longer than 1000 milliseconds.

For short test runs, you can temporarily use:

Short test run only

log_min_duration_statement = 0

Caution: Use log_min_duration_statement = 0 carefully on busy production servers. It logs every statement and can generate a large volume of logs.

Duration matters: If duration logging is not enabled, pgBadger can still show query counts and events, but slowest-query, total duration, average duration, and maximum duration sections will be limited or empty.

Common mistakes and quick fixes

Symptom	Likely cause	Fix
Report is empty	Prefix mismatch	Match `--prefix` with `log_line_prefix`.
No duration data	Duration logging was not enabled	Set `log_min_duration_statement` before collecting logs.
No files visible	Server logs disabled or retention expired	Enable capture and check retention.
pgBadger command fails	pgBadger is not in the current folder or path	Run `pgbadger -V` to confirm installation.

Common troubleshooting FAQs

1. Report is created but empty

This usually means the pgBadger prefix did not match the actual log format.

Check the first few lines:

Copy and run

head -5 ./$FOLDER/*.log

Make sure the pgBadger --prefix matches the server’s log_line_prefix.

2. Report shows queries but no duration

PostgreSQL logged statements but did not log durations.

Enable one of the following, collect fresh logs, and rerun pgBadger:

Parameter options

log_min_duration_statement = 1000

# or temporarily for testing
log_min_duration_statement = 0

3. No `.log` files are visible

Confirm that Server logs are enabled:

Portal setting

Capture logs for download

Also check the retention period. If the retention period has expired, older logs may no longer be available for download.

4. pgBadger command fails

Confirm that pgBadger is available in the current folder or installed in your path.

Copy and run

pgbadger -V

If you are running pgBadger from the local folder, use:

Copy and run

perl -X ./pgbadger

Summary

For customers already using Azure Database for PostgreSQL Flexible Server logs, the pgBadger workflow is straightforward:

Install pgBadger.
Configure log_line_prefix.
Enable Server logs for download.
Download the .log files.
Place them in a local date-based folder.
Run pgBadger with the matching prefix.
Open pgbadger-report.html.

Bottom line: Server logs give you the shortest path from Azure Database for PostgreSQL Flexible Server logs to a pgBadger report. Download the native .log files, run pgBadger with the matching prefix, and open the generated HTML report.

References

Take control of your PostgreSQL maintenance

jasomaning — Fri, 26 Jun 2026 22:21:20 GMT

Maintenance is an important part of keeping Azure Database for PostgreSQL flexible server secure, reliable, and up to date. It helps deliver platform updates, security patches, operating system updates, and PostgreSQL engine updates that keep servers running smoothly.

But we also know that timing matters.

For teams running production workloads, a maintenance event during peak traffic, a migration, financial close, a major release, or a seasonal business event can create unnecessary stress. Even a brief restart or connection interruption can affect applications, customers, and business operations.

That’s why we’re excited to share that new self-service maintenance controls for Azure Database for PostgreSQL flexible server are now generally available in the Azure portal.

With these new capabilities, customers can see upcoming maintenance, reschedule eligible planned maintenance to a preferred date and time, apply maintenance when they’re ready, and review maintenance history after events complete.

Why we built this

Azure Database for PostgreSQL flexible server already offers maintenance scheduling options through Custom Maintenance Windows (CMW) and System-managed Maintenance Windows (SMW). These options give you a starting point for controlling when maintenance updates are applied.

But customers told us they needed more flexibility after a specific maintenance event was scheduled.

Sometimes the original maintenance time still lands during a critical business period. In the past, customers who needed to defer maintenance often had to open a support request. That added time, extra coordination, and operational overhead for something many teams wanted to handle directly.

With this release, you now have more control from the Azure portal.

What’s new

The new maintenance experience introduces four key capabilities.

1. View upcoming maintenance

You can now view upcoming maintenance before it begins. This gives teams a clearer view of when maintenance is scheduled, what type of maintenance is planned, and whether the event can be rescheduled.

To view upcoming maintenance:

In the Azure portal, go to your Azure Database for PostgreSQL flexible server.
On the server Overview page, review the Next Maintenance field.

Figure 1: View upcoming maintenance

If upcoming maintenance is available, the Next Maintenance field displays the scheduled maintenance time.

Select the Next Maintenance value to open the Maintenance page.
On the Maintenance page, review the Maintenance status section.

The Maintenance status section shows upcoming maintenance events that apply to your server, including the scheduled time, status, maintenance type, and available actions.

Instead of reacting at the last minute, database administrators and application teams can plan ahead with more confidence.

2. Reschedule maintenance to a preferred date and time

For eligible maintenance events, you can reschedule planned maintenance to a preferred date and time up to two weeks later.

To reschedule maintenance:

In the Azure portal, go to your Azure Database for PostgreSQL flexible server.
In the left menu, under Settings, select Maintenance.
In the Maintenance status section, review the upcoming maintenance event.
If the event is eligible, select Reschedule.
Choose an eligible future date and time.

Figure 2: Reschedule maintenance to a preferred date/time

Only dates and times that meet the service rules and your maintenance policy are available for selection. Note: Reschedule maintenance is not supported for servers on SMW schedule.

Select Reschedule to confirm the new maintenance time.
After confirmation, review the Maintenance status section to verify that the new start time is displayed.

The portal shows a confirmation after the maintenance event is successfully rescheduled.

This is useful when the original maintenance time overlaps with a period where even a short interruption could be disruptive, such as peak application traffic, end-of-quarter processing, planned migrations, major releases, holiday events, or internal change freeze periods.

3. Apply maintenance on demand

You can also apply eligible maintenance immediately when the timing works better for you.

To apply maintenance on demand:

In the Azure portal, go to your Azure Database for PostgreSQL flexible server.
In the left menu, under Settings, select Maintenance.
In the Maintenance status section, review the upcoming maintenance event.
If the event is eligible, select Reschedule, followed by Apply now.
Select Yes - Apply Maintenance Now to start maintenance.
Monitor the Maintenance status section.

Figure 3: Apply maintenance on demand

The maintenance event status updates as the workflow progresses. When maintenance completes, the status changes to Complete and the event moves to the Maintenance history section.

For example, a team might decide to apply maintenance during a quieter period, after validating application readiness, or before a planned release. This gives customers a way to complete maintenance on their own timeline instead of waiting for the scheduled window.

4. View maintenance history

After maintenance completes, you can review maintenance history for your server. This helps teams confirm when maintenance occurred and supports operational reviews, troubleshooting, and audit-related workflows.

To view maintenance history:

In the Azure portal, go to your Azure Database for PostgreSQL flexible server.
In the left menu, under Settings, select Maintenance.
On the Maintenance page, review the Maintenance history section.
Select a maintenance event Tracking ID to view more details, such as the maintenance type, start time, and final status.
Select Export to CSV to download maintenance history.

Figure 4: View maintenance history

If no past maintenance events are available for the server, the maintenance history section might be empty.

Built for real production schedules

Production environments rarely operate on a simple schedule. Maintenance often needs to be coordinated with application releases, internal change windows, customer commitments, and business calendars.

These new controls are designed to make that coordination easier. By making maintenance more visible and actionable, Azure Database for PostgreSQL flexible server helps you plan with less uncertainty and more control.

Frequently asked questions

Which maintenance events can I reschedule?

Only eligible planned maintenance events on Custom Maintenance Schedule (CMW) can be rescheduled. Some maintenance, such as time-sensitive security or compliance updates, might not be eligible for rescheduling.

How far can I reschedule maintenance?

Eligible maintenance can be moved to a preferred date and time up to two weeks from the originally scheduled maintenance date.

Can I reschedule maintenance more than once?

Yes. You can update the selected maintenance date and time again, as long as the maintenance event remains eligible and the new time is within the allowed two-week rescheduling window.

Why can’t I reschedule maintenance right before it starts?

Rescheduling is unavailable shortly before the originally scheduled maintenance time. This lock-in period helps ensure the maintenance workflow can begin reliably.

Can I apply maintenance before its scheduled time?

Yes. When an upcoming maintenance event is eligible, you can select Apply now in the Azure portal to begin maintenance immediately.

Will applying maintenance on demand restart my server?

It might. Some maintenance operations require a server restart, which can result in a brief interruption or connection churn. Apply maintenance when your application can tolerate that impact.

Where can I use these maintenance controls?

The new controls are available in the Azure portal. Open your Azure Database for PostgreSQL flexible server and go to Settings > Maintenance.

Can I use Azure CLI or REST API?

Azure CLI and REST API support are coming soon. At general availability, customers can use the Azure portal to view upcoming maintenance, reschedule eligible events, apply maintenance on demand, and view maintenance history.

Can I view maintenance that has already completed?

Yes. The Maintenance history section in the Azure portal shows completed maintenance events. You can select an event to review its details and export the history to CSV when needed.

What should I do if I need to defer maintenance for more than two weeks?

Create an Azure support request. The self-service experience supports rescheduling eligible maintenance for up to two weeks, but support can help assess requests that require a longer deferral.

Getting started

To get started, open your Azure Database for PostgreSQL flexible server in the Azure portal and navigate to Settings > Maintenance. These new self-service maintenance controls are now generally available in the Azure portal for Azure Database for PostgreSQL flexible server. CLI and API support are coming soon.

Learn More

To learn more about rescheduling maintenance and related Azure PostgreSQL capabilities, see:

Build a Knowledge Graph in Azure HorizonDB with AI Functions and Apache AGE

Aditi_Gupta — Thu, 11 Jun 2026 17:42:46 GMT

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)

scoriani — Thu, 11 Jun 2026 09:09:00 GMT

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.

What's new with Postgres at Microsoft, 2026 edition

clairegiordano — Tue, 04 Aug 2026 18:31:29 GMT

A lot has happened with Postgres at Microsoft over the past year. This is the 2026 edition of our annual “what’s new” blog post, with highlights from the past 12–13 months—across both our managed services on Azure and our work in the upstream open source project.

The infographic below pulls it all together—feature updates, new capabilities, and ongoing investments across our Postgres workstreams. You might notice it looks a bit different compared to last year: we redesigned the infographic to make space for two new sections—Azure HorizonDB (Preview) and Developer Tools.

The table of contents follows the structure of the hand-made infographic, with each bullet linking to that section. Jump to what you care about, or settle in ☕️ and read the whole thing.

Azure Database for PostgreSQL flexible server
Azure HorizonDB
Developer Tools
PostgreSQL core
Citus open source
Postgres Community

Figure 1: This infographic maps out the major workstreams across Microsoft’s Postgres efforts as of June 2026—from the managed database services on Azure, to VS Code and Cursor, to upstream contributions to the Postgres open source project. For much of the open source work, our contributions to PostgreSQL involve collaboration with people across the global PostgreSQL community, both inside and outside Microsoft.

Azure Database for PostgreSQL flexible server

Azure Database for PostgreSQL flexible server is a managed database service on Azure that meets the needs of large enterprises, small to medium-sized businesses, and early-stage startups. Flexible Server continues to grow in capability month over month, as evident in the monthly “feature recap” blog posts on Microsoft Tech Community (props to Gauri Kasar for publishing these) in June 2025, July, August, September, October, November, January 2026, February, March, April.

TIP ON NAMING: Throughout this post, we sometimes use the full name—Azure Database for PostgreSQL flexible server—and sometimes we just say “Flexible Server” for short. They mean the same thing. You might notice we use the two names interchangeably, so am flagging it here to avoid any confusion.

Performance & Scalability

Premium SSDv2 storage: With the general availability of Premium SSDv2 storage, significant performance and cost-efficiency improvements are now available for IO-intensive workloads. With SSDv2, storage and performance can be scaled independently so you only pay for what you use. Premium SSDv2 adds flexible server storage scaling up to 64TB, with up to 80,000 IOPS and 1,200 MiB/s throughput. (link to docs)
Elastic Clusters support for Terraform, Bicep, & Ansible: With the general availability of Elastic clusters, flexible server added built-in support for row-level and schema-level sharding of data across a cluster of servers. Built-on Citus open-source technology, elastic clusters provides horizontal scaling of workloads with all the enterprise features of flexible server. We’ve added infra-as-code support to deploy elastic clusters from Terraform, Bicep, and Ansible. (link to docs)
Cascading read replicas: With the general availability of cascading read replicas, you can not only create read replicas from the primary, but from other replicas too—enabling up to 30 replicas, more efficient distribution of read traffic, and more flexibility for complex deployment topologies. (link to docs)
Intel & AMD v6 series SKUs: The Intel & AMD v6 General Purpose and Memory Optimized SKUs deliver high-performance, massive scale and better price performance. Powered by 5th Gen Intel® Xeon® processor and AMD's fourth Generation EPYC™ 9004 processors you can scale up to 192 vCores and 1.8 TiB of memory. Using the NVMe protocol for data disk access you can leverage the maximum IOPS and throughput from high performance IO options like SSDv2. (link to docs)
New Azure Advisor performance recommendations: Azure Advisor provides proactive performance, resiliency, and security recommendations for your workloads. We added Index scan insights to improve query efficiency, audit logging review to identify excessive logging, statistics monitoring with alerts on statistics resets, storage optimization recommendations, and connection management guidance. (link to docs)
PgBouncer upgrades: PgBouncer is the built-in connection pooling feature for flexible server, providing the ability to scale to thousands of connections. Upgrading to 1.25.1 added enhanced protocol handling and important stability and security fixes. (link to docs)
pg_duckdb extension (Preview): The pg_duckdb extension combines PostgreSQL’s transactional performance and reliability with DuckDB’s analytical speed for large datasets. This makes a great combination for hybrid OLTP and OLAP environments where you need to run analytical queries directly in PostgreSQL without compromising on performance. (link to demo video)

pg_ivm extension: The pg_ivm extension implements Incremental View Maintenance (IVM), allowing materialized views to by updated more efficiently by only applying incremental changes when the underlying data changes—resulting in improved performance for large datasets where only a small subset of the data is modified. (link to repo)

Manageability

Built-in Grafana monitoring dashboard: Grafana dashboards for your flexible server instances are now readily available from the Azure Portal in your Azure Database for PostgreSQL view. You can now visualize metrics and logs, correlate events by timestamp, and rapidly gain insights into performance, query behavior, and availability with built-in dashboards. (link to blog)
Maintenance payload visibility: Maintenance updates to flexible server can include PostgreSQL minor version updates, security fixes, bug fixes and new functionality. It’s important to know what’s changing so you know what to expect, what improvements you can take advantage of, and whether to flag any concerns. You can now access the release notes for maintenance updates. (link to docs)
Defer maintenance & Maintenance on demand: Using Custom Maintenance Windows (CMW) and System-managed Maintenance Windows (SMW) gives you control over when to apply flexible server maintenance updates. We’ve expanded that control with the ability to defer an upcoming maintenance update by up to 2 weeks, or to apply one on demand. These new options are available in the Azure Portal, with CLI and API support coming soon. (link to docs)
PostgreSQL 18 (w/MVU & Terraform support): PostgreSQL 18 was made available on Azure on the same day as the community release, with a host of performance and security improvements . PG18 general availability added support for all Azure public regions, Major Version Upgrade, Entra ID authentication, and Terraform support. (link to blog)
5 new regions added: Austria East, Denmark East, Indonesia Central, Malaysia West, Chile Central: New Azure regions for flexible server are continually being added in response to customer demand. You can check out the region availability list to stay up to date with supported regions. (link to docs)
HA expansion: Japan West: Existing regions are also being retrofitted to add availability zones which support zone-redundant High Availability. In this timeframe, we’ve added support for multi-zone deployment in Japan West. (link to docs)

Resiliency

Zonal resiliency HA setting: Zone-redundant high Availability (HA) is the recommended and default HA configuration for maximum resiliency. The Azure Portal now includes a Zonal Resiliency setting that lets you select same-zone HA if a region doesn’t support zone-redundant HA—with automatic migration once capacity becomes available. (link to docs)
Near-zero downtime scaling for HA-enabled servers: This feature minimizes downtime when you modify the storage and compute tiers. Scaling operations such as vCore or Compute tier operations can now HA failovers to maintain the connection string, reducing downtime to typically under 30 seconds. You don’t need to take any action to use this feature. (link to docs)
Long term backups: Backups with Long Term Retention (LTR) enable you to keep backups for up to 10 years, enabling you to meet regulatory and audit-driven requirements for long-term data retention. (link to docs)
Logical replication slot synchronization metric: A new metric called logical_replication_slot_sync_status provides a binary signal to indicate whether logical replication slots are synchronized across High Availability (HA) primary and standby nodes. This adds a clear signal for failover readiness to help with scenarios where data continuity during failover is critical. (link to docs)

Security and networking

Azure Confidential Computing: PostgreSQL flexible server instances can now run on Confidential Virtual Machines (CVMs) inside a Trusted Execution Environment (TEE)—a secure, isolated enclave with encrypted memory, enabling end-to-end security and enhanced privacy to meet the strictest security standards for regulated workloads. (link to docs)
Entra ID group login using user credentials: You can authenticate to Azure Database for PostgreSQL with your Entra ID as a member of a Microsoft Entra group by creating a group principal. Managed identities and service principals are also supported as group members. (link to docs)
Entra ID token refresh libraries for .NET, Python, Java: Using Entra ID for authentication throughout your application supports an identity-based security perimeter, simplifying how applications authenticate with Azure Database for PostgreSQL, but it also means your application needs to handle additional complexities like Entra token refresh. These libraries take care of the token refresh logic, making it easy to add token refresh support to your applications with minimal code changes. (link to libraries .NET, JavaScript, and Python)
Credcheck, anon, ip4r extensions: We onboarded several extensions over the last year that help with compliance and regulatory requirements, including:
- anon: GA of the upgraded anon extension, adding support for dynamic and static masking, anonymized exports, randonmization, and other advanced masking techniques.
- credcheck: The credcheck extension adds credential checks for usernames and password complexity.
- ip4r: The ip4r extension provides a set of data types for Ipv4 and Ipv6 network addresses which are useful for auditing, compliance, and intrusion detection. (link to docs: anon, credcheck, IP4R)
Priority connectivity for azure_pg_admin users: The azure_pg_admin role provides a way to perform privileged administrator operations without access to the superuser role, reducing the risk of privilege escalation. This role was updated to work with PG16’s stricter role hierarchy, allowing management of objects owned by any non-restricted role. It also ensures that at least one database connection is always available to admin users—even when the client connection pool is full—helping prevent lockout situations and making troubleshooting easier. (link to docs)
Defender security assessments (Preview): Two new Microsoft Defender for Cloud CSPM security recommendations for flexible server are now availability:
- Geo-redundant backups should be enabled for PostgreSQL Servers, and
- require_secure_transport should be set to "on" for PostgreSQL Servers
These assessments evaluate database configuration settings against recommended security practices, helping you manage risk and align with internal and industry standards. Additional security assessments will be added over time. (link to new recommendations)
VNET to Private Link migration (Preview): Previously, it wasn’t possible to migrate servers deployed inside a VNET to an updated secure network configuration based on Private Endpoint connectivity, which is simpler and more scalable. With the VNET to Private endpoint migration preview, you can use the Azure CLI, API or SDK to migrate your server without needing to recreate it. (link to docs)
Extended CVE support for PG11, 12, 13: If you’re running a PostgreSQL version in flexible server that is no longer community supported like PG11, 12, or 13, it will continue to be patched with high priority CVEs for 3 years after the community retirement data as part of Azure Database for PostgreSQL extended support. (link to docs)

Integration

Mirroring data to Microsoft Fabric: The general availability of Fabric mirroring in flexible server opens up near real-time replication of data from Azure Database for PostgreSQL to Microsoft Fabric—enabling the advanced analytics and reporting capabilities of Fabric without the need for extensive ETL. It also means your PostgreSQL server is free to run mission-critical transactional workloads without being affected by spikes in analytical reporting. (link to docs)
Ansible module update: A new version of the Ansible collection for flexible server was released, adding support for support for Elastic clusters, PG18, virtual endpoints, on-demand backups, system-assigned identity, storage auto-grow, read replica switchover and more. (link to docs)
Updated Go, Java, JavaScript, .NET & Python SDKs: The udpated SDKs for performance flexible server operations add PG18 support, improved Elastic cluster features and improved response codes. (link to SDKs: .NET, Go, Java, Javascript, Python)
Upsert and Script activity in ADF and Azure Synapse: New capabilities were provided to make merging data into existing tables easier with the Upsert method, and to run custom SQL scripts as part of workflows enabled more streamlined ETL processes with Azure Data Factory and Azure Synapse. (link to Upsert Methodand script activity docs)
Stable REST API release for 2025: The 2025-08-01 stable REST API release for Azure Database for PostgreSQL added support for the latest PostgreSQL major versions, Elastic Cluster and CMK enhancements. (link to released APIs)
Azure Storage extension Parquet support: Parquet is a popular columnar storage format that is widely used in big data and analytics environments. With Parquet support in azure_storage, you can now perform direct SQL-based reads and writes to Parquet files in azure_storage, making it easy to import and export data to and from PostgreSQL without needing external tools or scripts. (link to docs)

Migration service in Azure Database for PostgreSQL

AI-assisted Oracle to PostgreSQL migration tool: Migration from one database type to another has traditionally been a complex, time-consuming and costly project. The emergence of AI-assisted migration tooling has dramatically reduced this cost. The AI-assisted migration tooling available with the VS Code PostgreSQL extension converts Oracle schema and application code to Azure Database for PostgreSQL flexible server. This tooling leverages GitHub Copilot, Microsoft Foundry, and custom Language Model tools to convert Oracle schema, database code and client applications into PostgreSQL-compatible formats and validates every change against a running flexible server instance. (Link to schema conversion docs, link to app conversion docs)
Azure Migrate discovery & assessment: The first step in a database migration process is Discovery: understanding what you’re running and the state of migration readiness. Azure Migrate now provides PostgreSQL discovery and assessment to report on your on-prem PostgreSQL landscape, identify potential migration blockers, and learn tailored SKU and cost insights with a streamlined migration assessment. (link to docs)
Migration with pgoutput plugin: Online migration to flexible server became generally available last June and we’ve continued to improve it. You can now leverage pgoutput (used by PostgreSQL’s logical replication framework) for online migration with improved reliability and performance. The update provides improved compatibility with modern PostgreSQL deployments and reduces dependency on legacy decoding mechanisms, enabling functionality like fine-grained filtering using Publications, allowing migration of specific tables and filtering by operations. (link to docs)
AlloyDB & EDB migration sources: You can now migrate directly from AlloyDB and EDB Extended Server to PostgreSQL using the Azure Database for PostgreSQL Migration Service, with both online and offline migration support. (link to docs: AlloyDB, EDB)

AI capabilities in Flexible Server

AI Functions (Preview): AI Functions add extraction, generation, classification, and re-ranking directly into SQL through the azure_ai extension using an Azure OpenAI or Microsoft Foundry model. It replaces hundreds of lines of Python glue with a one-line SQL call. (link to docs)
pgvector 0.8.2 support: pgvector 0.8.2, focuses on stabilizing parallel HNSW index builds, fixing correctness issues and improving reliability, all important steps toward production-grade vector search. (link to docs)
Microsoft Foundry integration (Preview): We've shipped a PostgreSQL connector for Microsoft Foundry built on the Model Context Protocol (MCP). Foundry agents can now explore your Postgres schema, retrieve records, run analytical queries, and perform vector similarity searches in natural language, secured by Microsoft Entra ID (link to docs)
LangGraph/LangChain connector: The new native Azure Database for PostgreSQL connector for both frameworks gives agents first-class vector retrieval, checkpointing, and conversational memory backed by your Postgres instance with Entra ID authentication and production-grade reliability out of the box. (link to blog)
Apache AGE extension support: Apache AGE is now supported on Azure Database for PostgreSQL, bringing graph queries to the same database that already holds your relational tables, JSON, vectors, and full-text indexes. (link to blog)

Try it out: Quickstart for Azure Database for PostgreSQL

The Quickstart: Create an Azure Database for PostgreSQL flexible server docs page walks you through how to get started deploying your own flexible server instance, including a link to a free Azure trial account.

Our Postgres team is hiring!

If you’re a deep Postgres expert—or a strong Linux systems engineer—this might be your moment. We’re continuing to grow the Postgres team at Microsoft. (link to Principal Software Engineer role; and link to Software Engineer II role)

As Affan Dar, the VP of Engineering for Postgres at Microsoft says all the time:

“We are always looking for strong Linux systems engineers and PostgreSQL experts to help us build the future of Postgres at Microsoft.”

Azure HorizonDB (Preview)

Azure HorizonDB launched in private preview last November, and at Microsoft Build in May 2026 we announced the public preview. If you want a quick overview, the excerpt below from the announcement blog post is a good place to start—or you can dive straight into some of the key HorizonDB features further down.

"Azure HorizonDB is built to meet the demands of security, resilience, scale, and performance—combining the flexibility developers expect from Postgres with the operational rigor enterprises require.

It extends the core Postgres engine with cloud-native capabilities such as integrated identity, fine-grained network and security controls, and seamless lifecycle management, while preserving full compatibility with the open ecosystem of extensions.

HorizonDB introduces advanced, natively integrated capabilities like vector data support and AI model management, enabling new classes of intelligent applications without sacrificing transactional integrity or developer productivity."

—Excerpted from "Azure HorizonDB: Enterprise-Ready Postgres, Engineered for the AI Era" announcement blog post

Low latency commits: The architecture of Azure HorizonDB (Preview) separates compute and storage, so storage is shared by all compute nodes. This shared storage architecture enables low-latency, millisecond commits within region providing critical support for tier-1, performance-sensitive workloads. (link to docs)
Scale up to 192 Cores: Azure HorizonDB supports compute scaling up to 192 cores for both primary and replica instances, enabling the capacity needed to handle workload spikes. (link to docs)
Read scale-out with 15 replicas: Support for up to 15 read replicas, with read connections automatically load-balanced across them to efficiently scale out read workloads. (link to docs)
Autoscaling storage up to 128 TB: Support for storage auto-scaling up to 128 TB, eliminating the need to pre-provision storage size. Storage automatically shrinks as your data footprint decreases. (link to docs)
Zone resilient storage: Azure HorizonDB leverages Azure Blob Storage, which is zone-resilient by default, to ensure zero data loss. (link to docs)
Entra ID Authentication: Azure HorizonDB provides native integration with Microsoft Entra ID, enabling centralized identity and access management for PostgreSQL workloads. This integration supports secure, token-based authentication while allowing organizations to enforce enterprise security policies such as multi-factor authentication and conditional access.
Private Endpoints : Azure HorizonDB supports Azure Private Endpoints, ensuring that database connectivity remains entirely within a customer’s private Azure VNET boundary. This capability minimizes exposure to the public internet and helps organizations satisfy stringent security, compliance, and regulatory requirements.
Mirroring to Microsoft Fabric: Azure HorizonDB includes native mirroring to Microsoft Fabric, enabling near real-time replication of operational PostgreSQL data into analytics-ready OneLake storage. This capability simplifies modern analytics architectures by reducing dependency on complex ETL pipelines while supporting scalable BI, AI, and data engineering workloads.
~75 popular Postgres extensions: Azure HorizonDB is fully PostgreSQL-compatible and supports approximately ~75 popular extensions such as pg_stat_statements, auto_explain, pg_duckdb, pg_diskann. It will continue to expand support for additional extensions, including both PostgreSQL and Azure-specific offerings such as AI extensions. (link to docs)
Full-text search with BM25 ranking (pg_textsearch): pg_textsearch brings BM25 the same relevance algorithm behind every major search engine directly into HorizonDB as a native extension. BM25 offers better relevance than PostgreSQL's built-in ts_rank, and you can combine it with vector search in one SQL query for true hybrid retrieval. (link to docs)
DiskANN Advanced filtering: DiskANN Advanced Filtering offers lower latency on filtered vector search compared to traditional approaches, so a query like "find the most similar products under $50 in the Electronics category" runs at full DiskANN speed. (link to docs)
AI model management: AI Model Management in Azure HorizonDB simplifies how you bring AI into your database. With a single step, it provisions fully managed AI models for embeddings, semantic ranking, and generation through Microsoft Foundry—and installs and configures the azure_ai extension to enable AI functions like generate(), extract(), create_embeddings(), and rank() for immediate use directly in SQL. This removes the need for manual setup and context switching, with model provisioning, management, monitoring, and billing handled seamlessly within HorizonDB. (link to docs)
AI pipelines: AI Pipelines let you describe an AI workflow (chunking, embedding, extraction, generation, ranking, human approval) declaratively in SQL, and run it as a fault-tolerant pipeline that lives inside the database built on pg_durable. (link to docs)
Durable functions (pg_durable): pg_durable is an open source extension that lets you describe long-running workflows such as sequential steps, parallel fan-out, scheduled jobs, human-in-the-loop, and retries declaratively in SQL. And then you can run them as fault-tolerant durable functions that live inside the database. (link to GitHub Repo)

BACKSTORY: Beyond features, if you want to learn more about the story behind Azure HorizonDB, listen to the Talking Postgres podcast episode with guest Adam Prout, one of the founding architects of Azure HorizonDB.

Developer Tools

We launched a new IDE for PostgreSQL in VS Code in May 2025—and the response was strong, including a day at the top of Hacker News and over 170K views of the original blog post. One year later, the extension has more than 560K+ installs, we’ve kept building and adding more capabilities. Below are some of the highlights. We also recently added support for Cursor, available via the Open VSX Registry.

VS Code extension to connect to any Postgres, anywhere: You can connect to any PostgreSQL database directly from the VS Code extension for PostgreSQL—whether it’s running locally, in a container, on-prem, or in any cloud. Connection profiles let you switch between environments without leaving the editor. (link to docs)
One-click Dockerized Postgres + integrated psql: Local development is streamlined through the PostgreSQL extension in VS Code, including quick setup of a PostgreSQL environment and support for familiar tools like psql. This reduces the amount of manual setup needed to start querying. (link to docs)
Object Explorer with cross-database search: Within VS Code, the PostgreSQL extension provides an Object Explorer for browsing tables, views, and functions across databases. You can also search across schemas and databases without manually navigating the full tree. (link to docs)
Schema visualization: Schema visualization is built into the VS Code extension for PostgreSQL, making it easier to understand relationships between tables. This can be especially useful when working with unfamiliar or complex data models (link to docs)
Intellisense query editor with CSV/JSON: The VS Code extension for PostgreSQL includes a query editor with IntelliSense that is schema aware. Query results are returned in a grid and can be exported to formats like CSV or JSON for further analysis. (link to docs)
Query plan visualizer & Copilot analysis: Query plans can be visualized directly in VS Code using the PostgreSQL extension, helping surface bottlenecks and execution details. With GitHub Copilot, you can also get explanations and suggestions for improving query performance. (link to docs)
Apache AGE Cypher graph visualization: Support for Apache AGE allows graph queries to be run and visualized as node-edge diagrams directly in VS Code. This enables exploration of graph data without requiring a separate visualization tool. (link to docs)
Copilot Agent Mode tools (run SQL, design schemas, import CSV): When used with the VS Code extension for PostgreSQL, GitHub Copilot can operate in agent mode to assist with multi-step workflows such as running queries, designing schemas, or importing data. These actions are suggested in natural language while still requiring user confirmation. (link to docs)
Copilot metrics intelligence in Server dashboard: The VS Code extension for PostgreSQL includes server dashboards that surface database performance metrics. GitHub Copilot can help interpret these signals and guide troubleshooting or optimization efforts. (link to docs)
Entra authentication for Azure Database for PostgreSQL: Connections from the VS Code extension for PostgreSQL to Azure Database for PostgreSQL support Microsoft Entra ID authentication. This enables secure, passwordless access directly from the editor. (link to docs)
Azure server browse, create, & manage in-IDE: Azure Database for PostgreSQL resources can be discovered, created, and managed directly within VS Code through the PostgreSQL extension. This reduces the need to switch to the Azure portal for common workflows. (link to docs)
Cursor extension for PostgreSQL: An extension for PostgreSQL is also available in Cursor and other Open VSX-compatible editors, bringing the same database tooling into those environments. In Cursor, these workflows integrate with Cursor’s native AI experience while preserving the core Postgres capabilities. (link to blog post)

Contributing to PostgreSQL core

Microsoft continues to invest in our open-source PostgreSQL contributors team and reaffirms its commitment to open source. The team continues to drive large and ambitious projects in upstream PostgreSQL and make all those features available to all Postgres users.

The team has a broad range of expertise, and our contributions to Postgres span almost all areas in Postgres, including the Query Planner, Executor, Storage/IO subsystems, Security, Operational and Manageability improvements, new SQL features and much more.

Our commitment to supporting Postgres development hasn’t changed since Claire Giordano first wrote this back in August 2023:

In order to thrive, an open source ecosystem needs commercial support as well as volunteer efforts. Even open source developers need to eat! For the Postgres open source ecosystem to flourish, companies like Microsoft need to support the project by funding development in the Postgres core. Which we do.

PostgreSQL is a complex piece of software that runs mission-critical workloads across the globe. To provide the best possible experience on Azure, it follows that we need to thoroughly understand how it works. By having PostgreSQL committers and contributors on our team, they can share knowledge internally across different orgs, or directly answer internal questions regarding incidents or extension development.

Because today's cloud operates at a scale most on-prem solutions never encountered, unique cloud data center problems, often relating to performance, now require special attention. Our in-house team of deep Postgres experts are focused on tackling these cloud-scale issues upstream, in the Postgres core. Another benefit: our team's Postgres expertise gives Azure customers confidence in our cloud database services, too.

Commercial funding of PostgreSQL developers has another benefit: it gives developers the long-term stability to pursue the big things, the groundbreaking changes that are super important to the future. In particular, the Postgres contributor team at Microsoft is focused on some big architectural changes (example: Asynchronous IO) that you wouldn’t be able to do without the funding for a full-time, multi-year effort.

Highlights of our team’s Postgres 19 code contributions (so far!)

Big news: Postgres 19 Beta 1 just released, and PG 19 is expected to GA later this year, likely in September 2026.

Below are highlights from ~440 commits our Microsoft team authored or co-authored (so far) in Postgres 19.

And because attribution matters in open source, it must be said: the Postgres 19 work you’ll see below was done in collaboration with Postgres developers and contributors from around the world—including many outside Microsoft. That’s how the Postgres open source project works. We’re grateful to be part of it.

Figure 2: Team members at Microsoft that contribute to the upstream Postgres open source project.

Performance

Faster Tuple Deformation: This work accelerates scans of tables with many fixed-width columns. The patches add a dedicated fast loop for columns at pre-calculated offsets and a smaller Attribute struct for reduced memory footprint. (link to optimize tuple deformation commit; link to CompactAttribute commit)
Fast path for Foreign Key checks: A committed patch series that adds a faster path for foreign key checks. It avoids SPI by probing the referenced index directly, reuses execution state across trigger batches, and uses array-based index probes to reduce setup overhead. In the common case of bulk inserts into single-column, non-partitioned primary-key tables, it delivers about a 2.9x speedup. (link to commit series)
Faster COPY using SIMD for delimiter matching: The COPY FROM text/CSV parsing was optimized by using SIMD instructions to process input data a chunk at a time, quickly skipping over bytes that don't contain special characters (delimiters, newlines, escapes) rather than checking byte-by-byte in the state machine. The performance speedups can be up to 60% in certain cases, with no regressions. (link to commit)
Parallel TID range scan: The change allows for queries that filter on ctid ranges to be executed by multiple parallel workers. This is particularly useful for logical replication initializers, data migration, and custom ETL scripts. (link to commit)
Improved TS counter for low-overhead EXPLAIN: The commit reduces the overhead of EXPLAIN ANALYZE timing by using the x86 RDTSC instruction directly. This reduces pipeline stalls which dominated the timing cost and makes EXPLAIN ANALYZE much faster. (link to commit)
On-access Visibility Map updates: The change allows us to mark pages all-visible during SELECT queries. This leads to more index-only scans, which previously had to wait for a Vacuum to run, and additionally also results in less I/O needed by Vacuum. (link to commit)
Reduce Vacuum WAL generation: A series of changes to reduce WAL generation by Vacuum and COPY FREEZE. After these commits, we no longer emit separate heap visible WAL records and instead include that information in other existing WAL records, halving the number of WAL records emitted per heap block for both heap vacuuming and COPY FREEZE. This makes vacuum and COPY FREEZE faster and decreases disk space usage. (links to commits: d96f87332b3, add323da40a, 1252a4ee286)

New SQL Features:

SQL/PGQ: SQL Property Graph Queries is Part 16 of the SQL:2023 ISO standard which lets you define graph structures on top of your existing relational tables and query them with a dedicated pattern matching syntax. This is a major new feature, led by Peter Eisentraut along with Ashutosh Bapat from our team. In practical terms, for PostgreSQL, this means you can now express things like social network traversals, dependency graphs, fraud detection paths, or supply chain analysis using concise graph syntax without leaving Postgres, without extensions, and without duplicating your data into a separate graph store. (link to commit)

Operational Improvements:

Automated resizing of AIO workers: The patch automatically adjusts the I/O worker pool size for PostgreSQL's async I/O subsystem, replacing the old fixed io_workers setting with dynamic scaling that grows the pool under load and shrinks it back down after an idle timeout—so you no longer have to guess the right static worker count. (link to commit)
New EXPLAIN (IO) for better IO visibility: The change introduces a new IO option to EXPLAIN, which adds per-scan-node I/O instrumentation to EXPLAIN ANALYZE output. These apply to nodes backed by the ReadStream API’s and reports prefetch queue metrics (average and maximum distance, capacity) and I/O request stats. This gives you direct visibility into how the ReadStream/AIO layer is performing underneath each scan, instead of having to guess from BUFFERS alone. (link to commit)

Security and Reliability:

CVE-2026-2006: The change modified an internal string length function to report ERROR if the input string ends in an incomplete multibyte character. The general philosophy was to raise encoding errors on a just-in-time basis—that is, the low-level multibyte string length functions now actively detect and reject truncated/incomplete characters rather than silently ignoring them. This hardens PostgreSQL's multibyte encoding handling, Incomplete characters in stored data are a sign of corruption or encoding bugs and surfacing them as errors is safer than silently computing wrong character counts. (link to commit)
Online checksum enablement: Enabling checksums to detect data corruption was only available during initdb, or having to shut down the entire cluster and calculating the checksums on all the files. For larger production databases, that downtime is often unacceptable. This change allows you to enable this in a running cluster, and the checksums are calculated in the background. (link to commit)
Server Side SNI support: PostgreSQL 19 adds server-side support for SNI, with a new configuration file $datadir/pg_hosts.conf that specifies the hostname/certificate/key pairs. The server inspects the hostname TLS extension in the SSL handshake and selects the right SSL certificate, key, and CA certificate to use for that connection. This means a single PostgreSQL instance can present different certificates depending on which hostname the client is connecting to. (link to commit)

Groundwork/Futures:

Buffer Mgr Locking improvements: Andres Freund has been working on several improvements in the way buffer management and locking has been done, paving the way to use AIO for writes. The change also now performs buffer page un-lock and un-pin in a single atomic operation, showing some pgbench runs to see up to 25% improvement.
Index Pre-fetching groundwork: Index pre-fetching did not make it for PG19, but a lot of the groundwork has been done in this cycle, including all the major design pieces, preliminary improvements in the AIO infrastructure and mitigation of any performance regressions. The feature is in good shape to land in PG19.
Shared Buffer Elasticity groundwork: Ashutosh and Heikki have worked on improving shared memory management in PG 19. This would help support changing shared-buffers without server restart in a future release. In PG19, extensions using small shared memory structures can be created/loaded after startup without going through shared_preload_libraries and without restarting the server. (link to commit)

The features above capture some highlights of the work done by the team at Microsoft for open-source PostgreSQL, but it’s not a comprehensive list—and certainly doesn’t reflect all the engineering work to review patches and mentor contributors across the project. Let’s look at some numbers:

Microsoft’s code contributions to Postgres 19 (to date) as of 31st May 2026

Code contributions in Postgres 19	440 Commits with Microsoft authors or co-authors	3,088 total commits to PG19 to date (from everyone)	14.2% of commits have code authors from Microsoft
Patch Reviews in Postgres 19	907 Commits with reviews from the Microsoft Team	5,603 total commits to PG18 to date (from everyone)	16.2% of commits had reviews from team @ Microsoft

To interpret the numbers, here are 3 things to keep in mind:

Not all commits are created equal. Some commits are small; others are complex and high-impact. So while commits are a useful signal, they’re not a perfect measure of effort or impact. Still, it’s a metric many people care about, so we’re sharing it.
Many commits have multiple authors (and reviewers): The 440 commits with Microsoft authors in Postgres 19 (as of May 31 2026) were authored by 19 different people on our team. But those commits were often co-authored by other contributors—both inside and outside Microsoft. That’s one of the things I love about the Postgres community: developers collaborating across companies, countries, and continents.
Code is just one part of the story: Code and review contributions are essential to the Postgres project—but they’re not the whole picture. As you’ll see later in this post, our team also contributes in other ways: to extensions like Citus, and to the Postgres Community.

Citus Open Source

The Citus open source extension to Postgres is a good fit for data-intensive applications that need more compute, memory, or scale than a single Postgres node can handle.

With over 12.5K stars on GitHub, Citus is a popular extension that gives Postgres the superpower of distributed tables. You can download Citus open source, or you can use Citus on Azure via the Elastic Clusters feature in Azure Database for PostgreSQL.

New Citus open source features in last 13 months

The Citus open source extension scales out Postgres horizontally, using either row-based sharding or schema-based sharding, or both.

The Release Notes pages for Citus are online—and for Citus major releases you can often find a dedicated blog post as well:

Mehmet Yilmaz’s release blog post titled, Distribute PostgreSQL 18 with Citus 14
Check out the Citus 14.0 release notes that added PG18 support

Here are highlights of new Citus open source capabilities added in the last 13 months:

Citus 13.2, 14.0, and 14.1 releases: You can find the release notes online for Citus 13.2, Citus 14.0, and for the latest release which is actually two paired minor releases, Citus 14.1/13.3.
Postgres 18 support in Citus 14: Citus 14 primarily about PG18 compatibility, with upstream benefits like faster scans and maintenance via AIO; better index usage with skip-scan; uuidv7() for time-ordered UUIDs; OAuth authentication support; and temporal constraints flowing through once compatibility lands. (link to Citus 14.0 release notes)
Snapshot-based node split / faster scale-out: From the release notes, “the snapshot based node-addition feature enables faster scale-out operations by adding a new worker node using a clone of an existing worker node. This significantly reduces rebalance times when adding new nodes to the cluster.” Why? Because the cloned work already contains a copy of the data. (link to release notes)
Faster parallel shard rebalancing: Citus 13.2 explicitly improved rebalancer performance by parallelizing moves and removing logical-replication bottlenecks. (link to release notes)
New Citus observability views/stats: Citus added new observability views and user-defined functions (UDFs) for distributed clusters. Citus 13.1 introduced citus_stat_counters to expose Citus-specific counters collected when citus.enable_stat_counters is enabled; and 13.1 also introduced citus_nodes to show node name, port, role, and active status, as well as supporting UDFs to query/reset counters and identify whether the current node is primary.

Citus 13.2 added citus_stats(), which retrieves distributed pg_stats for a Citus table, giving users more cluster-level visibility into statistics and node state. (link to citus stat counters in release notes; link to citus nodes view in release notes; link to citus_stats view in release notes)
Expanded DDL/role propagation: Citus 13.1 adds support for propagating more DDLS from the coordinator to ease role and database management in a Citus cluster, including support for: GRANT/REVOKE rights on table columns; REASSIGN OWNED BY commands; CREATE/DROP database commands; SECURITY LABEL on tables and columns; ALTER USER RENAME commands; ALTER DATABASE .. SET .. commands; and role management from worker nodes. (link to Citus 13.1 release notes)
Planner/query performance improvements: Citus 13.2 includes outer join pushdown and local fast-path query optimization. (link to outer join pushdown in release notes; link to fast-path query optimization in release notes)

Postgres Community work

Given my role as head of Postgres open source community initiatives at Microsoft, it’s not a surprise: contributing to Postgres is something I care deeply about.

Last year, I gave a talk at PGConf EU that shared an analysis of contributions to Postgres v18, based on research I did with Daniel Gustafsson. And if you’ve ever raced sailboats, you know: every role matters.

One thing I’m quite proud of are the different ways the team at Microsoft contributes to the Postgres ecosystem. This Postgres Contributions infographic—inspired by a hand-drawn sketch by Cornelia Biacsics—shines a light on the ways we’re contributing to this ecosystem.

Figure 3: Infographic of the 8 different ways the team at Microsoft contributes to the Postgres ecosystem, from our Azure managed services to Postgres open-source community contributions.

Highlights from the Postgres community work done by our team at Microsoft

Serve on organizing & talk selection teams for multiple Postgres events: The in-person Postgres community conferences are a great way to learn, share your expertise, and connect with other Postgres people. And if you lean into the “hallway track”, you might be surprised by the doors it can open.

Over the past 13 months, members of our Postgres team at Microsoft have served on the organizing committees or talk selection teams for these 9 Postgres community conferences, in time-order (oldest to most recent):
- PGConf.dev 2025 (Melanie Plageman)
- PGConf NYC 2025 (Daniel Gustafsson)
- PostgreSQL Down Under (PGDU) 2025 (Thomas Munro)
- Prague PostgreSQL Developers Day (P2D2) 2026 (Tomas Vondra)
- FOSSASIA PGDay 2026 (Amit Langote)
- PGConf India 2026 (Thomas Munro)
- Nordic PGDay 2026 (Daniel Gustafsson)
- PostgreSQL Conference Germany 2026 (Cornelia Biacsics)
- PGConf.dev 2026 (Melanie Plageman, Claire Giordano)

Co-organize PGConf.dev annual PostgreSQL development conference: Special shout-out to Melanie Plageman, who is part of the team that organizes PGconf.dev, which in the last 3 years has become a “go to” event. This annual gathering (the successor to PGCon) is unique in how it brings together current and future PostgreSQL hackers from around the world to collaborate in person. (link to PGConfdev 2026 schedule)
Sponsor 17 Postgres conferences around the world: Postgres community conferences don’t just happen—they rely on financial support to bring people together. Over the past ~13 months, our team at Microsoft has sponsored these 17 in-person Postgres events:
- PGConf.dev 2025 – Gold
- Hyderabad PG Days 2025 – Sponsor
- PGDay Austria 2025 - Silver
- PGDay UK 2025 – Benefactor
- PGDay Lowlands 2025 – Supporter
- PGDay Napoli 2025 – Supporter
- PGConf NYC 2025 – Platinum
- PGConf EU 2025 in Riga – Gold
- PG Down Under 2025 – Silver
- Prague PostgreSQL Developers Day (P2D2) 2026 – Bronze
- FOSSASIA PGDay 2026 - Silver
- PGConf India 2026 – Diamond
- Nordic PGDay 2026 – Supporter
- PostgreSQL Conference Germany 2026 – Silver
- PGConf.dev 2026 – Gold
- PG DATA 2026 (formerly PGDay Chicago) – Gold
- PGDay Boston 2026 – Silver

Figure 4: Logos of the PostgreSQL community conferences our Microsoft team is proud to have sponsored over the last 13 months—along with thanks and gratitude to the conference organizers for making these events happen.

POSETTE: An Event for Postgres: POSETTE is a free & virtual developer conference organized by our Postgres team at Microsoft. Now in its 5^th year, and aided by the fact that it’s virtual, it’s safe to say POSETTE is the largest Postgres event in the world—bringing together developers, users, contributors, and experts from across the globe to share their knowledge. (link to PosetteConf.com)

Last year’s event in June 2025 was a hit—and you can still watch all of last year’s talks on the POSETTE 2025 playlist on YouTube.

Special thanks to my teammates on the 2026 talk selection team—Daniel Gustafsson, Divya Bhargov, and Melanie Plageman—for reviewing all 238 of this year’s talk proposals. And of course POSETTE 2026 would not be happening without the full organizing team behind POSETTE 2026, nor without the partnership and financial support from AMD.

Looking ahead, POSETTE 2026 is coming up soon: 16-18 Jun, online. With 4 livestreams, 2 keynotes, 44 talks, and 50 speakers, there’s something for everyone.
- Check out the schedule on the PosetteConf website.
- Register: To make sure you don’t get doublebooked, register for the POSETTE 2026 livestream(s) that works for you:
  - Livestream 1 / Livestream 2 / Livestream 3 / Livestream 4
- If you attend live, the benefit is: you’ll be able to ask the speakers questions in the text chat on Discord while the talks are being livestreamed—and be part of the conversation. It’s a good way to connect with the speakers and the community.
- Can’t make it live? No problem, you can always catch the 2026 talks later on YouTube.

Figure 5: POSETTE: An Event for Postgres 2026 is a free and virtual developer event, organized by our Postgres team at Microsoft and now in its 5^th year. This graphic gives you a map of the 44 talks in POSETTE 2026, from the keynotes to the Postgres core talks, Postgres ecosystem talks, and Azure Database talks too.

Talking Postgres podcast: Hard to believe, but our monthly podcast is now over 3 years old—with 39 episodes published as of the date of writing. Focused on the human side of Postgres, the conversations dig into why people who work with Postgres do what they do—and how they got to where they are. (link to podcast)

In the past year alone, I’ve had the chance to talk with these amazing people: Adam Prout, Andres Freund, Boriss Mejías, Charles Feddersen, Gwen Shapira, Melanie Plageman, Rob Emanuele, Shireesh Thota, Simon Willison, Tomas Vondra, Luigi Nardi, Peter Cooper, and Peter Farkas.

You can find all episodes at Talking Postgres.com, on the YouTube playlist, or wherever you get your podcasts. Bonus: we record episodes live on the Microsoft Open Source Discord, where you can join the parallel live text chat during the show. It’s a fun way to connect with the community in real time.
Deliver 63 conference talks at Postgres events: Both in-person and virtually, our Postgres teams have been sharing their expertise with the user and developer community on the conference circuit—delivering 63 talks in the last 13 months.
Organize Postgres user groups & meetups: User groups and meetups are a great way to learn and meet other Postgres users and contributors—but it takes work to make it all happen: to find locations, line up speakers, organize food and drink, and get the word out.

+1 to those on our team at Microsoft—and to everyone—who volunteer their time and partner with others in the Postgres community to help organize local Postgres user groups, including:
- Malmö PostgreSQL User Group (M-PUG): Daniel Gustafsson (link to meetup)
- Prague PostgreSQL Meetup: Tomas Vondra (link to meetup)
- PostgreSQL User Group Vienna: Cornelia Biacsics (link to meetup)
Hosting local meetups at Microsoft: Shout-out to the people involved in making Microsoft offices available as venues for local Postgres meetups, including:
- Postgres Bangalore (PGBLR) Meetup: hosted at the Microsoft office in Feb 2026 (post by Nitin Jadhav about the meetup)
- Barcelona (+Valencia) PostgreSQL User Group: hosted at the Microsoft office in Oct 2025 (link to meeting #4 at Microsoft)
Serve on Postgres core team, project committees, & PGCA Board of Directors: Every open source project needs governance, and there are many teams and efforts that comprise the project beyond code. Shout-out to:
- Andres Freund from Microsoft serves on the PostgreSQL Core Team.
- Melanie Plageman serves on the PostgreSQL Contributors committee.
- Noah Misch and Andres Freund serve on the PostgreSQL Security team.
- Claire Giordano serves on the board of directors for the PostgreSQL Community Association (PGCA) non-profit, an organization that stewards the PostgreSQL brand assets including trademarks and domain names. (link to PostgreSQL governance / link to PGCA non-profit)
Benefactor sponsor of PostgreSQL Community Association (PGCA) non-profit: As of May 2026, Microsoft is a Benefactor sponsor of the PGCA non-profit and the PostgreSQL project, providing financial support to protect the PostgreSQL project’s trademarks and brand assets. (link to PGCA non-profit website)
PostgreSQL developer meetings: Twice a year the developer community hosts invitation-only summits—typically coinciding with FOSDEM PGDay and PGConf.dev—to discuss “wicked problems”, technical issues, or development processes that are not easily addressed over email. Members of our Postgres contributor team have a seat at this table.
Blogging: The blog platform where our Postgres team has been publishing the most in the last year—with 99 new posts—is on Microsoft Tech Community. Blogging continues to be a super useful way to share information—and when I’m researching something at 2AM, I’m definitely appreciative of all the Postgres people who take time to share information via blog! (link to the Microsoft Blog for PostgreSQL)
Contribute to Patroni 4.0.x and 4.1.x: Patroni is a popular High Availability (HA) solution for Postgres. It helps you deploy, manage, and monitor HA clusters using streaming replication—and it’s open source. Alexander Kukushkin from our team is the technical lead and collaborates with engineers from different companies on Patroni.

In the last 13 months, Patroni added Postgres 18 support as well as support for patronictl demote-cluster and patronictl promote-cluster which automate switching of a Patroni cluster between primary and standby cluster roles.

I started to include individual release notes links for the last 13 months but there were too many to list: 5 minor releases and 1 new major release. (link to Patroni release notes)

Microsoft ❤️ Postgres

For the 4^th year in a row, this blog post is a snapshot of the work our Postgres team at Microsoft has done over the last year. There are too many contributors to name—but without their efforts, this post would not exist.

As I wrap-up, I’m struck by just how many ways the team at Microsoft shows up for Postgres. We run a managed Postgres service on Azure—and in the past year, we’ve launched a new Postgres extension for VS Code as well as a new Postgres database service called Azure HorizonDB (in Preview). We contribute upstream to the PostgreSQL project with code, architecture, reviews, testing, extensions, volunteering in the community, organizing user groups, and more. We maintain open source projects like Citus and Patroni. To share expertise, we write blog posts and give talks. We sponsor and help organize conferences—including POSETTE, the world’s largest virtual event for Postgres. And yes, we even produce a monthly podcast.

And the infographic that pulls it all together? I think it's a work of art.

********************

Acknowledgements

In addition to significant contributions by this blog post’s co-authors Guy Bowerman (Azure Database for PostgreSQL chapter) and Sumedh Pathak (PostgreSQL core chapter), many thanks to people who contributed to this year’s blog post: Abe Omorogbe, Brian Holt, Denzil Ribeiro, Dingding Lu, Isaac Alves, My Nguyen, Shreya Aithal, and Silvano Coriani. I could not have pulled this together alone: thank you!

Introducing Durable Functions in PostgreSQL

abeomor-msft — Tue, 09 Jun 2026 17:28:31 GMT

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 →

Figure 1: 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.

Figure 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:

Figure 3: AI pipelines and pg_durable in VSCode extension

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

Make upgrades predictable with Pre-Upgrade Validation Checks

varun-dhawan — Thu, 11 Jun 2026 14:31:16 GMT

Major version upgrades are an important part of keeping PostgreSQL environments current with the latest features, security updates, and performance improvements. But for production workloads, the hardest part is often not the upgrade itself - it is knowing whether the server is ready before the upgrade window begins.

Today, we’re announcing the Public Preview of Pre-Upgrade Validation Checks for Azure Database for PostgreSQL. This new capability lets you validate upgrade readiness before starting the actual major version upgrade, helping you identify and resolve blockers early.

With Pre-Upgrade Validation Checks, you can run upgrade checks independently, review actionable results, fix issues, and re-run validation until your server is ready. This shifts upgrade troubleshooting from the upgrade window to a proactive pre-flight step.

Why this matters

Azure Database for PostgreSQL flexible server already supports in-place major version upgrades using PostgreSQL pg_upgrade. The service preserves the server name and connection settings, runs upgrade prechecks, takes an implicit backup when checks pass, and then performs the engine upgrade.

Pre-Upgrade Validation Checks extend this model by decoupling validation from upgrade execution.

Instead of: Upgrade → Discover issue → Troubleshoot → Retry

You can now follow: Validate → Fix → Re-Validate → Upgrade

This helps reduce failed upgrade attempts, improves planning, and gives teams more confidence before entering a production change window.

What Pre-Upgrade Validation Checks validate

Pre-Upgrade Validation Checks evaluate both Azure-specific upgrade requirements and PostgreSQL compatibility checks, including pg_upgrade --check.

At a high level, the validation covers:

Configuration and platform prerequisites, such as server state, target version support, storage headroom, and upgrade readiness.
Extension compatibility, including unsupported or version-sensitive extensions.
Database dependencies and objects, such as read replicas, logical replication slots, event triggers, PostGIS search_path, and upgrade-sensitive objects.
Engine compatibility, using PostgreSQL pg_upgrade --check.

If a blocking issue is found, the result includes details to help you understand what needs to be fixed before retrying validation or starting the upgrade.

How to run Pre-Upgrade Validation Checks from the Azure portal

You can run Pre-Upgrade Validation Checks directly from the existing Upgrade experience in the Azure portal.

Step 1: Select `Validate only`

From your Azure Database for PostgreSQL flexible server, select Upgrade. Choose the target PostgreSQL version, then select Validate only as the action. This runs validation checks without starting the actual upgrade.

Figure 1: Select Validate only before starting upgrade

Step 2: Review successful validation results

If all validation checks pass, the result shows a successful status. At this point, the server is ready to proceed with the major version upgrade.

Figure 2: Successful validation results

In this example, all pre-upgrade validation checks completed successfully, and no blocking issues were detected for the selected target PostgreSQL version.

Step 3: Review and fix validation errors

If validation detects issues, the results page shows failed checks with details and remediation guidance. You can fix the reported issues and run validation again.

Figure 3: Failed validation with remediation details

In this example, validation found an event trigger issue before the upgrade was started. The upgrade action remains blocked until the issue is resolved and validation passes.

Step 4: Download validation results

You can also download the validation results as a CSV file. This makes it easier to share findings with DBA, application, platform, or support teams before the actual upgrade window.

Figure 4: Download validation results as CSV

The CSV output is useful for offline review, internal tracking, and support collaboration.

Recommended workflow

Use Pre-Upgrade Validation Checks as part of your upgrade planning process: run validation early, review the results, fix any reported blockers, re-run validation until all checks pass, and then proceed with the major version upgrade.

What happens after validation passes?

Once validation succeeds, you can proceed with the major version upgrade using the existing Azure PostgreSQL upgrade workflow. The actual upgrade remains a separate operation and still includes the managed backup and pg_upgrade execution steps.

Pre-Upgrade Validation Checks do not remove the upgrade downtime window. Instead, they help ensure that known blockers are resolved before that window begins.

Frequently asked questions

Does Validate only perform the upgrade?

No. The Validate only option runs readiness checks without upgrading the server. The actual major version upgrade remains a separate action.

Does this remove downtime?

No. Major version upgrades still require an execution window. The benefit is that compatibility issues can be discovered and resolved before downtime begins.

Can I re-run validation?

Yes. Validation is designed to be repeatable. You can fix reported issues and re-run checks until all validations pass.

What types of blockers can be detected?

Common examples include unsupported extensions, logical replication slots, event triggers, insufficient storage headroom, configuration issues, and PostgreSQL compatibility findings from pg_upgrade --check.

Get started

Pre-Upgrade Validation Checks are now available in Public Preview for Azure Database for PostgreSQL flexible server.

To try it, open your flexible server in the Azure portal, go to Upgrade, select your target PostgreSQL version, and choose Validate only.

Learn more

To learn more about major version upgrades and related Azure PostgreSQL capabilities, see:

Validate early. Fix with confidence. Upgrade when ready.

Announcing new security, maintenance and analytics features for PostgreSQL at Microsoft Build 2026

GuyBowerman — Mon, 29 Jun 2026 22:36:55 GMT

At Microsoft Build 2026, we’re announcing a major wave of PostgreSQL innovation across Azure. Alongside the public preview of Azure HorizonDB, we’re delivering a broad set of enhancements for our fully managed open-source PostgreSQL service: Azure Database for PostgreSQL flexible server. These updates span performance, analytics, security, operations, resilience and migration - helping you build faster, operate with more control, secure your workloads, and modernize with confidence.

Here’s a quick tour of the top flexible server announcements at Build 2026.

Feature Highlights

pg_duckdb Extension
pg_ivm Extension
Defender Security assessments
temporal_tables Extension
Cross-tenant CMK
Automatic Entra token refresh libraries
New Powershell module: Az.PostgreSQLFlexibleServer
More control over planned maintenance
Pre-Upgrade validation checks
New Built-in Grafana dashboards
Chaos Studio supports Azure Database for PostgreSQL
AI-assisted Oracle to PostgreSQL migration
Migration Service for Azure Database for PostgreSQL improvements (EDB, AlloyDB)

Performance, Scale & Analytics

pg_duckdb Extension Generally Available

The pg_duckdb extension enables you to accelerate high-performance analytics and data-intensive applications with DuckDB’s SQL engine running inside your Postgres server. We’re pleased to announce pg_duckdb is now generally available in Azure Database for PostgreSQL. The latest version builds on the preview with the latest DuckDB engine improvements and optimized performance. This version adds vectorized execution for faster analytical queries, delivering significant improvements in aggregation performance, along with new support for writing to Azure Blob Storage and querying Parquet data directly from PostgreSQL. These capabilities enable high-performance analytics on your external data and simplify data processing workflows. Learn more: pg_duckdb.

pg_ivm Extension Generally Available

Materialized views are a useful way to optimize performance for queries that run regularly, but if underlying data becomes stale the result set needs to be recomputed. With the pg_ivm extension you can automatically maintain materialized views as the underlying data changes. This is particularly valuable for large datasets with small incremental changes that need real-time freshness, like dashboards, catalog analytics and SaaS usage reporting. We are pleased to announce the pg_ivm extension is now generally available in Azure Database for PostgreSQL. Learn more: pg_ivm.

Security, Auditing & Identity

Defender security assessments Preview

Microsoft Defender Security Assessments for Azure Database for PostgreSQL enables continuous evaluation of your database security posture, helping identify vulnerabilities and misconfigurations across server and database configurations. Previously limited to reactive threat detection, in the latest preview release, Defender now provides proactive, risk-based insights through assessments tailored to PostgreSQL-specific best practices, delivering more relevant and actionable guidance. This helps you strengthen your security baseline, prioritize remediation, and align with best practices and compliance requirements. Learn more: https://aka.ms/Defender-Assessments-for-PG-Preview

temporal_tables Extension Generally Available

We’ve had many customer requests to support the temporal_tables extension, which provides built-in support for tracking and querying historical changes to data over time. Temporal tables are now generally available in Azure Database for PostgreSQL. With this extension enabled you can easily perform time-based queries, audit data changes, and maintain historical records without building custom tracking logic, simplifying application development and compliance scenarios. Learn more: temporal_tables

Cross-tenant CMK Preview

Azure Database for PostgreSQL now supports cross-tenant customer-managed keys (CMK) in public preview, allowing you to encrypt your data at rest using an Azure Key Vault key that resides in a separate Microsoft Entra tenant from the database service. This feature is designed for SaaS providers and enterprises that need to maintain strict separation of duties and ownership of encryption keys, enabling you to retain full control over key lifecycle management while PostgreSQL runs in a service provider’s tenant. Learn more: Data encryption at rest in Azure Database for PostgreSQL

Automatic Entra token refresh libraries Preview

We’re making it easier to use Entra ID authentication with Azure Database for PostgreSQL throughout the application stack by introducing new token refresh libraries for .NET, JavaScript, and Python.

With Entra ID, access tokens are short-lived which can make managing their lifecycle complex in real-world applications. Developers need to be aware of token refresh and build additional handling around token expiration, connection retry, and session continuity.

These new libraries remove that friction. By handling Entra token refresh seamlessly in the background, they allow applications to stay connected without interruption and with no custom logic required. The result is a simpler development experience and more resilient applications, especially for long-running or connection-heavy workloads.

Across languages, the libraries provide a consistent and streamlined way to adopt secure, passwordless authentication, helping teams focus more on building their applications and less on managing authentication. Learn more: .NET, JavaScript, and Python.

Operations, Maintenance & Monitoring

New Powershell module: Az.PostgreSQLFlexibleServer Generally Available

We’re excited to introduce the newly renamed Az.PostgreSQLFlexibleServer PowerShell module, delivering a streamlined experience for managing Azure Database for PostgreSQL with PowerShell. Building on the capabilities of the previous Az.PostgreSql module, the updated module aligns with the new features in the 2026-01-01 preview REST API. This module brings support for PostgreSQL 18, elastic clusters for scalable workloads and a range of enhancements designed to simplify management and improve performance. Whether you're provisioning new deployments or managing complex environments, this module ensures you can take full advantage of the latest platform capabilities directly from PowerShell.

To learn more, visit our official documentation on PowerShell: Az.PostgreSql Module | Microsoft Learn

More control over planned maintenance Generally Available

We’ve seen many requests to provide more control when a maintenance update is applied to Azure Database for PostgreSQL. Sometimes when a critical workload is running you want to apply the maintenance when you’re ready. Announcing general availability this week, we’re building on the existing System and Custom maintenance window options and adding new self-service maintenance capabilities to the Azure portal.

You can now reschedule upcoming maintenance updates for up to two weeks and apply maintenance on demand at a time that suits you. You can also view scheduled maintenance and review your server’s maintenance history after updates are complete.

These options help you better align maintenance with your business schedules, reduce disruption during critical workload periods, and minimize the need for support-driven deferral requests. CLI and API support are coming soon. Learn more: https://aka.ms/azure-postgres-reschedule-maintenance

Pre-Upgrade validation checks Preview

PVC detects an event trigger blocker before upgrade execution and keeps the upgrade action disabled until issues are resolved.

Major version upgrades are critical for staying current with PostgreSQL features, security updates, and performance improvements, but you often discover blockers only after starting the upgrade workflow. Pre-Upgrade Validation Checks lets you validate upgrade readiness before initiating the actual upgrade by running Azure-specific upgrade checks and PostgreSQL pg_upgrade --check validations independently.

The shift is simple: you can identify and fix upgrade blockers before the upgrade window begins. The feature surfaces actionable issues across configurations, extensions, dependencies, replication slots, event triggers, and other upgrade-sensitive objects. You can fix blockers, re-run validation until all checks pass, and proceed with the upgrade with greater predictability.

Learn more: https://aka.ms/pg-flex-upgrade-checks

New Built-in Grafana dashboards Generally Available

Monitor Azure PostgreSQL with built-in Grafana dashboards — no setup, no extra cost, and no separate service to manage.

Grafana dashboards are now built directly into the Azure portal for Azure Database for PostgreSQL - no setup, no extra cost, and no separate service to manage. You can open your PostgreSQL resource in the portal and immediately access prebuilt dashboards for key health and performance signals such as CPU, memory, storage, IOPS, connections, transactions, and availability.

The key value is metrics + logs in one place. You can quickly correlate performance spikes with PostgreSQL logs, understand what changed, and troubleshoot faster using the familiar Grafana experience. Dashboards can also be customized, saved to your subscription, and shared across teams for ongoing operations.

Learn more: https://aka.ms/azure-postgres-dashboards-grafana

Resilience & Business Continuity

Chaos Studio supports Azure Database for PostgreSQL Preview

No matter how much you prepare, you only really know how good your database disaster recovery plan is when something breaks. With Chaos Studio support for Azure Database for PostgreSQL, you can simulate zone-down scenarios on PostgreSQL HA-enabled instances and validate the resilience of your mission-critical workloads.

With Chaos Studio integration, you can proactively test failover behavior and gain confidence in how your applications respond to real-world zonal failures.

This feature is currently available through a gated private preview. To get started, submit your subscription details using the form. Once reviewed, our team will enable the feature for your subscription, with guidance to help you begin testing.

Getting started is simple:

Create a Chaos Studio workspace via the Chaos Studio portal and configure your subscription, resource group, and region.
Define the scope and assign the required managed identity and permissions.
Review and verify your workspace setup.
Browse available scenarios and select the PostgreSQL zone-down scenario.
Configure the test (name, duration), then run it from My Library to begin validating failover behavior.

With just a few steps, you’ll be able to simulate real-world failure conditions and gain confidence in your application’s resilience.

To get started, please submit your details using this link: Private Preview Support for Chaos Studio

Migration & Modernization

AI-assisted Oracle to PostgreSQL migration Generally Available

AI-assisted migration tooling has dramatically lowered the bar for moving between different databases and is changing the way people look at the return on investment for migration. The VS Code PostgreSQL extension comes with AI-Assisted migration tooling which converts Oracle schema and application code to Azure Database for PostgreSQL. This tooling uses GitHub Copilot, Microsoft Foundry, and custom Language Model tools to convert Oracle schema, database code and client applications into the PostgreSQL equivalents, and validates every change against a running flexible server instance. Learn more: Schema conversion, App conversion.

Migration Service for Azure Database for PostgreSQL improvements (EDB, AlloyDB) Generally Available

We’ve added AlloyDB and EDB Extended Server as new sources for migrating to PostgreSQL in the Azure Database for PostgreSQL Migration Service, with support for both online and offline migration support. Learn more: Migrate from AlloyDB, Migrate from EDB.

Looking ahead

That wraps up the Build 2026 announcements for Azure Database for PostgreSQL flexible server. There are also many great PostgreSQL technical sessions at Build this week, covering cloud-native app & AI development and migration. To find out more, here's a link to the Build session catalog for PostgreSQL sessions: https://aka.ms/Postgres-on-Azure_Build-2026.

We'll continue to build out our roadmap over the coming months to deliver on your asks to improve the performance, security and stability of your PostgreSQL workloads. Check the Microsoft Blog for PostgreSQL for a regular monthly recap where we share the latest enhancements and product updates.

Azure HorizonDB: Enterprise-Ready Postgres, Engineered for the AI Era

charlesfeddersenMS — Tue, 02 Jun 2026 16:45:15 GMT

Affan Dar, Vice President of Engineering, PostgreSQL at Microsoft
Charles Feddersen, Partner Director of Program Management, PostgreSQL at Microsoft

Today at Microsoft Build, we’re pleased to announce the public preview of Azure HorizonDB, a new enterprise-ready Postgres-compatible database service designed to meet the needs of modern AI applications, alongside a set of enhancements to our PostgreSQL tooling in Visual Studio Code to further streamline the developer experience.

Postgres is rapidly solidifying its role as a foundational layer in modern data architectures, with accelerating adoption across industries. For developers, it has become the preferred platform for new application development, driven by its extensible architecture, mature extension ecosystem, and adherence to open standards and APIs. At the same time, enterprises are choosing Postgres to re-platform and modernize existing systems, taking advantage of its ability to support a broad range of operational workloads while enabling advanced capabilities such as vector-based data access all within a single, interoperable platform.

A Postgres Platform Grounded in Security, Resilience, Scale, and Performance

Azure HorizonDB is purpose-built to meet these demands, combining the flexibility developers expect from Postgres with the operational rigor enterprises require. It extends the core Postgres engine with cloud-native capabilities such as integrated identity, fine-grained network and security controls, and seamless lifecycle management, while preserving full compatibility with the open ecosystem of extensions and tools. At the same time, HorizonDB introduces advanced, natively integrated capabilities like vector data support and AI model management, enabling new classes of intelligent applications without sacrificing transactional integrity or developer productivity.

These capabilities are backed by a platform designed for enterprise performance and scale. HorizonDB supports databases up to 128 TB, scales out with up to 15 read replicas for high-throughput workloads, and delivers sub-millisecond commit latency across availability zones for low-latency transactions and high availability. This combination is critical for modern applications that require consistent performance under load, including high-concurrency transactional systems, real-time AI-driven interactions, and globally distributed services.

The result is a unified platform that scales from the first line of code to globally distributed, mission-critical systems. Enterprise adoption ultimately depends on trust in the platform itself. Azure HorizonDB delivers this with native integration into Microsoft Entra ID for centralized identity and access control, private endpoints for network isolation, and built-in encryption to protect data at rest and in transit. These capabilities are essential for meeting compliance requirements and enabling organizations to run mission-critical workloads with confidence, without added complexity.

This foundation is critical for any application, but it becomes indispensable for AI, where secure access to data and controlled model interaction underpin every intelligent experience. Building on this, HorizonDB introduces a set of integrated AI capabilities designed to bring intelligence directly into the database.

Run Fast, Memory-Efficient Vector Search with DiskANN

HorizonDB brings high-performance vector search directly into Postgres through DiskANN with spherical quantization. This enables efficient, low-latency similarity search at scale while significantly reducing memory and storage overhead. Spherical quantization works by normalizing vectors and encoding them into compact representations that preserve angular distance, allowing the system to compare vectors efficiently with minimal loss in accuracy. The result is the ability to index and query large embedding datasets within the transactional engine itself, making vector search a first-class capability rather than an external dependency.

"HorizonDB is compelling because it brings a PostgreSQL-compatible foundation, AI-native capabilities and enterprise-grade controls closer to the operational data layer."

Jennings Balavari, Founder, Opsen AI

Build Smarter Apps with Hybrid Search in Postgres

HorizonDB supports hybrid search by combining vector similarity through pgvector with full-text search enabled via the pg_textsearch extension, allowing applications to match both semantic meaning and precise keyword relevance in a single query. This enables more accurate, context-aware results, such as blending intent-driven retrieval with exact term matching for search, recommendations, or RAG scenarios. By unifying these capabilities within Postgres, HorizonDB improves result quality while simplifying application design without the need for external search systems.

Operationalize AI with Built-In AI Model Management

Working with vectors requires models to generate, interpret, and evolve embeddings, making model lifecycle a core part of the application stack. HorizonDB introduces integrated AI model management to simplify how models are registered, versioned, and governed alongside data, including built-in support for generative GPT models and ranking models. For example, GPT models can be used to generate summaries, responses, or structured outputs directly from application data, while ranking models enable relevance scoring for search results or recommendations over vector results. By managing these models alongside the data they operate on, HorizonDB ensures consistency, traceability, and control, creating a unified environment where models and data evolve together.

“As we build a multi-tenant, AI-driven commerce platform, HorizonDB has been particularly compelling in two areas: scale and how close AI capabilities are to the data itself. Running vector search, filtering, and model-driven workflows directly inside the database removes a lot of the complexity we’d normally manage across separate services."

James Frawley, CIAO, ReFiBuy

Bring AI into SQL with AI Functions

With models managed in place, AI Functions provide a direct way to invoke them from within SQL and application logic. These functions are implemented through the azure_ai extension, which brings model invocation directly into the Postgres engine. This allows developers to embed inference into queries and transactions, eliminating the need for external orchestration. By bringing model execution closer to the data, AI Functions reduce latency, simplify application design, and make intelligent behavior a natural extension of existing Postgres workloads.

"What stood out with HorizonDB is that it aligns closely with how we already think about the problem. Instead of stitching together multiple components, it brings transactional data, vector search, and AI capabilities into a single platform, which simplifies the architecture without forcing a complete rethink."

Mohsin Shafqat, Director Software Engineering, Nasdaq

Run Reliable, Event-Driven Workflows with AI Pipelines

Finally, AI Pipelines operationalize these capabilities through reliable, event-driven workflows for model execution and data processing. Pipelines execute on data changes, enabling real-time asynchronous reactions without external orchestration and ensuring consistent, repeatable behavior as data evolves. Combined with model management and AI Functions, they turn embedded intelligence into something that can be run, scaled, and trusted in production, while inheriting the database’s high availability and failover characteristics for resilience. Pipelines can also be visualized and observed in real time through the Visual Studio Code extension for PostgreSQL, giving developers and operators immediate visibility into execution flow, state, and outcomes

Modern Unified Experience for Data, AI, and Operations in VS Code

As intelligence becomes a core part of the data platform, the developer and operator experience becomes equally critical. HorizonDB extends seamlessly into Visual Studio Code with enhanced PostgreSQL tooling that works across any Postgres deployment, not just HorizonDB. Features like AI-assisted query plans and integrated monitoring enable faster debugging and optimization, helping teams understand both database performance and AI-driven behaviors.

At the same time, for Azure-based deployments, the experience is deeply integrated with platform capabilities, enabling management of networking configuration, server parameters, and server logs directly from the development environment, streamlining operations across application and infrastructure layers.

Azure HorizonDB brings together enterprise-grade security, deep Postgres compatibility, and a modern AI-native data platform, all engineered for developers. It scales efficiently across workloads, from transactional systems to intelligent applications, while delivering a world-class, Azure-integrated experience in Visual Studio Code for both developers and operators.

Ready to get started with Azure HorizonDB?

Azure HorizonDB is now available in public preview in Australia East, Central US, Sweden Central, West US 2, and West US 3 regions. Additionally, East US, Canada Central, Indonesia Central, Italy North, Japan East, Korea Central, and Poland Central will be available in the coming weeks.

You can get started today by creating a new HorizonDB instance using the Azure portal, API’s, or the Visual Studio Code extension for PostgreSQL to begin exploring these capabilities firsthand.

To learn more, dive deeper into our documentation and sign-up today to try AI model management in a limited preview.