Microsoft Fabric FabCon 2026 Recap — Data Agents, HorizonDB, and What It Means for Enterprise Data Platform

By Law Wen Feng, Principal Solution Architect · wenfeng.my

I spent the last week catching up on everything Microsoft announced at FabCon Atlanta 2026 and Microsoft Build 2026, and frankly, there is a lot to unpack. If you are an Azure-first enterprise team in Southeast Asia trying to figure out what to do next with your data platform, this post is for you.

Here is what stood out to me: Data Agents went GA, Azure HorizonDB hit public preview, Database Hub landed in Fabric, and GPU-accelerated Data Warehouse promises 7x faster queries. These are not just feature announcements — they signal a real shift in how Microsoft thinks about the enterprise data stack. Let me walk through each one and what it actually means for your team.

Data Agents: Your Virtual Analysts, Now Production-Ready

Data Agents hit general availability at FabCon 2026, and this is the announcement I am most excited about for practical reasons. Think of Data Agents as virtual analysts that sit on top of your governed Fabric data — they let users ask questions in natural language and get answers grounded in your actual enterprise data, not some generic model output.

What makes them different from the chatbots we have been tolerating for the past two years? A few things:

Grounded in governed data. Data Agents connect directly to your OneLake data, semantic models, and lakehouse tables. They respect your row-level and column-level security. When a user asks "What were our Southeast Asia Q1 revenue figures?", the agent queries your actual warehouse — it does not hallucinate numbers from training data.

Domain-aligned. You can create agents scoped to specific business domains. Your finance team gets a finance agent, your supply chain team gets a supply chain agent. Each one is configured with the right data sources, the right semantic models, and the right business context.

Cross-platform reach. Data Agents are not siloed inside Fabric. They can be used as knowledge sources in Microsoft Foundry, Copilot Studio, and Microsoft 365 Copilot. That means your finance team can access their finance agent directly from Teams without switching tools.

Operations Agents. Beyond interactive Q&A, there are Operations Agents that continuously monitor live data and act on predefined business logic. Detect anomalies, trigger alerts, initiate workflows — all grounded in real-time data signals from Fabric.

For enterprise teams, the production-readiness angle is key. This is not a research project. The improved NL2SQL engine is already in preview with better accuracy, transparency, and resilience when translating natural language to SQL. The agents handle query complexity behind the scenes — joins, aggregations, filters — while presenting results in natural language with supporting visualizations.

The prerequisites are worth knowing before you plan a pilot: a paid F2 or higher Fabric capacity (or Power BI Premium P1+ capacity with Fabric enabled), and at least one supported data source — a warehouse, lakehouse, Power BI semantic model, KQL database, or mirrored database — with read access. If your tenant runs Microsoft Purview policies, agents operate within them: DLP policies can restrict access to sensitive warehouse assets, and access restriction policies can block results from classified sources. That is governance working as intended.

If you are building a data culture where self-service analytics actually means something, Data Agents are the missing piece. The challenge has never been giving people access to data — it has been making that data accessible to people who do not speak SQL. This addresses that directly.

Azure HorizonDB: PostgreSQL Meets Cloud-Native Scale

This one is a bigger deal than most people realize. Azure HorizonDB is Microsoft's new fully managed, PostgreSQL-compatible database service, and it just entered public preview. Let me explain why this matters.

HorizonDB is built on a cloud-native architecture with disaggregated compute and storage. That means you can scale them independently — something that traditional managed PostgreSQL services cannot do well. The numbers are impressive:

  • Elastic storage scaling up to 128 TB — auto-scaling shared storage that grows with your data
  • Compute scale-out up to 3,072 vCores across primary and replica nodes
  • Database-as-log architecture — transactions commit directly to shared, zone-resilient write-ahead log (WAL) storage, eliminating traditional checkpoint I/O bottlenecks
  • Up to 3x faster performance compared with self-managed Postgres for transactional workloads

