By ByteBot
Azure HorizonDB, Microsoft’s PostgreSQL-compatible database rebuilt for agentic AI workloads, entered public preview at Build 2026 on June 2. Developers can now sign up and start building. The bigger question: is it ready for your workload, or should you stay on Aurora, AlloyDB, or Azure’s own Flexible Server until general availability?
What’s Actually Available Now
The December 2025 announcement was promising but abstract. The Build 2026 public preview is concrete: five regions at launch (Australia East, Central US, Sweden Central, West US 2, West US 3), with East US, Canada Central, Japan East, Korea Central, Poland Central, and others arriving in the coming weeks. You can provision HorizonDB through the Azure portal, the REST API, or the VS Code PostgreSQL extension.
Pricing follows a pay-as-you-go model with compute billed per vCore, plus storage in GiB/month. Microsoft has not published specific numbers yet — you cannot properly evaluate a database service without knowing what it costs to run at your scale, so factor that into your planning timeline.
DiskANN: The Feature Worth Paying Attention To
Vector search is table stakes for AI apps in 2026. Every managed PostgreSQL service runs pgvector. What HorizonDB does differently with DiskANN Advanced Filtering is worth understanding.
Standard pgvector HNSW search runs in two passes: retrieve the nearest vector candidates, then apply your WHERE clause to filter down to results. The problem is that most real-world agent queries are filtered — “find the 10 most relevant memories about pricing created in the last seven days by this specific user.” Post-filtering means doing work you then throw away.
DiskANN’s advanced filtering collapses this into one pass. During graph traversal, each vector is checked against the predicate simultaneously — not after. Microsoft’s benchmarks show up to a 3x reduction in query latency depending on filter selectivity. Independent benchmarks don’t exist yet (it’s a public preview), but the architectural reason the approach should be faster is sound. This is not just a marketing claim; it is how the algorithm works.
In-Database AI Model Management
HorizonDB integrates directly with Microsoft Foundry, letting you call embedding, generative, and reranking models from within SQL. The models are managed by the database itself — no API keys in your application code, no external HTTP calls during query execution. Model usage is billed through Foundry at its standard rates.
For teams building RAG pipelines or agent memory systems, this removes an entire infrastructure layer: the API proxy, the embedding service, the model routing logic. Whether you would trust a preview database for that role in production is a separate question worth thinking through.
The VS Code PostgreSQL Extension Is Now GA
Often overlooked in HorizonDB coverage: the VS Code PostgreSQL extension reached 500,000 installs and went generally available at Build 2026. The extension integrates GitHub Copilot with full schema context, enabling schema-aware completions and one-click performance debugging where Copilot Agent mode launches directly from the monitoring dashboard.
The more interesting preview feature is Oracle migration tooling. The extension uses AI-powered schema conversion to migrate Oracle database schemas to PostgreSQL, flagging complex constructs as “Review Tasks” for Copilot to resolve. Oracle-to-PostgreSQL migrations are painful and expensive — automated tooling that understands the schema rather than regex-replacing syntax is worth watching, especially as Oracle’s CPU-based licensing costs have pushed more enterprises toward the exit.
The Honest Limitations
HorizonDB is not serverless. Compute must be manually configured; you add and remove replicas yourself based on throughput needs. Storage auto-scales, compute does not. For teams accustomed to Aurora Serverless v2 scaling down to zero, this is a meaningful operational difference.
Five regions at launch, no published pricing, no SLA for preview workloads, and no independent performance benchmarks. Microsoft’s own 3x DiskANN latency reduction and 3x transaction throughput claims are architecturally plausible but unverified externally.
Aurora remains the safe production choice if you need proven reliability, global region coverage, and serverless scaling. HorizonDB is the right preview choice if you are building AI-heavy applications on Azure and are willing to evaluate preview technology — and if you can absorb the operational overhead of manual compute scaling.
How to Get Started
- Azure portal — provision a HorizonDB cluster, configure compute tier and region
- VS Code — install the PostgreSQL extension, connect to HorizonDB from your IDE
- REST API — automate provisioning through Azure Resource Manager APIs
Your existing PostgreSQL drivers, ORMs, and queries work without modification. The PostgreSQL wire protocol compatibility is the point: HorizonDB is designed to be a drop-in for workloads that need what standard managed PostgreSQL cannot deliver at AI scale.
If you are running agentic workloads that combine vector retrieval with transactional data, and you are already on Azure, the preview is worth evaluating now. If you need GA-level stability and published pricing before committing, check back in several months. The public preview is real, but it is still a preview.
