Microsoft this week significantly expanded its Fabric data platform, adding native mirroring support for Oracle databases and Google BigQuery, and introducing a new graph database built from LinkedIn’s internal technology. The updates, unveiled at the FabCon conference, aim to let enterprises replicate data from two of the most entrenched analytics sources into Fabric’s OneLake storage layer without building custom ETL pipelines—and then query that data alongside relationship models that can ground AI agents.

What Fabric Just Added: Oracle, BigQuery, and a Graph Engine

The marquee additions are a pair of new mirroring connectors and a low-code graph workload. Mirroring, which Microsoft introduced in late 2023, already supports sources like Azure SQL, Azure Cosmos DB, and Snowflake. The new connectors extend that list to include Oracle—widely used for on-premises transactional systems and legacy data warehouses—and Google BigQuery, a cloud-native analytical warehouse. Once configured, Fabric creates an initial snapshot of the source database and lands it in OneLake as Delta Lake tables. From then on, change data capture (CDC) keeps the replica synchronized in near real time, with Microsoft claiming updates typically appear within five minutes.

The separate Graph in Fabric offering lets users model relationships across enterprise data without extracting it from OneLake. Microsoft says the engine is based on graph design principles and engineering work that originated at LinkedIn, which it acquired in 2016. The service is designed for scenarios like fraud detection, supply-chain tracing, and recommendation systems, and to help AI agents reason more accurately by first filtering through a knowledge graph before applying vector search or large language models.

How the Mirroring Engine Works Behind the Scenes

Fabric mirroring operates in two phases. First, it performs an initial bulk snapshot of the source database’s tables, writing the data to OneLake in Apache Parquet format with Delta Lake metadata. This gives Fabric workloads a queryable baseline without any transformation code. Once the snapshot completes, mirroring taps into the source system’s native CDC streams—Oracle’s database CDC or BigQuery’s change tracking, for example—and continuously applies changes to the OneLake tables. Microsoft also announced support for Apache Iceberg, so data stored in OneLake can be accessed by Iceberg-first platforms through metadata translation.

For on-premises Oracle databases, the setup requires a Fabric enterprise gateway deployed behind the customer’s firewall. The gateway provides a secure channel for the initial snapshot and ongoing CDC without exposing the database directly to the internet. Permissions must be granted so Fabric can read the source and capture changes. Once mirrored, the data inherits OneLake’s governance and access controls, allowing administrators to set row-level and column-level security policies that apply across all Fabric workloads.

What “Near Real-Time” Means in Practice

Microsoft’s own messaging says mirroring keeps the replica “in near real time” and that changes can appear in less than five minutes. In a briefing, Arun Ulag, corporate vice president of Azure Data, told The Register that “with less than five minutes latency, Fabric keeps the database, the metadata instance, in sync with the original automatically.” Community testing and third-party vendor reports suggest that actual replication lag varies widely: some setups achieve sub-second streaming through partner solutions like Striim, while native mirroring for certain sources can take minutes during peak loads or large change volumes.

No universal service-level agreement (SLA) guarantees a fixed latency across all source types. Enterprises should benchmark their own workloads. A useful test is to measure both the time from source change to OneLake arrival and the end-to-end time until a Power BI Direct Lake report reflects the update. During the pilot, stress-test with synthetic change rates that match peak production, and observe behavior during schema modifications or network congestion.

The Graph Database: LinkedIn’s Tech, Now in Fabric

Graph in Fabric is a fully managed, low/no-code platform that lets users build relationship models directly on top of data already in OneLake. According to Microsoft, the graph engine was built by the same team that created LinkedIn’s massive graph infrastructure, then moved into Azure Data engineering. This lineage matters: LinkedIn’s graph powers real-time recommendations and professional network features at planetary scale, so the technology is proven for high-cardinality, fast-changing relationships.

The service integrates with other Fabric components. A data analyst can define a graph from OneLake tables, query it using Cypher or a visual interface, and combine results with SQL or vector searches in the same notebook. Microsoft sees this as a key enabler for AI agents. Instead of scanning an entire dataset, an agent can use the graph to narrow the context to relevant entities, then apply a language model to reason within that subset. Official messaging calls out fraud detection, supply-chain optimization, and customer 360 scenarios as prime candidates.

What This Means for Enterprise Data Teams

