Azure HorizonDB Adds PostgreSQL 18 in Non-Production Preview

Azure HorizonDB Adds PostgreSQL 18 to Its Public Preview​

The Azure Updates entry is brief. Titled "Public Preview: Azure HorizonDB supports PostgreSQL 18," it carries the In preview status. On the Azure Updates site, that status means a feature is available to all Azure customers for non-production use and testing. It sits between In development, which is limited to selected customers, and Launched, which Microsoft reserves for fully released, production-ready products. The listing does not give a staged rollout schedule, a region list for PostgreSQL 18 specifically, or any version-specific limitations.

HorizonDB has been around for less than a year. Microsoft unveiled Azure HorizonDB at the Ignite conference, a new fully managed, scalable, and high-throughput PostgreSQL cloud database in private preview, in November 2025. According to Microsoft's PostgreSQL team, the service reached broad availability at Build 2026, when the company announced the public preview of Azure HorizonDB, a new enterprise-ready Postgres-compatible database service designed to meet the needs of modern AI applications. The SQLYard blog explained that the move to public preview means it can now be provisioned directly without an application process.

The update also appears to have arrived ahead of Microsoft's own documentation. At the time of writing, the HorizonDB Learn quickstart still named PostgreSQL 17 as the supported engine version. That conflicts with the new announcement. The most likely explanation is that the documentation hasn't caught up yet. Still, anyone planning a test deployment should check which versions the Azure portal or API actually offers in their subscription and region before scripting a deployment around version 18.

PostgreSQL 18 Now Runs on HorizonDB's Log-Based Architecture​

HorizonDB is Microsoft's alternative to running PostgreSQL on a virtual machine with attached disks, and that explains why version support on this service is a separate story. Microsoft's Learn overview says the service rests on two principles: separating compute from storage, and a database-as-a-log design. In that design, compute nodes write only the write-ahead log (WAL) to storage, never data pages. A purpose-built WAL service acknowledges each transaction once the log record is durable. Storage nodes then replay the WAL to rebuild page state, which Microsoft says removes the usual checkpoint I/O bottleneck and reduces write amplification.

This design takes a lot of work away from the PostgreSQL engine. According to the Learn overview, HorizonDB moves several jobs from the compute replicas to the storage layer: WAL archiving, background dirty-page writing, checkpointing, backups, full-page writes, and read-replica redo. Compute replicas are stateless and come with 8 GB of memory per provisioned core, plus a local NVMe cache for frequently used pages. A cluster has one writable primary and any number of readable standbys. All of them share a single zone-resilient copy of the data, so adding a read replica doesn't require copying any data.

Microsoft has made bold performance claims for this design. At launch, the company said the scale-out compute architecture supports up to 3,072 vCores across primary and replica nodes, and the auto-scaling shared storage supports up to 128TB databases, and that it could deliver up to 3x more throughput when compared with open-source Postgres for transactional workloads. These figures come from Microsoft. No independent benchmark of HorizonDB running PostgreSQL 18 has been published. Redmondmag columnist commentary described the engine as using disaggregated storage, zone-redundant architecture and a Rust-based engine to target large, cloud-native workloads.

Because HorizonDB rebuilt the storage layer underneath PostgreSQL, a new major engine release isn't a simple repackaging job the way it can be on a conventional managed server. The PostgreSQL 18 preview is Microsoft's statement that the new engine works with this custom storage stack. The preview label shows that Microsoft is not yet willing to support it for production workloads.

HorizonDB's Preview Gaps Matter More Than the PostgreSQL 18 Upgrade​

If you're wondering whether this announcement changes HorizonDB's production readiness, the answer is no. The service's documented limitations are the same as before, and several of them block typical enterprise deployments. The Learn overview, last updated June 2, 2026, lists these features as not yet available or not available in the preview:

Compliance teams will likely focus on the lack of customer-managed keys and cross-region replicas. Operations teams will notice that they can't control maintenance windows. None of these gaps is related to the PostgreSQL version, so none of them closes with this update.

Regional availability also limits where you can test. The Learn overview lists HorizonDB in Canada Central, Central US, East US, West US 2, and West US 3 in the Americas; Germany West Central and Sweden Central in Europe; and Australia East and Korea Central in Asia Pacific. Microsoft notes that some regions might restrict new deployments. The Build announcement also promised that East US, Canada Central, Indonesia Central, Italy North, Japan East, Korea Central, and Poland Central will be available in the coming weeks. Some of those regions don't appear in the June documentation list, so confirm your region in the portal. The PostgreSQL 18 announcement doesn't say whether version 18 is available in every HorizonDB region.

