Azure HorizonDB at Ignite 2025: What It Is, Why It Matters, and How to Think About It

Microsoft used Ignite 2025 to put a new flag in the ground for Postgres at cloud scale. Azure HorizonDB—branded as “HorizonDB”—promises the elasticity of a cloud-native architecture, the familiarity of PostgreSQL, and integrated AI features that shorten the path from schema to shipped app. Here’s what was announced, why it matters, and how to evaluate it for your stack.

What Microsoft actually announced

At Ignite 2025, Microsoft unveiled Azure HorizonDB as a PostgreSQL‑compatible, cloud‑native database service. It separates compute and storage, adds elastic scale‑out, and integrates native AI capabilities. Microsoft’s Azure blog highlights preview status, the “up to three times faster than open‑source PostgreSQL” claim, and up to 15 read replicas atop auto‑scaling shared storage. The current limits detail 192 vCores per replica and auto‑scaling storage up to 128 TB, along with advanced vector indexing and pre‑provisioned models.

Microsoft’s engineering blog goes deeper: HorizonDB’s tiered cache, shared storage, and elastic compute together enable high‑throughput OLTP with sub‑millisecond multi‑zone commit latencies. Across the primary plus replicas, clusters can reach 3,072 vCores—consistent with 16 nodes (1 primary + 15 replicas) at 192 vCores each. Security features include Entra ID, Private Endpoints, zone‑redundant replication, automated backups, and integration with Defender for Cloud. Preview regions at launch include Central US, West US3, UK South, and Australia East.

Why HorizonDB exists (and where it lives in the Azure portfolio)

If you already use Azure Database for PostgreSQL (ADP), think of HorizonDB as the cloud‑native, scale‑out sibling aimed at heavier throughput, lower latency, and AI‑forward scenarios. Microsoft’s product page spells out the difference: HorizonDB = cloud‑native architecture for high‑throughput, data‑intensive apps; ADP = managed, traditional Postgres deployments.

Strategically, HorizonDB also positions Microsoft against Google AlloyDB, AWS’s distributed Aurora offerings, and third‑party distributed Postgres stacks (e.g., CockroachDB, YugabyteDB). The Register frames HorizonDB as Microsoft’s answer to the distributed Postgres race—where compatibility, scale, and availability are the new table stakes.

What’s actually new for builders and data teams

• Vector search that respects your filters. HorizonDB introduces DiskANN Advanced Filtering, fusing predicate filtering with vector traversal—aimed at avoiding the slow “retrieve then filter” pattern common with HNSW. Microsoft’s initial benchmarks attribute significant latency reductions to this approach (depending on filter selectivity).
• Built‑in AI model management. HorizonDB can auto‑provision Foundry models (embeddings, rerankers, generation) and wire up the azure_ai extension and semantic operators within Postgres—reducing the glue work typically required to stand up RAG and agentic patterns.
• Deep tooling in VS Code. The PostgreSQL extension for VS Code is now GA, with “Metrics Intelligence” that uses Copilot and live telemetry to help diagnose and remediate performance issues. Graph data via Apache AGE is supported with in‑editor visualization.
• Elastic scale with preview limits. HorizonDB is private preview only; access is application‑based, with limited regional availability today.

---

How it fits with Fabric and Foundry (and the rest of your estate)

HorizonDB joins a broader set of Ignite data announcements that emphasize AI‑ready databases and Fabric as the connective tissue. Microsoft’s blog positions HorizonDB alongside SQL Server 2025, Azure DocumentDB(MongoDB‑compatible), and Fabric’s database experiences—framed as a portfolio where transactional, NoSQL, and analytics coexist with native AI hooks. For HorizonDB specifically, the Foundry integration creates a cleaner path from Postgres tables to RAG/agent workflows, and Fabric provides the governance and sharing patterns around it.

When you might reach for HorizonDB

For teams with analytics and AI roadmaps, the decision often hinges on two questions: latency under load and AI proximity to data.

• You need OLTP at scale with near‑instant commits across zones and massive read fan‑out (e.g., multi‑region, multi‑tenant SaaS).
• You want vector search + filters inside Postgres, not as a sidecar. DiskANN’s design aims to keep both accuracyand throughput without bolting on a separate vector store.
• You value managed AI plumbing—pre‑provisioned models, semantics operators, and Foundry connectors—to speed up RAG, retrieval, and agent scenarios with fewer moving parts.
• You’re already in Azure and want a Postgres‑first path that’s distinct from ADP (traditional managed Postgres) and Cosmos/DocumentDB (NoSQL).

Pragmatic guidance for early evaluation

Start small, but measure what matters:

• Target a realistic workload. Use a write‑heavy, read‑scaled service path (or a RAG microservice) where vector search and filtering are critical. Compare end‑to‑end p95/99 latency and tail behavior—before and after DiskANN Advanced Filtering.
• Exercise the AI loop. Validate that model provisioning, semantic operator calls, and cost attribution via Foundry work the way your governance expects.
• Pressure the scale‑out path. Test replica fan‑out and failover behavior, and observe how auto‑scaling storage interacts with throughput at peak. Use the VS Code extension’s Metrics Intelligence to shorten iteration cycles.
• Mind preview constraints. Expect evolving limits, region constraints, and API polish typical of a private preview. Apply for access and sanity‑check region fit: Central US, West US3, UK South, Australia East at announcement time.