The architecture is worth understanding because it explains the performance story. Compute and storage are fully disaggregated: one writable primary replica plus readable standby replicas share a single copy of zone-resilient data. The WAL service is optimized purely for transaction log semantics, and filtered WAL is sent only to the storage nodes that own the affected data. Storage nodes reconstruct page state by applying the WAL, which reduces write amplification and delivers consistent write latency regardless of database size. You get the full PostgreSQL ecosystem — compatibility, tooling, community — with cloud-scale behavior baked in.

Provisioning is already covered by the Azure CLI, ARM templates, and the portal. Here is the CLI path from Microsoft's official quickstart — a zone-resilient cluster with two replicas:

az extension add --name horizondb

az horizondb create \
  --resource-group rg-prod-data \
  --name hz-orders-01 \
  --location <region> \
  --version 17 \
  --administrator-login pgadmin \
  --administrator-login-password <secure-password> \
  --v-cores 2 \
  --replica-count 2 \
  --zone-placement-policy Strict

Connection details follow the standard PostgreSQL wire protocol — any existing psql, driver, or ORM stack works:

psql "host=hz-orders-01.<id>.<region>.horizondb.azure.com port=5432 \
      dbname=postgres user=pgadmin sslmode=require"

Vector Search and AI Integration

Here is where HorizonDB gets really interesting for AI workloads. It ships with an advanced DiskANN vector index that introduces filtering capabilities — query predicate pushdowns directly into vector similarity search. This is a significant improvement over the pgvector HNSW approach that most managed Postgres services use today.

Why does filtered vector search matter? Because in production, you almost never do a raw "find me the most similar items" query. You want "find me the most similar items where status = active AND region = APAC AND created_date > 2025-01-01". HorizonDB pushes those filters down into the index traversal, which means dramatically better performance on real-world queries.

It also includes built-in AI model management. You can call generative, embedding, and reranking models directly from SQL, integrated with Microsoft Foundry. No separate vector database, no separate model hosting, no stitching together multiple services.

As Mohsin Shafqat from NASDAQ put it: "Instead of stitching together multiple components, it brings transactional data, vector search, and AI capabilities into a single platform."

Enterprise Security and Compliance

HorizonDB is enterprise-ready from day one:

  • Native Microsoft Entra ID integration
  • Private Endpoints support
  • Data encryption at rest and in transit
  • Automated backups with point-in-time recovery

For teams in regulated industries — financial services, healthcare, government — these are not nice-to-haves. They are prerequisites.

Database Hub: One Pane of Glass for Everything

The Database Hub announcement is about operational simplicity, and honestly, it is overdue. If you are running a mix of Azure SQL, Cosmos DB, PostgreSQL, MySQL, and SQL Server on-premises via Azure Arc, managing them is a headache. Each has its own portal, its own monitoring, its own governance model.

Database Hub in Fabric brings unified management for databases across edge, cloud, and Fabric into a single experience. It supports:

  • Azure SQL Database
  • Azure Cosmos DB
  • Azure Database for PostgreSQL
  • SQL Server via Azure Arc
  • Azure Database for MySQL
  • Fabric Databases

The key capabilities include agent-assisted management (Copilot-powered insights), built-in observability, and delegated governance. This is not just a dashboard — it is an intelligent management layer that can help you spot issues before they become incidents.

For Southeast Asia teams running hybrid infrastructure — databases on-premises in your Singapore or KL datacenter alongside cloud databases — the Azure Arc integration means you can manage that on-prem SQL Server from the same interface as your cloud databases. One governance model, one monitoring surface, one place to see everything.

GPU-Accelerated Data Warehouse: The 7x Performance Leap

This is the headline grabber, and for good reason. Microsoft announced GPU-accelerated Fabric Data Warehouse in early access preview at Build 2026, with early access starting in July 2026 across a limited set of regions — currently East US, East US 2, South Central US, Southeast Asia, and Germany West Central (sign-up required) — and no GA date committed yet.

The numbers from Microsoft's benchmarks are striking: up to 7x faster than three comparable cloud data warehouse providers across reporting, application, and AI scenarios. At 64-user concurrency, the performance stays stable — which is the real story here, not just the peak speed.