Billing during the preview has three parts: provisioned compute in core hours, database storage used per GB per month, and backup storage used within the short-term retention period. Test clusters therefore cost money. Tear them down when you finish testing.

Azure Database for PostgreSQL Flexible Server Already Runs PostgreSQL 18 in Production​

Teams that need PostgreSQL 18 in production on Azure today don't need HorizonDB. Microsoft already has a generally available PostgreSQL 18 option on Azure Database for PostgreSQL flexible server. Microsoft says that when PostgreSQL 18 was released in September, we made a preview available on Azure on the same day. At Ignite 2025 it announced that PostgreSQL 18 is generally available on Azure Database for PostgreSQL, with full Major Version Upgrade (MVU) support. Flexible server's release notes show it keeping up with minor releases. The August 2026 notes list general availability of minor versions 18.6, 17.11, 16.15, 15.19, and 14.24, along with pre-upgrade validation checks that find problems blocking a major version upgrade before the upgrade starts.

Microsoft describes the difference between the two services this way: HorizonDB is the cloud-native service, while Azure Database for PostgreSQL is our database service for running open source PostgreSQL on Azure, delivering a fully managed experience for traditional PostgreSQL deployments. SQLYard compared flexible server to a managed instance of PostgreSQL running on attached storage, conceptually similar to how most SQL Server VMs work, which is a helpful comparison for Windows shops coming from SQL Server.

Flexible server's own PostgreSQL 18 preview gives an idea of what a version preview can involve, though it doesn't predict HorizonDB's behavior. During that preview, Microsoft listed restrictions including Microsoft Entra ID authentication not yet available in preview (support coming soon). Limited extension availability (see supported list). Query store and index tuning not available. In-place major version upgrades came only with general availability. HorizonDB's PostgreSQL 18 announcement doesn't list any version-specific restrictions. Treat that as missing information and test for yourself rather than assuming there are no restrictions.

Microsoft's HorizonDB documentation doesn't say whether an existing HorizonDB PostgreSQL 17 cluster can be upgraded in place to version 18, or whether you'll need a new cluster. For anyone who already has a HorizonDB test environment, this is the biggest open question. Plan for the possibility that you'll need to create a fresh cluster and migrate data into it.

What this means for you​

Teams already evaluating HorizonDB should add PostgreSQL 18 to their test plans now. Teams that need PostgreSQL 18 in production should stay with flexible server. The announcement gives both groups something to act on, but it doesn't allow anyone to move production workloads onto HorizonDB.

For a test deployment, connecting works like any other PostgreSQL server. Microsoft's connectivity guide says HorizonDB works with existing PostgreSQL clients, drivers, ORMs, and SQL syntax. Clusters expose a read-write primary endpoint and a read-only endpoint that load-balances across readable replicas. Both endpoints use standard connection strings on port 5432 with sslmode=require, and you'll find the endpoint details on the cluster's Overview page in the portal. Microsoft recommends enforcing TLS 1.2. Supported tools include the PostgreSQL extension for Visual Studio Code, which supports Microsoft Entra authentication for HorizonDB, as well as pgAdmin and psql in Azure Cloud Shell.

Extensions need the closest checking. HorizonDB publishes a list of its extensions and modules by PostgreSQL version, so if your application depends on a particular extension, confirm that it's listed for version 18 before you invest in testing.

• Treat HorizonDB with PostgreSQL 18 as a non-production test target only. Microsoft's In preview status explicitly excludes production use.
• Before you script a deployment, confirm in the Azure portal or API that version 18 is offered in your region, because HorizonDB's quickstart documentation still referred to PostgreSQL 17 at the time of writing.
• Check that your required extensions appear on HorizonDB's list for PostgreSQL 18, and don't assume extension support matches flexible server's.
• Expect to build a new cluster rather than upgrade an existing PostgreSQL 17 HorizonDB cluster, since Microsoft hasn't documented an in-place upgrade path.
• Measure your workload against the fixed seven-day backup retention and the lack of customer-managed keys, cross-region replicas, and configurable maintenance windows, because those gaps block production use regardless of engine version.
• Use Azure Database for PostgreSQL flexible server if you need PostgreSQL 18 in production today, since it has offered version 18 as generally available with major version upgrade support since Ignite 2025.

PostgreSQL 18 support brings HorizonDB level with the current PostgreSQL release, which should make it less of a gamble to start evaluating the platform now for a future migration. Whether HorizonDB is ready for production depends on Microsoft closing the gaps in backup retention, encryption keys, disaster recovery, and maintenance control. When those items disappear from the Learn limitations table and the service's Azure Updates status changes from In preview to Launched, PostgreSQL 18 testing done now will make the move to production quicker.