Azure HorizonDB vs PostgreSQL pgvector vs AI Search for RAG

Last week at Build 2026, Microsoft moved Azure HorizonDB into public preview: a fully managed, PostgreSQL-compatible database service that scales to 128 TB of storage and 3,072 vCores, with vector search and AI model management built directly into the engine, and direct connectivity to Microsoft Foundry and Fabric. For teams building retrieval-augmented generation (RAG) systems on Azure, this is not just another database SKU. What used to be a two-way decision between Azure Database for PostgreSQL with pgvector and Azure AI Search is now a three-way one. Sweden Central is also one of only five regions in the initial preview rollout, which means Swedish and Nordic teams can evaluate it with data residency intact from day one.

What Microsoft actually shipped

Azure HorizonDB was first announced at Ignite 2025, and Build 2026 is where it became something you can actually deploy. The headline facts from Microsoft's announcement and the coverage around it:

• PostgreSQL-compatible, fully managed. Microsoft positions it as combining PostgreSQL familiarity with a cloud-scale architecture. Your drivers, ORMs and SQL should largely carry over.
• Scale-out architecture. Up to 128 TB of elastic storage and up to 3,072 vCores, with compute and storage scaling independently, a fundamentally different design from the vertical-scaling model of Azure Database for PostgreSQL Flexible Server.
• Zone-resilient by default, with multi-zone replication and what Microsoft describes as sub-millisecond multi-zone commit latency.
• Vector search and embeddings in the engine. The stated goal is to remove the need for a separate vector database alongside your transactional store, for exactly the RAG and agent-memory workloads most of us are building.
• Integrated AI model management and direct connectivity to Microsoft Foundry and Microsoft Fabric, so the database plugs into the same platform your agents and analytics already live on.
• Enterprise plumbing from the start: Entra ID authentication, encryption at rest and in transit, private network endpoints.
• Preview regions: Central US, West US 2, West US 3, Sweden Central and Australia East.

The same Build wave brought related announcements. Azure Database for PostgreSQL gained Microsoft Defender for Cloud integration in preview plus new discovery and assessment tooling for Oracle-to-PostgreSQL migrations. Microsoft also introduced Web IQ, a web-grounding capability that sits alongside Work IQ, Fabric IQ and Foundry IQ, and is reported to be available both standalone and integrated into Azure AI Search and the Copilot stack. Web IQ changes the calculus on the AI Search side of this comparison.

The three contenders for your embeddings

Option 1: Azure Database for PostgreSQL + pgvector

This has been our default recommendation for most mid-sized RAG workloads for a while, and nothing at Build changed that for the majority of teams. Flexible Server with the pgvector extension gives you vectors, metadata, full-text search and your transactional data in one place, queried with plain SQL. You get HNSW and IVFFlat indexing through pgvector, and Azure's DiskANN-based indexing work has been extending what a single Postgres instance can handle. The operational model is familiar and the cost model is predictable (vCores plus storage). There is no synchronisation pipeline to build or monitor, because the source data and the embeddings live in the same ACID-compliant store.

The ceiling is real, though. Flexible Server scales vertically. When your corpus grows into hundreds of millions of vectors, or your write throughput and query concurrency climb together, you end up sharding manually or accepting bigger and bigger instances. That ceiling is precisely the gap HorizonDB is aimed at.

Option 2: Azure HorizonDB

HorizonDB is best understood as the answer to the question: what if the pgvector approach did not have a ceiling? Same PostgreSQL surface, but on a scale-out engine with independent compute and storage scaling, zone resilience by default, and vector search treated as a first-class engine capability rather than an extension you bolt on. The integrated AI model management and the direct Foundry connection also hint at where Microsoft wants this to go: embedding generation and retrieval orchestrated closer to the data, with fewer custom pipelines shuttling text and vectors between services.

The caveats are the standard preview caveats, and they matter more for databases than for almost any other service category. There is no GA date announced, preview services carry no SLA, and pricing at general availability is not yet published. Evaluate it now, but be very careful about putting a system of record on it before GA.

Option 3: Azure AI Search

Azure AI Search remains the retrieval-quality champion. It is a search engine that happens to also store vectors rather than a database, and that distinction cuts both ways. In its favour: hybrid retrieval (BM25 keyword plus vector plus semantic ranking) is built in and genuinely improves answer quality for most enterprise RAG corpora. Integrated vectorisation handles chunking and embedding for you. The new Web IQ integration means grounding on both your private corpus and fresh web context can happen in one retrieval layer. If your bottleneck is retrieval relevance rather than data volume, AI Search earns its keep.

Against it: your documents live somewhere else, so you own an indexing pipeline, its failure modes, its freshness lag and its consistency gaps. You pay for search units on top of whatever database you already run. And every schema change to your source data ripples through an indexer configuration that no one on the team loves maintaining.

A decision framework that survives contact with reality

Walk through these questions in order; the first strong answer usually decides it:

