The typical retrieval-augmented app in production right now is three systems in a trench coat. Postgres holds the relational truth. A separate vector database holds the embeddings. An inference service turns text into vectors and back again. Every request fans out across all three, and each has its own consistency story, its own failure mode, and its own bill. The seams are where the bugs live: a row updated in Postgres but not re-embedded, a filter applied in the app after the vector search already threw away the rows you wanted, a "similar products" list that quietly includes items you deleted an hour ago.
Azure HorizonDB, which Microsoft moved to public preview at Build 2026, is a bet that those three systems should be one. Not a new vector store bolted onto a database — a Postgres-compatible engine where vector search and model inference run inside the transaction boundary, next to the relational data they describe. That framing is worth taking seriously, and it's more interesting than the benchmark numbers Microsoft leads with.
The engine under the compatibility layer
HorizonDB keeps full PostgreSQL compatibility on the surface and rebuilds the storage engine underneath. The architecture Microsoft calls "database-as-logs" separates compute from storage completely: instead of a primary writing pages to its own attached disk and shipping WAL to replicas, transactions commit directly to a shared write-ahead log in storage, in a single step. Storage is shared by every compute node.
That decoupling is what the scale numbers hang off of:
- Up to 3,072 vCores across primary and replica nodes
- Auto-scaling shared storage up to 128 TB per database
- Up to 15 read replicas for read-heavy fan-out
- Sub-millisecond commit latency across availability zones
The multi-zone sub-millisecond commit is the line that matters. Because the log is the shared source of truth, a replica in another zone isn't chasing a primary's disk — it reads the same committed log. You scale reads out to fifteen nodes without the usual replication-lag anxiety, and a compute node can fail without taking storage with it. It's the compute/storage split Aurora and AlloyDB popularized, with HorizonDB leaning harder on committing straight to log storage rather than to a page-oriented volume.
Where the AI actually lives
The part that makes HorizonDB more than a faster Postgres is that inference is a first-class database operation, exposed through the azure_ai extension. It has three pieces worth naming:
- AI Model Management connects the database to generative, embedding, and reranking models in Microsoft Foundry, so a model is a registered object you reference rather than an HTTP endpoint you call from app code.
- AI Functions let you invoke those models from SQL — generate an embedding, classify a row, summarize a column — inside a query or a transaction.
- AI Pipelines give you durable, event-driven orchestration: when data changes, re-embed it, re-rank it, run the model, without an external worker to babysit.
Put concretely, "re-embed this row when its description changes" stops being a background job in your application and becomes a property of the table. The embedding and the row it describes commit together. That closes the exact gap — stale or missing embeddings — that makes the three-system RAG stack fragile.
DiskANN, and the filtering problem nobody talks about
Vector search is where HorizonDB's design pays off most visibly, and the reason is filtering rather than raw speed. Real retrieval queries are almost never "find the nearest vectors." They're "find the nearest vectors for this tenant, in this category, under this price, from the last 30 days." An HNSW or IVFFlat index handles that badly: it returns the top-K nearest candidates and then applies your WHERE clause, so a selective filter throws most candidates away and recall collapses. The usual workaround is over-fetching and re-ranking in the app — more seams.
HorizonDB's DiskANN index (via pg_diskann) pushes the predicate into the graph walk. The index keeps traversing until your LIMIT is satisfied with rows that already pass the filter. There's no special syntax — you write ordinary SQL and the planner does it:
CREATE INDEX products_embedding_diskann_idx
ON products USING diskann (embedding vector_cosine_ops);
-- Vector similarity AND metadata filters, one query, one index walk
SELECT id, category, price
FROM products
WHERE tenant_id = 42
AND category = 'kitchen'
AND price BETWEEN 20 AND 200
AND created_at > now() - INTERVAL '30 days'
ORDER BY embedding <=> :query_embedding
LIMIT 10;
Recall and latency stay stable as the filter gets more selective — the property HNSW loses. Microsoft cites up to 3x faster vector search than traditional pgvector indexes, but the durable win is that the filtering happens where the data is, with transactional consistency and no application-side post-filtering.
DiskANN also breaks the dimensionality ceiling. HNSW in pgvector caps out at 2,000 dimensions; DiskANN with spherical quantization indexes up to 16,000 (at sq_bits = 1) or 4,000 (at sq_bits = 4), which is what lets you index a text-embedding-3-large vector directly instead of truncating it.
CREATE INDEX demo_embedding_diskann_idx ON demo USING diskann (embedding vector_cosine_ops)
WITH (spherical_quantized = true, sq_bits = 4, sq_training_samples = 25000);
What adopting it actually costs
The honest caveats are architectural, not performance. HorizonDB is in public preview as of June 2026, in a handful of regions — not where production commitments belong yet. And the AI features that make it compelling are the same ones that bind you: azure_ai, AI Model Management, and AI Pipelines are coupled to Microsoft Foundry. The SQL you write against them does not move to a self-hosted Postgres or to another cloud's managed Postgres. You're trading the portability that made "just use Postgres" a safe default for a tighter, more capable stack.
On the ledger's good side, the surface stays familiar: standard PostgreSQL SQL, roughly 75 popular extensions (pg_stat_statements, auto_explain, pg_duckdb, pg_diskann, pgvector, pg_textsearch), Microsoft Entra ID for identity, private endpoints, and encryption at rest and in transit. Your ORM, your migrations, and your operational muscle memory carry over.
The pitch isn't "a faster database." It's "one consistency domain for your relational data, your embeddings, and your inference."
If you're running the three-system RAG stack today, the concrete thing to evaluate is not throughput — it's whether collapsing embeddings, filtering, and inference into one transactional engine removes a class of bug you currently paper over with reconciliation jobs and over-fetching. Spin up a preview instance, port one filtered vector query off your bolted-on vector store, and measure recall under a selective WHERE clause. That single query tells you more about whether HorizonDB fits than any vCore count will.
Sources: Azure HorizonDB: Enterprise-Ready Postgres, Engineered for the AI Era (Microsoft Community Hub) · Scalable Vector Indexing with DiskANN in Azure HorizonDB (Microsoft Learn) · Announcing Azure HorizonDB (Microsoft Community Hub)