For organizations already invested in the Microsoft data ecosystem—Power BI, Synapse, Purview—these additions remove significant engineering friction. Instead of maintaining separate CDC pipelines, teams can mirror Oracle and BigQuery directly into OneLake and query the data alongside other sources. Power BI can use Direct Lake mode over the mirrored Delta tables, eliminating import refreshes and enabling near real-time reporting. Administrators gain a single pane for governance, and data engineers can stop building bespoke connectors.

However, the impact varies by role:

  • For system administrators: The on-premises Oracle connector requires a Fabric gateway, so plan for gateway sizing, high-availability configurations, and least-privilege service accounts. Validate that the gateway does not become a bottleneck during the initial snapshot of multi-terabyte databases.
  • For data engineers: While mirroring handles the mechanical data movement, teams still need to manage semantic model creation, column mappings, and data quality checks downstream. The graph engine is a new tool that can simplify relationship modeling, but learning its query language and scaling properties will require investment.
  • For business analysts and Power BI users: The most immediate benefit is fresher data, provided the operational latency meets expectations. The graph database could unlock new types of analysis—such as tracing dependencies in a bill of materials or detecting circular supply chains—that were previously cumbersome in SQL.

The Real Cost of “Free” Mirroring Compute

Microsoft’s pricing pitch for mirroring is aggressive: “the compute for mirroring is free to the customer,” Ulag said, adding that Microsoft absorbs the cost and provides storage allotments so customers don’t worry about storage expenses. The official documentation echoes this, stating that mirroring compute and a generous storage tier are included with Fabric capacity SKUs.

Community forums, however, contain threads where users report seeing OneLake write transactions and capacity unit (CU) consumption during heavy mirroring activity, suggesting the accounting model may not be as straightforward as “free.” In practice, the free storage allotment is capped per SKU (e.g., 10 TB for an F64 capacity), and overages revert to standard OneLake billing. Large Oracle warehouses or high-volume BigQuery datasets can quickly exceed those limits. Moreover, while mirroring compute might not directly drain CUs, downstream workloads that query the mirrored data—such as Power BI Direct Lake or notebook jobs—consume capacity as normal.

Before committing production pipelines, run a pilot that mirrors a representative dataset for a full billing period and compare the OneLake/CU usage against expectations. Model storage costs for snapshot retention and CDC retention, and clarify whether your chosen SKU’s free tier covers the entire dataset.

A Practical Roadmap for Adoption

Adopting Fabric mirroring and Graph does not require a rip-and-replace of existing tools, but it does demand careful validation. Start by inventorying which Oracle instances and BigQuery datasets would deliver the most value if combined in OneLake. Prioritize tables that feed multiple reporting systems or where relationship modeling could improve fraud detection or supply-chain analytics.

Next, set up a proof of concept. Pick a handful of tables, including at least one large table and one high-change table, and mirror them. Measure the initial snapshot time, steady-state CDC latency, and the OneLake storage footprint. Test schema evolution—add a column, drop a column—and see how mirroring handles it. For on-premises Oracle, configure the enterprise gateway and confirm it maintains connectivity through firewall rules and network changes.

Once the data is in OneLake, build a small graph from production-like data. Test simple relationship queries and, if you’re exploring AI agent scenarios, feed graph-filtered context to a language model and evaluate accuracy. At the same time, validate billing: compare actual CU and storage usage against the free tier, and project costs as you scale up.

Finally, consider hybrid architectures. For extremely high-throughput sources or where you need sub-second latency guarantees, partner mirroring services like Striim or CData can complement Fabric’s native connectors. And if you already use Neo4j or TigerGraph, you can keep those while experimenting with Fabric Graph for knowledge-graph–style workloads.

What’s Next for Fabric

Microsoft has signaled that mirroring will continue to expand to more sources, with the Oracle and BigQuery connectors currently in preview and general availability dates to be announced. Expect tighter billing dashboards in the Fabric admin portal to clarify what mirroring compute and storage are included per SKU. The open mirroring ecosystem will also grow: third-party vendors are building adapters using Fabric’s open mirroring APIs, giving customers more choices for specialized connectivity.

Graph in Fabric is also poised to evolve. Microsoft plans to expose Model Context Protocol (MCP) endpoints so AI agents can directly query the graph, and deeper Copilot integrations will let users ask natural-language questions over relationship data. As the line between analytics and AI continues to blur, Fabric’s combination of open-format mirroring and a native graph engine positions it as a credible hub for building AI-ready data fabrics—provided teams test thoroughly before going all in.