Microsoft Fabric June 2026 — Practical Guide

Fabric's June 2026 update is one of the heavier monthly releases I've seen since the platform launched. The themes are clear: AI capabilities moving from preview to production, GPU-accelerated warehouse capacity, and Data Agents reaching a general-availability state inside Microsoft 365 Copilot.

If you've been evaluating Fabric as a warehouse-plus-Power BI play, this release shifts what the platform can actually do. You can now enrich, classify, and summarize data inside T-SQL and PySpark without wiring external endpoints, and business users can query governed data in natural language from within Copilot.

Here's what the update actually delivers, what's genuinely production-ready versus still in preview, and what I'd adopt first.

AI Functions: gpt-5-mini Is Now the Default

The headline change: Fabric AI Functions now default to gpt-5-mini with reasoning_effort set to low. The model carries a 400,000-token context window and a 128,000-token maximum output. For more complex transformations, you can configure gpt-5.1 or raise reasoning_effort to trade compute for higher-quality results.

AI Functions work across pandas, PySpark, Dataflow Gen2, and the Data Warehouse SQL surface. Fabric manages the endpoint for you — no Azure OpenAI resource to provision, no keys to rotate.

One important detail: the warehouse SQL surface is still labeled Preview in Microsoft Learn, and the function set there is specific. There is no generic "generate anything" function. What you actually get:

-- Real AI Functions available in Fabric warehouse SQL
SELECT AI_ANALYZE_SENTIMENT('This hotel was great!') AS sentiment;

SELECT AI_CLASSIFY('Room was dirty', 'service', 'dirt', 'food') AS classification;

SELECT AI_EXTRACT('Check-in was late and room dirty', 'sentiment', 'problem') AS extraction;

SELECT AI_SUMMARIZE('The hotel was clean and staff were friendly.') AS summary;

SELECT AI_GENERATE_RESPONSE('Reply in 20 words:', 'The room was noisy.') AS response;

SELECT AI_TRANSLATE('The hotel was great', 'de') AS translation_de;

SELECT AI_FIX_GRAMMAR('Th room are clean and staff were nice') AS fixed_text;

The practical pattern is to run these over a warehouse table — say, enriching a week of support tickets with classification and sentiment — and materialize the results rather than recomputing on every query. Microsoft's own guidance warns that these functions call external AI APIs and can affect query performance, so precompute and stage the results.

The pricing model matters

AI function calls through the built-in Fabric endpoint are billed to your Fabric capacity under the Copilot and AI meter. Consumption is measured in CU seconds per 1,000 tokens, and the difference between models is significant:

Model	Input (per 1K tokens)	Cached input	Output (per 1K tokens)
gpt-5-mini	8.40 CU seconds	0.84 CU seconds	67.23 CU seconds
gpt-5.1	42.02 CU seconds	4.20 CU seconds	336.13 CU seconds

That's roughly a 5x cost delta between the two models on input, and the same ratio on output. Cached input is a 10x discount over fresh input, which rewards stable, repeated prompts over a dataset. Run enrichment as a batch job over materialized text, not inline in a live dashboard query.

In pandas and PySpark notebooks, the interface is just as direct — classify a column with one call, then read token usage back from df.ai.stats:

# PySpark AI Functions — default model is gpt-5-mini, reasoning_effort="low"
df = spark.table("support_tickets_lakehouse.raw_tickets")

enriched = df.ai.classify(
    labels=["billing", "technical", "account"],
    input_col="body",
    output_col="category",
)

# Track consumption before you scale the job
stats = enriched.ai.stats
print(stats)  # cached_tokens, input_tokens, output_tokens, reasoning_tokens, model

You can set progress_bar_mode="stats" to see live capacity-unit estimates while a function runs. If you're budgeting a large enrichment job, this is how you do it.

If the built-in endpoint doesn't fit your requirements, pandas and PySpark also support bringing your own model via a custom Azure OpenAI, Microsoft Foundry, or OpenAI-compatible endpoint. Fabric doesn't charge for those model calls — your provider bills token usage — but Fabric compute still applies.

GPU-Accelerated Data Warehouse (Preview)

The June update introduces GPU acceleration for the Data Warehouse — one of the most-watched preview features in this release. The stated benefit is faster query execution and reduced processing times on large datasets, with a workspace-level setting for administrators to enable GPU-accelerated queries and monitoring that shows which queries were accelerated and what improvement they achieved.

Two honest caveats. First, this is Preview — treat it as an evaluation target, not a production dependency. Second, the June update documentation positions GPU acceleration around query performance on large datasets; it does not yet document a separate GPU tier sized specifically for AI-function workloads. If your architecture review depends on GPU behavior for AI Functions specifically, wait for the GA documentation before committing.

What's directionally clear: Fabric is investing in compute headroom for the AI-enriched analytics pattern — queries that mix traditional aggregation with model calls. If you're designing a platform where BI and AI workloads share one warehouse, this is the piece to watch.

The warehouse got operational improvements alongside GPU acceleration:

Warehouse Monitor — visibility into running and completed queries, with the ability to spot expensive or failed ones and cancel runaway queries
CI/CD for SQL Analytics Endpoints — schema changes managed through database projects in Git and deployed through pipelines
Time Travel support — query historical versions of warehouse data for auditing and recovery scenarios

