Microsoft has made PostgreSQL 18 generally available on Azure Database for PostgreSQL elastic clusters, its managed distributed PostgreSQL offering. The rollout is powered by Citus 14.0, the sharding extension that underpins elastic clusters, and it closes a gap that existed since Azure Database for PostgreSQL flexible server picked up PostgreSQL 18 in late 2025.
What elastic clusters are, briefly
Elastic clusters are Azure’s managed take on the open source Citus extension. One or more flexible server instances join together into a shared-nothing cluster, and PostgreSQL tables get distributed across nodes using row-based or schema-based sharding. Adding nodes triggers an online rebalance, so scaling out does not require blocking your workloads or a migration weekend.
The offering also carries some history. Elastic clusters are the successor to Azure Cosmos DB for PostgreSQL, which is on a retirement path and no longer accepts new deployments. Teams still running on Cosmos DB for PostgreSQL get a dedicated migration tool that Microsoft says usually finishes in under ten minutes, with a write-lock window of roughly five to eight minutes during cutover.
Unlike the old Cosmos DB offering, elastic clusters drop the dedicated coordinator surcharge and can run queries from any node. That change is more than a pricing tweak: it removes a bottleneck component from the architecture and simplifies capacity planning.
What PostgreSQL 18 brings to the cluster
Most of the headline work in PostgreSQL 18 came from the community release in September 2025, and it holds up well:
- An asynchronous I/O subsystem that queues multiple read requests concurrently, speeding up sequential scans, bitmap heap scans, and vacuum, with gains up to 3x when reading from storage.
- Skip-scan lookups on multicolumn B-tree indexes, which helps queries filter on the second column of an index without touching the first.
uuidv7(), which generates time-ordered UUIDs. In a sharded setup this matters more than usual, because sequential-ish keys pack better into shard-local index pages and reduce write amplification.- Virtual generated columns, OAuth 2.0 authentication,
OLDandNEWinRETURNINGclauses, and temporal constraints withWITHOUT OVERLAPS. - Wire protocol version 3.2, the first protocol revision since 2003, and deprecation of md5 password authentication.
Under Citus 14.0, several of these flow into distributed clusters with no code changes: asynchronous I/O, skip scans, and uuidv7() simply work. Others needed Citus-specific engineering, and that work landed. Virtual generated columns, temporal constraints, RETURNING OLD/NEW, and JSON_TABLE now behave correctly across shards, with the coordinator carrying PostgreSQL 18 EXPLAIN WAL fields through distributed EXPLAIN output.
Practical notes before you upgrade
If you run a single-node flexible server and want PostgreSQL 18 there, Microsoft already documented that path, including in-place major version upgrades from PostgreSQL 11 through 17. The catch is extensions: several are blocked on the upgrade path and need to be removed or re-planned first, including azure_ai, azure_storage, pg_diskann, pgrouting, pg_failover_slots, and azure_local_ai. Check your extension list before scheduling anything, because an upgrade job that stalls on a blocked extension is an annoying way to spend a maintenance window.
For teams on older distributed deployments, the advice is blunter. Cosmos DB for PostgreSQL is retiring, so the migration to elastic clusters is not optional, and doing it on PostgreSQL 17 before stepping up to 18 means one migration instead of a rushed one later.
Sharding decisions still on you
One thing the GA label does not change: elastic clusters handle the plumbing, but the data model is still your problem. Picking a distribution column, deciding which tables get co-located, and spotting cross-shard queries remain the same exercises they were under Citus on any platform. The troubleshooting guides Microsoft refreshed for flexible server do cover distributed diagnostics, but a bad distribution key will produce bad performance no matter how new the Postgres version is. If you are evaluating elastic clusters, budget a day to test your heaviest queries against a real dataset before committing.
Why this one matters
The pattern worth watching is turnaround time. The community shipped PostgreSQL 18 in September 2025; flexible server supported it within months; and now the distributed tier supports it within a year. Managed Postgres used to lag major releases by an awkward margin, which pushed teams toward self-managed clusters just to get current features. Azure has been closing that gap release by release, and elastic clusters inheriting upstream features through Citus updates, rather than through bespoke Microsoft patches, is the mechanism that makes it sustainable.
For anyone building multi-tenant SaaS or high-ingest pipelines, the combination is now concrete: PG18’s I/O and indexing work, uuidv7 keys, horizontal sharding, online rebalancing, and no coordinator tax, all as a single Azure resource with Entra ID auth and built-in connection pooling. That is a reasonable default for the next greenfield sharded Postgres deployment.
If you want to try it, the fastest path is creating an elastic cluster in the Azure portal or with az postgres flexible-server create --cluster-option ElasticCluster, then running your schema and ORM migrations against it to see which distributed queries need attention.