Azure HorizonDB Explained: Architecture, Public Preview Limits, and What It Means for SQL Server DBAs

Microsoft announced the public preview of Azure HorizonDB at Build 2026, positioning it as a new class of PostgreSQL-compatible database service built specifically for mission-critical, AI-heavy workloads. It is not a configuration option inside Azure Database for PostgreSQL Flexible Server and it is not a rebrand of an existing service. It is a separate product with its own storage architecture, its own compute model, and its own set of preview-stage gaps that matter before anyone recommends it for production.

This article covers what Azure HorizonDB actually is under the hood, how its architecture compares to both Azure Database for PostgreSQL Flexible Server and Azure SQL Database Hyperscale, what is genuinely not available yet, and what a SQL Server DBA evaluating it today needs to check before treating any of the marketing language as a production guarantee.

1What Azure HorizonDB Is

Azure HorizonDB was first announced at Ignite 2025 as a private preview. Build 2026 moved it to public preview, meaning it can now be provisioned directly without an application process, though it remains a preview service with the caveats that status implies. Microsoft’s own documentation describes it as a cloud native, fully managed, AI-ready database service built on PostgreSQL, combining a disaggregated compute and storage architecture with a database-as-a-log design.

The core distinction to hold onto: Azure Database for PostgreSQL Flexible Server is a managed instance of PostgreSQL running on attached storage, conceptually similar to how most SQL Server VMs work. Azure HorizonDB is architected from the storage layer up around separation of compute from durability, closer in spirit to how Azure SQL Database Hyperscale departs from traditional SQL Server storage. Both HorizonDB and Flexible Server remain live, separately supported Azure services with different target workloads. Microsoft is not deprecating Flexible Server in favor of HorizonDB.

2Architecture Part One: Disaggregated Compute and Storage

In HorizonDB, compute is stateless. Compute resources, meaning vCores and memory, scale independently of storage, and storage scales independently of compute. Read scale-out happens by adding replicas to the cluster rather than by resizing anything.

Storage runs as two purpose-built fleets rather than one: a fleet dedicated to the write-ahead log and a separate fleet for data, both backed by Azure Blob Storage and zone resilient by default. Storage capacity is allocated dynamically as the database grows; there is no storage size or IOPS to provision up front, which is the same operational pattern Azure SQL Database Hyperscale uses for its data files.

This separation produces three concrete operational effects documented by Microsoft. Compute and storage scale on independent schedules. Read replicas provision quickly because they attach to existing shared storage instead of copying data. Failover is faster because the WAL is already durable in shared storage, removing the log-rewind step that a traditional replica has to perform before it can accept writes.

3Architecture Part Two: The Database-as-a-Log Design

This is the part of the architecture most likely to be new territory for a SQL Server DBA, and it is worth slowing down for. In HorizonDB, compute replicas write only the write-ahead log to the storage layer. Data pages are never written from compute to storage. The WAL is the single authoritative source of truth for the entire system; storage nodes reconstruct page state by replaying it.

Mechanically: every insert, update, or delete is appended to a durable WAL service before the transaction is acknowledged to the client. That WAL service is purpose-built for transaction log semantics and tuned for low latency. Filtered WAL is routed only to the storage nodes responsible for the data it affects. Storage nodes then apply that WAL to reconstruct pages, which eliminates the checkpoint I/O bottleneck that exists in a conventional PostgreSQL deployment.

The practical payoff Microsoft documents is a list of PostgreSQL background processes that simply do not run the same way on HorizonDB compute replicas, because their work has moved to the storage layer:

Each compute replica, primary or standby, also gets a local NVMe SSD cache that holds hot pages, reducing round trips to the remote storage fleet. Provisioned memory is fixed at 8GB per core.

4The Cluster Model: Primary, Replicas, and Endpoints

A provisioned HorizonDB resource is called a cluster. A cluster has one writable primary replica and any number of readable standby replicas, all sharing a single copy of the underlying zone-resilient storage. At least two replicas are required for zonal resilience. Compute scales up to 192 vCores per node, on both the primary and each replica, and Microsoft documents support for up to 15 read replicas per cluster with connections load-balanced automatically across a dedicated read-only endpoint. A separate read-write endpoint always routes to whichever replica currently holds the primary role.

Because replicas attach to shared storage rather than maintaining their own copy, adding or removing a replica is a compute operation, not a data-copy operation. That is a meaningfully different mental model from adding an Always On secondary or a PostgreSQL streaming replica in a conventional deployment.

5AI and Vector Search Capabilities

HorizonDB ships with native support for vector embeddings rather than treating vector search as a bolt-on. pgvector is available for similarity search using HNSW or IVFFlat indexes. pg_diskann brings Microsoft Research’s DiskANN algorithm, which is the recommended default for large, high-dimensional, filtered vector workloads and supports up to 16,000 dimensions.

The specific detail worth knowing: DiskANN is currently the only vector index in HorizonDB that supports what Microsoft calls advanced filtering, meaning a metadata predicate in the WHERE clause is evaluated inside the index walk itself rather than filtering candidates after the fact. With HNSW or IVFFlat, a selective predicate causes most of the top-K candidates to be discarded post-search, which drops recall and typically forces an application to over-fetch and rerank. DiskANN’s advanced filtering keeps fetching matching candidates until the requested limit is satisfied, so recall and latency stay stable even as filters get more selective. For anyone building retrieval-augmented generation or multitenant search where results must be filtered by tenant or category alongside a vector match, that distinction determines which index is the right default, not just the faster one.

The pg_textsearch extension adds BM25-ranked full-text search as a native index access method, meant to sit alongside pgvector and DiskANN for hybrid retrieval rather than replace PostgreSQL’s built-in tsvector/tsquery search. The azure_ai extension provides AI functions and model management for calling Azure AI Foundry models directly from SQL.