Data Agents: Generally Available in Microsoft 365 Copilot

This is the feature with the broadest organizational impact. The Fabric data agent is now a generally available feature for building conversational Q&A over your enterprise data — and the June update continues the push to surface data agents inside Microsoft 365 Copilot, so business users can ask natural-language questions from Teams, M365 Chat, and Copilot surfaces without opening Fabric.

The governance story is the reason I'd take this seriously for production:

Same security model, same results. Row-Level Security and Column-Level Security still apply. Access to a Power BI semantic model through a data agent is governed by Read permission on the model — no workspace-level access required, but no more access than that.
Microsoft Purview integration. When data agents are surfaced through M365 Copilot, Purview governance policies continue to apply. Users can only access what their credentials and Purview policies allow, regardless of entry point.
Precedence layers. Organizational policies and workspace governance settings override developer instructions and user prompts. The agent operates within approved boundaries no matter how it's configured.
Auditability. Agent interactions can be logged and discoverable through Purview Audit and eDiscovery.

On the capability side, the June release adds improvements to NL2SQL accuracy, multi-source query routing (the agent determines which source holds the answer), and a built-in code interpreter for more advanced analysis without leaving the agent.

Provisioning the capacity underneath

Data agents, AI Functions, and warehouse workloads all consume Fabric capacity (F SKUs). If you're standing up a dedicated capacity for this, the Azure CLI covers it:

az fabric capacity create \
  --resource-group rg-fabric-prod \
  --capacity-name fab-prod-my \
  --administration "{members:[[email protected]]}" \
  --sku "{name:F4,tier:Fabric}" \
  --location southeastasia

Or declaratively with Bicep:

resource fabricCapacity 'Microsoft.Fabric/capacities@2025-01-15-preview' = {
  name: 'fab-prod-my'
  location: 'southeastasia'
  sku: {
    name: 'F4'
    tier: 'Fabric'
  }
  properties: {
    administration: {
      members: [ '[email protected]' ]
    }
  }
}

Start small — F2 or F4 — pilot the agent and AI Functions on it, then scale the SKU with az fabric capacity update --sku "{name:F8,tier:Fabric}" once you have real consumption data.

OneLake Storage Tiers and Lifecycle Management (Preview)

OneLake gains storage tiers with lifecycle management — rules that automatically move files to lower-cost storage based on criteria like created date, modified date, or last-accessed date. There's also item size reporting for visibility into what's consuming storage across the platform.

This is the cost lever. If you're accumulating years of lakehouse data, lifecycle rules tier cold data without manual intervention — the same pattern Azure Blob Storage lifecycle management gave you, now native to OneLake. It's Preview, so validate behavior on a non-critical workspace before applying rules broadly.

What I'd Adopt First

Based on what's production-ready versus preview, my adoption order:

AI Functions with gpt-5-mini — the cheapest entry point into in-platform AI enrichment. Batch enrichment over materialized tables, with df.ai.stats to track CU burn.
Data Agents — GA, with the security model intact. Pilot with a controlled user group on read-only sources where RLS/CLS already exists.
OneLake lifecycle management — set rules early; cost savings compound monthly.
Warehouse Monitor + CI/CD for SQL endpoints — operational hygiene before you scale AI workloads.
GPU-accelerated warehouse — evaluate in preview once your AI Functions usage grows; wait for GA before depending on it.

Pitfalls to Avoid

Don't write `AI_GENERATE()` and expect it to work. The warehouse AI function set is specific (AI_CLASSIFY, AI_EXTRACT, AI_GENERATE_RESPONSE, etc.). Check the current documentation — the surface area evolves between updates.
Don't run AI Functions inline in interactive queries. Each call consumes capacity. Materialize results into staging tables and query those.
Don't assume gpt-5.1 for everything. At ~5x the CU cost of gpt-5-mini, reserve it for tasks where reasoning quality actually changes the output.
Don't deploy data agents without checking RLS/CLS coverage. The agent respects your security model — which means gaps in your model become gaps in the agent's answers.
Don't conflate Preview with GA. GPU warehouse acceleration and OneLake storage tiers are Preview this cycle. Design for them, but don't make production SLAs depend on them yet.

Key Takeaways

AI Functions default to gpt-5-mini with `reasoning_effort=low` — 400K context, 128K max output — and bill to Fabric capacity in CU seconds. gpt-5.1 is available but costs ~5x more per 1,000 tokens.
The warehouse AI function surface is specific and still Preview — AI_CLASSIFY, AI_EXTRACT, AI_SUMMARIZE, AI_TRANSLATE, AI_FIX_GRAMMAR, AI_ANALYZE_SENTIMENT, AI_GENERATE_RESPONSE. Materialize results; don't run them inline.
Data Agents are generally available and reach users through Microsoft 365 Copilot, with Purview governance, RLS/CLS, and auditability carried through. Start with read-only pilots on governed sources.
GPU-accelerated warehouse and OneLake storage tiers arrive in Preview — evaluate both, but don't build production SLAs on them until GA.
Budget with real numbers. Use df.ai.stats and the Capacity Metrics app to measure AI Functions consumption before scaling the workload.