Joey on SQL Server

Microsoft Previews Azure HorizonDB as Cloud Native PostgreSQL Engine

Introduced at Ignite late last year, Azure HorizonDB is a new PostgreSQL service designed for higher performance and scalability, using disaggregated storage, zone-redundant architecture and a Rust-based engine to target large, cloud-native workloads.

• By Joey D'Antoni
• 01/08/2026

Microsoft has long been an active participant in the PostgreSQL community from an open-source code perspective, and the database has been an Azure Database offering since around 2017. Microsoft has come a long way with the service, adding features such as Query Store, support for calling AI models directly from the engine, and a robust database service. However, while the service is very competitive with Amazon RDS on features, there are still some gaps compared to Amazon Aurora, especially for larger workloads.

At Ignite in November, Microsoft introduced the private preview of Azure HorizonDB, a new PostgreSQL service with better performance, greater scalability, and many of the same features as Azure Database for PostgreSQL. I had a chance to chat with the product team about the new service and wanted to report on the service.

One of the things I've enjoyed about using PostgreSQL on Azure and working with the product team is their transparency about their architecture. For example, if you are building an Azure Database for PostgreSQL, you get to choose your VM size, the type of performance of the disk you want and if you need high availability (HA) configured. While HorizonDB is more static in its hardware configuration, the team has been fully transparent about the service's architecture.

You can see their launch presentation from Ignite here; I highly recommend watching it, but let's talk about it at a high level. If you are coming from a SQL Server background, you may notice that HorizonDB shares some design patterns with Azure SQL Database Hyperscale. Both services are designed for the cloud first, rather than fitting an existing service into a cloud model. The biggest advantage in doing so is that storage is largely disaggregated from compute, which allows scaling and failover operations to not be "size of data" operations.

A size of data operation is what database professionals call, when an operation -- say a failover or a recovery, requires the entire set of data to be written again. Let's think of something simple, like changing the data type of a column to something larger. If the database engine can't implement that change simply, it may require rebuilding the entire table in a background task or even taking an outage for that table. Anything database engines can do to reduce the amount of size of data operations is a good thing.

You may have heard about the recent controversy around a rumor that Microsoft was rewriting Windows in a popular new memory-safe language called Rust. While Microsoft denied that rumor, the storage engine of HorizonDB is written entirely in Rust, along with some Postgres extensions that Microsoft has authored, as well as the DiskANN vector search indexing. In the Ignite presentation, Adam Prout explained how, in a multi-million-line code base with 100s of developers, it's nearly impossible to eliminate buffer overflows in C and C++. Every buffer overflow represents a potential security vulnerability, so writing in a memory-safe language like Rust effectively eliminates that risk while also reducing the risk of race conditions.

Building a database engine on top of cloud storage lets you do a lot of cool things to improve performance. One of the challenges of the cloud is that all storage is network-attached, which adds latency to any process. For example, if you are writing to a database configured for high availability. In a traditional configuration, a write has the following steps:

1. The write comes from the application and reaches the primary copy of the database, where it is hardened to the transaction log.
2. In PostgreSQL, the write-ahead log sends the write to the second copy of the database, where the data is then written to the secondary copy's transaction log.
3. An acknowledgment of the secondary write is sent back to the primary, which can now acknowledge the write being "safe" and complete the transaction.

Here, we are making a total of 4 network round-trips, which can significantly increase write latency.

One advantage that cloud providers have built into their physical architecture is zone-redundant storage. While in an on-premises environment, you could spread three storage arrays across data centers to achieve the same level of data protection. A) It would be expensive, and B) most organizations don't have three data centers of their own (I know you are out there, big enterprise).

Having zone-redundant storage means a write is acknowledged when it reaches a quorum of storage nodes (which implies two of three blobs in the diagram Microsoft showed at Ignite). In HorizonDB, because the secondary replica shares the same zone-redundant blob storage, all that back-and-forth between nodes can be avoided. As soon as the write from the primary is acknowledged, the secondary can read it and apply the log record. This architecture should allow HorizonDB to have both lower write latency and faster failovers. HorizonDB uses a technique I've discussed here before called sharding -- this has two effects: by spreading the data out, read I/O becomes more efficient, and having smaller "partitions" allows for faster point-in-time recovery.

I've mainly focused on the architectural aspects of HorizonDB, but the service also carries forward many of the innovations Microsoft has brought to all its database solutions, including integration with Microsoft Foundry for in-database semantic vector searching and DiskANN indexes to further optimize that vector search process. There is also some new AI model management technology to further assist with those efforts.

Microsoft has been offering open-source databases such as PostgreSQL and MySQL on Azure for almost a decade. However, they have historically trailed more advanced cloud-native offerings like Amazon Aurora. I'm impressed that I see many of the excellent design patterns from Azure SQL Database Hyperscale in HorizonDB, and I'm even more impressed that the service is built with a modern language like Rust. This service is still only available in private preview, but if you are interested and have a big PostgreSQL workload, you can reach out to Microsoft here.