• 1. Is the embedded content born in your database? If the text you are embedding is rows you already own (product data, tickets, CRM notes), keeping vectors next to source data in Postgres eliminates an entire synchronisation problem. Score one for pgvector or HorizonDB.
• 2. Is it a document soup? PDFs, SharePoint, wikis and mixed formats are exactly what AI Search's indexers and skillsets, with integrated vectorisation, were built for. Rebuilding that pipeline yourself on Postgres is rarely a good use of engineering time.
• 3. Does retrieval quality make or break the product? Hybrid search with semantic reranking typically beats pure vector similarity on messy enterprise corpora. If your evaluation harness shows a meaningful gap, AI Search justifies its cost. If you do not have an evaluation harness, build one before choosing anything.
• 4. What is your actual scale trajectory? Count vectors, not ambitions. Tens of millions of vectors with moderate query rates sit comfortably in Flexible Server. If your roadmap genuinely points at hundreds of millions of vectors or a multi-terabyte corpus with high concurrency, that is HorizonDB territory. The preview exists precisely so you can validate that claim yourself.
• 5. Can you tolerate preview status? New greenfield workload with a GA fallback plan: yes. Regulated system of record: not yet.
• 6. What does your team already operate? A team fluent in Postgres will run pgvector well and AI Search poorly, and vice versa. Operational familiarity is a feature.

One pattern we keep recommending: these options are not mutually exclusive. A common architecture keeps transactional data and per-user agent memory in Postgres with pgvector, and puts the large shared document corpus behind AI Search. HorizonDB's pitch is that it can eventually collapse that split for the Postgres side at any scale. Test that claim; do not bet on it before GA.

Migration is cheap in one direction only

Because HorizonDB is PostgreSQL-compatible, the pgvector-to-HorizonDB path should be the cheap one. If you standardise on plain SQL and pgvector semantics today, you preserve optionality. This is the sort of query that should carry across:

-- Hybrid-ish retrieval in plain Postgres: vector similarity
-- filtered by tenant and recency, joined to source rows.
SELECT d.id, d.title, d.updated_at,
       1 - (e.embedding <=> $1) AS similarity
FROM   doc_embeddings e
JOIN   documents d ON d.id = e.doc_id
WHERE  d.tenant_id = $2
  AND  d.updated_at > now() - interval '2 years'
ORDER  BY e.embedding <=> $1
LIMIT  20;

The reverse directions are more expensive. Moving off Azure AI Search means rebuilding indexing pipelines and re-tuning retrieval; moving from any Postgres flavour into AI Search means building those pipelines in the first place. That asymmetry is an argument for defaulting to the Postgres side when the decision is genuinely close, and it is also why HorizonDB entering this market matters even for teams who will never exceed Flexible Server's limits: it makes the Postgres path the one with the longest runway.

On cost shape rather than cost figures (preview pricing is not something to plan around): the Postgres options bill as compute plus storage you were largely paying for anyway, while AI Search is an additional service billed in search units on top of your database. Consolidation is usually the budget-friendly answer unless retrieval quality demands otherwise. The way to know is, again, an evaluation harness with your own documents and your own queries.

The Swedish and EU angle

Microsoft launching a preview with Sweden Central in the first five regions is unusual and welcome. Historically, Swedish teams evaluating new Azure data services have had to choose between waiting for regional availability or running proofs of concept in US regions, which gets awkward the moment real personal data enters the picture. Here, you can evaluate HorizonDB with production-adjacent data inside Swedish borders from the first week of preview.

A few practical points for teams operating under GDPR and Swedish procurement conditions:

• Data residency: Sweden Central availability means embeddings need not leave the country during evaluation, and embeddings can encode personal data just as surely as the source text does. Treat vector stores as in-scope for your records of processing; embeddings of personal data are personal data.
• Preview terms: preview services typically fall outside standard SLAs and may carry different terms. If your DPIA or your supplier assessment assumes GA-grade commitments, an evaluation is fine, but production personal-data processing on a preview service deserves a conscious, documented decision, not a drift.
• Security baseline: Entra ID authentication plus encryption in transit and at rest, with private endpoints from day one, means the preview can actually be wired into a locked-down landing zone rather than a firewall-exception science project. The parallel Defender for Cloud integration for Azure Database for PostgreSQL strengthens the incumbent option's compliance story too.
• Procurement framing: for public-sector and regulated buyers, the three-way choice has a useful property: all three options come from one vendor, under the same Microsoft data-protection terms, in the same regions. The decision is architectural, not contractual, which simplifies the paperwork considerably compared with adding a third-party vector database vendor.

What we would do this month

If you have a working RAG system on Flexible Server with pgvector: change nothing, but put a two-day HorizonDB evaluation in the backlog and measure your current vector count and query concurrency so you know your distance from the ceiling. If you are on Azure AI Search and happy with retrieval quality: also change nothing. Web IQ arriving inside AI Search suggests Microsoft will keep investing in that retrieval layer. If you are starting fresh in Sweden Central this quarter: build on Postgres + pgvector with clean SQL and a portable embedding pipeline, and treat HorizonDB as the scale-out path you will probably inherit for free at GA. The best position in June 2026 is the one that lets you defer the decision until Microsoft publishes GA pricing and SLAs. PostgreSQL compatibility is exactly what makes deferring cheap.

Sources

• heise online: Microsoft brings Azure HorizonDB with vector search to public preview
• Microsoft Azure Blog: Build 2026 — building agentic apps with Microsoft Fabric and Microsoft databases
• WindowsNews.ai: Azure HorizonDB and Web IQ — Microsoft's new AI infrastructure