6Fabric and Foundry Integration

Two integration points are genuinely native to HorizonDB rather than bolted on after the fact. Mirroring to Microsoft Fabric OneLake is built into the service, replicating operational data into Delta tables for analytics without a separately configured ETL pipeline. Integration with Microsoft Foundry is described as one-click, intended to shorten the path from Postgres tables to embedding generation, reranking, and agent workflows.

Note the distinction from Flexible Server’s Fabric mirroring, which is already generally available and built on logical replication plus change data capture, shipping snapshots to OneLake in Parquet format and applying subsequent changes in batches. HorizonDB’s mirroring runs on the same disaggregated storage architecture described above rather than layering CDC on top of a conventional instance. The end result looks similar from the Fabric side; the underlying mechanism is not identical.

7HorizonDB Compared: Flexible Server and Azure SQL Hyperscale

For a DBA fluent in Azure SQL Database Hyperscale, HorizonDB’s compute/storage split will look familiar in principle. The comparison below is useful for scoping which Microsoft service applies to which conversation.

The practical read: Flexible Server remains the default recommendation for a straightforward PostgreSQL migration today. HorizonDB is the one to evaluate specifically when the workload profile looks like what Hyperscale was built for on the SQL Server side, large-scale OLTP with unpredictable read growth, plus a genuine need for vector search inside the transactional database rather than in a bolted-on service.

8What Is Not Available Yet: Public Preview Limitations

This is the section most likely to change a recommendation, and it is documented directly by Microsoft rather than inferred. As of this writing, the following are explicitly listed as not yet available in HorizonDB:

None of these are disqualifying for evaluation and testing. Several of them, particularly customer-managed keys and cross-region replicas, are the kind of gap that rules out a production commitment for regulated workloads until Microsoft closes them. Anyone building a proposal around HorizonDB right now should treat this table as a live checklist against their own compliance requirements rather than an afterthought.

9Migration Path Today

As of this writing, Microsoft’s documented migration path into HorizonDB is dump and restore. There is not yet a dedicated online migration tool comparable to what exists for moving into Flexible Server. For a small to medium database this is a manageable maintenance-window migration. For a large, continuously written OLTP database, the lack of a logical-replication-based online migration path today means real downtime needs to be planned for, not assumed away.

10Regions and Pricing

Azure HorizonDB is currently available in eight regions: 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 in Asia Pacific. Microsoft states region availability will expand during preview and that some regions may carry deployment restrictions, so this list should be reverified against the Azure portal before any deployment plan is finalized.

Pricing is pay-as-you-go, billed per vCore for both the primary and any high availability replicas, plus separate billing for data and log storage in GiB per month. Backup storage is not charged up to 100% of the cluster’s total initial size; consumption beyond that is billed separately. There is no published reserved-capacity or committed-spend discount structure for HorizonDB as of this writing, which is typical for a public preview service and worth flagging to anyone building a cost model today rather than after general availability pricing lands.

11Should SQL Server DBAs Care Now

The recommendation: evaluate HorizonDB now if PostgreSQL support already exists in the environment and a specific workload matches its profile, large-scale OLTP with elastic read demand and a real vector search requirement inside the transactional path. Do not commit a production, compliance-bound workload to it yet. The missing customer-managed keys, the fixed seven-day backup retention, and the absence of cross-region replicas are not cosmetic gaps; they are the kind of thing that blocks a production sign-off in most regulated environments until Microsoft ships them.

For a SQL Server DBA specifically, the more useful exercise than memorizing HorizonDB’s feature list is recognizing the pattern: Microsoft is now running the same disaggregated compute-and-storage architecture across both of its major database lines, Hyperscale on the SQL Server side and HorizonDB on the PostgreSQL side. Understanding one genuinely does transfer to understanding the other, and that architectural fluency is likely to be worth more over the next few years than deep familiarity with either product’s preview-stage feature checklist.

References

• Microsoft Docs: What Is Azure HorizonDB? (Azure HorizonDB overview, Microsoft Learn)
• Microsoft Docs: Azure HorizonDB Pricing (Azure.com)
• Microsoft Docs: Scalable Vector Indexing with DiskANN in Azure HorizonDB (Microsoft Learn)
• Microsoft Docs: Full-Text Search with pg_textsearch in Azure HorizonDB (Microsoft Learn)
• Microsoft Docs: PostgreSQL Extension for Visual Studio Code with Azure HorizonDB (Microsoft Learn)
• Microsoft Docs: Azure Database for PostgreSQL Flexible Server Mirroring in Microsoft Fabric (Microsoft Learn)
• Microsoft Docs: What’s New with Postgres at Microsoft, 2026 Edition (Microsoft Community Hub)
• Microsoft Docs: Building Agentic Apps with Microsoft Fabric and Microsoft Databases, Build 2026 recap (Azure Blog)
• SQLYARD: Develop and Scale Without Limits: Azure SQL Database Hyperscale Explained
• SQLYARD: Azure Database for PostgreSQL Flexible Server: What Every Data Professional Needs to Know
• SQLYARD: 12 Things SQL Server DBAs Need to Know Before Supporting PostgreSQL
• SQLYARD: Microsoft PostgreSQL Hub for Azure Developers: What It Is and Why It Matters
• SQLYARD: MigrateIQ

All technical content on SQLYARD is verified against Microsoft documentation at the time of publication. SQL Server features, cloud service capabilities, licensing terms, and configuration requirements can change between versions and cumulative updates. Always validate against current Microsoft Learn documentation before deploying to production. Azure HorizonDB specifically remains in public preview at the time of this writing; feature availability, region coverage, and pricing are subject to change before general availability.