The underlying technology is called CoddSpeed, and it won the SIGMOD 2026 Best Industry Paper award. It uses NVIDIA accelerated computing, with a GPU-based execution engine derived from CoddSpeed's Tensor Query Processor (TQP) research. The optimizer intelligently offloads compute-intensive operations — large joins, aggregations — to GPUs while keeping other parts on CPUs.

What This Means in Practice

Per Microsoft's early access materials, UNC Health saw up to 5x improvement in query speeds, and WTW reported complex workloads running 3.4x faster at single concurrency. These are named enterprise customers — not synthetic benchmarks.

And here is the part that should make you pay attention: you do not need to rewrite a single query. Enable it from workspace settings and it applies automatically to all SQL Analytics Endpoints and Data Warehouses in the workspace. Same T-SQL surface, same tools, same architecture — just faster execution.

The scale of the gains matters more than any single benchmark run. Microsoft's own TPC-H testing at 100 GB on an F64 trial capacity found that the GPU-accelerated warehouse completes the full 22-query workload in about five seconds whether one user or 64 concurrent users are querying — while Microsoft's July 2026 benchmark blog reports roughly 6x throughput and 6–7x lower p95 latency versus the CPU path at high concurrency.

If you are running complex analytical workloads — financial reporting, supply chain optimization, customer analytics — this is a performance multiplier that directly impacts time-to-insight.

Practical Migration Guidance

Okay, so what should your team actually do with all of this? Here is my practical take for Azure-first enterprise teams in Southeast Asia:

If You Are Already on Fabric

  1. Turn on GPU acceleration. If your workspace has Data Warehouses, enable GPU acceleration from workspace settings. Run your existing queries and measure the difference. No risk, no rewrites.
  2. Start building Data Agents. Pick one domain — finance is usually the easiest win — and create a Data Agent scoped to your finance semantic model. Let your finance team try natural language queries. Iterate on the configuration.
  3. Explore Database Hub. If you are managing multiple database services, request early access to Database Hub. Unified management is a force multiplier for small DBA teams.

If You Are on Azure SQL / Synapse Today

  1. Evaluate HorizonDB for new PostgreSQL workloads. If you are starting a new AI-adjacent project that needs vector search, HorizonDB gives you relational + vector in one service. No separate vector database needed.
  2. Use the Migration Assistant. The ADF and Synapse pipelines migration assistant is in public preview. It automates the conversion of existing pipelines into Fabric. For SQL databases, a separate migration assistant (also in public preview) imports schemas through DACPACs, while a direct-connection option — generally available since June 2026 — lets the assistant connect directly to the source warehouse.
  3. Plan for Database Hub. As your database estate grows, having a unified management layer becomes critical. Start thinking about how Database Hub fits into your governance model.

If You Are Considering Fabric from Scratch

  1. Start with mirroring. Fabric now mirrors SAP Datasphere (GA), Oracle (GA), SharePoint Lists (preview), Dremio (preview), and more. Use mirroring to get a low-risk copy of your existing data into OneLake without disrupting production systems.
  2. Build your semantic layer first. Before you jump to agents or AI, make sure your Power BI semantic models are solid. Fabric IQ builds on top of these, and Data Agents depend on them. A weak semantic layer means weak agents.
  3. Think about governance from day one. OneLake security reached general availability on Microsoft's announcement timeline, and now provides row-level and column-level controls, with further capabilities (Eventhouse coverage, security APIs, simplified column-level security) shipped in July 2026. Set them up early — retrofitting governance is always harder than building it in from the start.

A Note on Cost

Microsoft also announced Savings Plans for databases, offering up to 35% savings compared to pay-as-you-go on select services. If you are committing to Fabric long-term, this is worth evaluating with your Microsoft account team. In the Southeast Asia market, where cost optimization is often a key selling point for cloud adoption, every percentage point matters.

Pitfalls to Watch Before You Commit

Announcements are exciting; production is where the truth comes out. Based on what I have seen in the field, here is where teams are likely to stub their toes.

1. Data Agents are only as good as your semantic layer. This is the single most common failure mode. If your Power BI semantic models have inconsistent naming, missing descriptions, or overlapping measures, the agent will produce plausible-sounding wrong answers. Budget real time for semantic model hygiene before you demo an agent to your CFO. A pilot with a clean, narrow domain scope beats a broad rollout every time.

2. Prerequisites and capacity licensing. Data Agents require paid F2+ (or P1+) capacity. That sounds small, but in environments still running on per-user Power BI Pro licenses with no reserved capacity, this is a procurement change, not a toggle. Confirm your capacity model before promising a timeline to stakeholders.

3. GPU acceleration is early access, not GA. Do not build migration business cases on the 7x headline until the feature reaches your region and your workload has been measured. Preview features change, region availability is limited, and your query mix may not match the benchmark scenarios. Treat it as upside, not baseline, in your TCO model.

4. HorizonDB is in preview — plan the exit strategy too. For production-critical workloads, evaluate what happens at GA: pricing changes, supported regions, extension compatibility with your PostgreSQL toolchain. Because HorizonDB keeps full PostgreSQL wire compatibility, the blast radius of a misjudgment is smaller than a proprietary platform — but still validate your specific extensions and drivers.

5. Database Hub does not replace your governance model. Unified management gives you one pane of glass, but it also centralizes the blast radius of misconfiguration. RBAC design, service principals, and audit logging across your Arc-registered SQL Servers need the same rigor as before — arguably more, since one console now touches everything.

6. Mirroring is not migration. Mirrored data in OneLake is a low-risk copy for analytics — it does not retire the source system, and it adds latency considerations for anything that needs fresh data. Keep a clear line between "mirrored for analytics" and "migrated" in your roadmap, or stakeholders will assume the source database is already decommissionable.

What It All Adds Up To

Stepping back, the overarching story from FabCon 2026 is clear: Microsoft is building Fabric into the unified enterprise data and AI platform. Not just analytics, not just warehousing, not just databases — all of it, connected through OneLake, governed through Fabric IQ, and made accessible through Data Agents.

The HorizonDB announcement signals that Microsoft is serious about owning the database layer for AI workloads. The GPU-accelerated warehouse shows they are willing to invest in hardware-level performance differentiation. And Data Agents going GA means the "talk to your data" promise is now production-ready, not just a demo.

For enterprise teams in Southeast Asia, this is a moment to reassess your data platform strategy. The gap between "having data" and "using data effectively" has always been about accessibility, governance, and performance. These announcements address all three.

The teams that move early on GPU acceleration and Data Agents will have a meaningful advantage in how quickly they can deliver AI-powered insights to their business stakeholders.

Key Takeaways

  1. Data Agents are production-ready (GA). Start with one domain, ground it in your governed semantic model, and let business users ask questions in natural language. This is the lowest-risk, highest-impact entry point for enterprise AI on Fabric.
  2. HorizonDB changes the PostgreSQL game. With 128TB elastic storage, DiskANN filtered vector search, and built-in AI model management, it eliminates the need to stitch together separate relational and vector databases for AI workloads.
  3. GPU-accelerated Data Warehouse delivers up to 7x speedup with zero query changes — in early access preview today. Enable it from workspace settings once your tenant has access and measure the difference on your existing workloads.
  4. Database Hub unifies management across your hybrid database estate. Whether your databases are on-premises via Azure Arc, in Azure SQL, or in Cosmos DB, Database Hub gives you one interface to manage, monitor, and govern them all.
  5. Migration paths are maturing. The ADF/Synapse pipeline migration assistant, the SQL database migration assistant with DACPAC support, and the direct-connection option mean moving to Fabric is getting easier. Start with mirroring for low-risk data replication, then plan your full migration with proper governance.

Got questions about Fabric, HorizonDB, or how to plan your migration? Reach out at wenfeng.my or connect with me on LinkedIn.