Microsoft’s Fabric platform just widened its berth for enterprise data: Fabric now supports mirroring from Oracle and Google BigQuery into OneLake, and it adds a native graph database built on technology from LinkedIn to model relationships at scale. The mirroring capability creates a Delta Lake–formatted snapshot of external warehouses and keeps that replica synchronized in near real time, while the new Graph workload overlays directly on OneLake to let analysts and AI agents reason about entity relationships without costly ETL. These additions are significant because they extend Fabric’s “zero ETL” ambition to two of the most entrenched enterprise data sources and add relationship-first tooling that’s becoming central to modern AI workflows. (blogs.microsoft.com)
Microsoft launched Fabric as a unified, AI-ready data and analytics platform to bring together ingestion, storage, governance, analytics, and machine learning. OneLake—the platform’s single logical data lake—acts as the storage and metadata plane, with workloads (Warehouse, Lakehouse, Real‑Time Intelligence, Notebooks, etc.) reading the same open data formats. Mirroring was introduced to create managed replicas of external operational/datastore systems inside OneLake so Fabric workloads could use that data directly, and over the past year Microsoft has been steadily adding sources and refining the experience. The recent FabCon updates extend mirroring to Oracle and Google BigQuery and add a Graph workload described by Microsoft as built from LinkedIn graph design principles. (support.fabric.microsoft.com)
This article walks through what the Oracle and BigQuery mirroring additions mean, how the mirroring engine works under the hood, the promise and limits of the new Graph capability, and what IT teams should test and plan before adopting these Fabric features in production.
A single quoted time—such as The Register’s paraphrase of “less than five minutes latency”—is not documented as an explicit SLA across all sources. That lower bound may be achievable in many setups but should not be treated as a guaranteed maximum latency for every deployment. Enterprises should benchmark with their own workloads to determine the operational freshness they can rely on. If your applications require deterministic latency SLAs, test mirroring under representative peak loads and validate behavior during schema drift, large snapshot operations, and network congestion. (blogs.microsoft.com)
That said, the move is not a turnkey cure for every migration problem. Latency behavior varies by source and workload; billing nuances around OneLake operations deserve careful validation; and extremely large or high‑change datasets may need specialist tuning or hybrid architectures. For teams considering Fabric mirroring or Graph for agents, the practical path is to pilot with production‑like datasets, stress‑test at scale, and baseline billing before you commit production pipelines. When those prerequisites are satisfied, Fabric’s expanded mirroring and graph features can materially simplify the journey to an AI‑ready data fabric—especially for organizations seeking to combine relational, warehouse, and relationship data without rebuilding an entire integration stack. (microsoft.com)
Source: theregister.com Microsoft weaves Oracle and BigQuery into Fabric
Microsoft launched Fabric as a unified, AI-ready data and analytics platform to bring together ingestion, storage, governance, analytics, and machine learning. OneLake—the platform’s single logical data lake—acts as the storage and metadata plane, with workloads (Warehouse, Lakehouse, Real‑Time Intelligence, Notebooks, etc.) reading the same open data formats. Mirroring was introduced to create managed replicas of external operational/datastore systems inside OneLake so Fabric workloads could use that data directly, and over the past year Microsoft has been steadily adding sources and refining the experience. The recent FabCon updates extend mirroring to Oracle and Google BigQuery and add a Graph workload described by Microsoft as built from LinkedIn graph design principles. (support.fabric.microsoft.com)This article walks through what the Oracle and BigQuery mirroring additions mean, how the mirroring engine works under the hood, the promise and limits of the new Graph capability, and what IT teams should test and plan before adopting these Fabric features in production.
What’s new: Oracle and BigQuery mirroring
Why this matters now
Oracle and Google BigQuery are pillars of many enterprise analytics estates: Oracle for transactional systems and legacy data warehouses, BigQuery as a scalable cloud warehouse for analytical workloads. By providing a managed, near‑real‑time replica of these systems inside OneLake, Fabric aims to remove the friction of building and operating ETL/CDC pipelines and to enable cross‑workload joins and Direct Lake Power BI analytics over a single copy of the data. For organizations with mixed-cloud and on‑prem estates this removes an onerous integration project from migration and AI initiatives. Microsoft’s announcement explicitly positions these connectors as a way to bring more enterprise data into an AI‑ready fabric without repeated data movement. (blogs.microsoft.com)Key capabilities Microsoft describes
- Initial snapshot: Fabric performs an initial snapshot of the source to establish the baseline copy.
- Ongoing CDC-based sync: After snapshot, mirroring uses Change Data Capture (CDC) to keep the OneLake replica synchronized in near real time.
- Format conversion: Incoming changes are landed as Parquet/Delta Lake tables that Fabric workloads can query directly.
- Management and observability: Mirrored databases expose SQL analytics endpoints, monitoring of refreshes, and granular controls over what is mirrored. (support.fabric.microsoft.com)
Technical underpinnings: how mirroring actually works
CDC, snapshots, and Delta tables
The mirroring flow is conceptually straightforward but operationally complex at scale. Microsoft documents an initial snapshot that writes a baseline of source tables into OneLake; subsequent changes are captured using the source system’s CDC mechanisms (native streams in Snowflake, database CDC in Oracle/Azure SQL/Postgres, etc.) and transformed into Delta Lake tables in the OneLake landing zone. Fabric then manages conversion into queryable tables and metadata endpoints that other Fabric workloads consume. This approach gives consumers a single, analytics-ready representation in Delta format. (support.fabric.microsoft.com)File and metadata formats: Delta, Parquet, Iceberg
Mirrored data lands in open columnar formats (Apache Parquet) and is managed using Delta Lake metadata by default, because Fabric engines are Delta-native. Microsoft has also added support for Apache Iceberg and provides translation layers so data can be accessed by Iceberg‑first platforms. This interoperability is central to Microsoft’s pitch: OneLake is an “open” lake where Delta and Iceberg coexist and can be translated to enable cross-platform access without duplicating data. Databricks, Snowflake, and other players have their own lakehouse formats and translation projects; OneLake’s approach is to offer both and translate at the metadata layer. (microsoft.com)Connectivity and security
For on‑prem or firewall‑protected sources (such as Oracle in datacenters), Microsoft recommends using a Fabric enterprise gateway to establish secure connectivity. Mirroring requires appropriate permissions on the source systems; the initial snapshot will need read access, and CDC requires the source’s CDC/log‑streaming features to be enabled. OneLake also extends catalog and access controls so data owners can enforce row‑ and column‑level policies across Fabric workloads. These operational prerequisites are important gating items for enterprise rollouts. (blogs.microsoft.com)Pricing and cost posture: “compute is free” — but read the fine print
Microsoft’s public pricing statement
Microsoft’s official messaging for Fabric’s mirroring has repeatedly emphasized that the compute used to support mirroring and a generous storage allotment are provided at no additional charge within Fabric capacity SKUs. The Power BI / Fabric documentation states mirroring storage and compute cost is free, and that certain capacity SKUs include terabytes of storage equivalent for mirrored data. This is the foundation of Microsoft’s “make it easy to bring data in” commercial pitch. (powerbi.microsoft.com)Where customers have seen ambiguity
Community reports and independent analyses have flagged areas that merit careful billing tests:- Transactional writes and OneLake operations: Some community members report OneLake write transactions and capacity unit (CU) accounting behave differently depending on workload. Microsoft’s messaging insists mirroring compute is not billed against Fabric capacity in the typical sense, but customers have reported seeing CU lines during heavy mirroring activity on some reports. These threads indicate that accounting models may be nuanced (e.g., free mirroring compute vs. query costs, or storage allowances that differ by SKU). (reddit.com)
- Storage caps: Microsoft provides free mirroring storage up to an SKU-based allotment; overages revert to standard OneLake billing or require capacity changes. That makes capacity planning important when mirroring large Oracle warehouses or extensive BigQuery datasets. (powerbi.microsoft.com)
Latency and freshness: “near real time” is not a single SLA
Microsoft describes mirroring as keeping a replica “in near real time” and documentation and partner messaging range from sub-second (for some partner-managed streaming solutions) to seconds-to-minutes in typical managed setups. Third‑party mirroring solutions like Striim advertise sub‑second or very low latency for specialized pipelines; Microsoft’s native mirroring language is intentionally broader. Community testing and vendor blogs report that actual replication lag varies with source type, CDC throughput, network latency, and the size of the initial snapshot. In practice, expected latency windows have ranged from very low seconds (for optimized streaming paths) up to minutes in heavier or more complex environments. (microsoft.com)A single quoted time—such as The Register’s paraphrase of “less than five minutes latency”—is not documented as an explicit SLA across all sources. That lower bound may be achievable in many setups but should not be treated as a guaranteed maximum latency for every deployment. Enterprises should benchmark with their own workloads to determine the operational freshness they can rely on. If your applications require deterministic latency SLAs, test mirroring under representative peak loads and validate behavior during schema drift, large snapshot operations, and network congestion. (blogs.microsoft.com)
The new Graph workload: LinkedIn DNA at OneLake scale
What Microsoft shipped
Fabric now includes a Graph workload described as a low/no‑code platform that models relationships across enterprise data. Microsoft explicitly states the graph technology draws on graph design principles and engineering work that originated at LinkedIn, and has repurposed that expertise into a cloud‑native graph engine that runs directly on top of OneLake. The Graph workload is intended to let Fabric customers build knowledge graphs and relationship models that power scenarios like fraud detection, supply‑chain tracing, recommendation systems, and improved grounding for AI agents. (blogs.microsoft.com)Why a native graph matters for AI and agents
Graphs encode relationships explicitly. Modern AI applications benefit from two-stage approaches that limit the search space (graph filters) and then apply vector search or LLM reasoning to the reduced set of entities. Microsoft’s messaging and interviews with leadership call out precisely this pattern: use a graph to narrow context, use vector search and LLMs to reason within that context. For enterprise datasets where relationships define outcomes—customer-to-order-to-fulfillment chains, network topology, or device‑to‑component dependencies—an integrated graph engine avoids repeated joins or costly data movement and enables query patterns that relational engines struggle to express ergonomically. (venturebeat.com)Built from LinkedIn expertise—not just marketing
Multiple Microsoft posts and coverage by independent outlets confirm the graph engine leverages LinkedIn’s years of real‑world graph experience. Microsoft moved portions of LinkedIn’s graph engineering team into Azure Data engineering to adapt the tech for enterprise use, and Microsoft states the graph engine is distributed and scale‑out by design—important characteristics for operating on OneLake data at enterprise scale. This is a notable difference from adding third‑party connectors: the graph capability is embedded into Fabric’s storage and governance fabric and is available to every Fabric customer (subject to preview/GA availability and SKUs). (blogs.microsoft.com)How Graph connects to OneLake and other workloads
Graph data overlays OneLake and references OneLake tables and metadata. That integration means graph queries can be combined with vector or SQL queries, and results feed into Power BI, notebooks, or Fabric agents. Microsoft positions this as a native capability—no extraction required—and emphasizes that this approach coexists with partnerships (Neo4j and TigerGraph integrations remain supported for customers needing additional native graph features or vendor relationships). Expect scenarios where customers use Fabric Graph for enterprise-scale knowledge graphs and retain Neo4j/TigerGraph for specialized graph analytics or operational graph workloads. (neo4j.com)Strengths, limitations, and risks
Strengths
- Friction reduction: Native mirroring removes a large portion of the engineering work required to get data into a single analytics plane—no bespoke CDC pipelines to maintain for many sources. (support.fabric.microsoft.com)
- Open formats: Using Delta and Parquet—and adding Iceberg translation—improves interoperability with other lakehouse engines, limiting some forms of vendor lock‑in. (microsoft.com)
- Integrated governance: OneLake catalog and OneLake security provide centralized access controls and lineage, making governance across mirrored sources more manageable than disparate pipelines. (microsoft.com)
- Graph + AI synergy: Combining a native graph overlay with vector search and Fabric’s AI workloads reduces round‑trips and improves the realism of grounded agent responses. (venturebeat.com)
Limitations and operational risks
- Variable latency: “Near real time” is environment dependent. Some setups reach seconds; others may be minutes. No universal SLA is published that guarantees a fixed upper bound for all source types. Benchmark representative workloads. (microsoft.com)
- Cost accounting ambiguity: Although Microsoft advertises free mirroring compute and an allotment of storage, community reporting and third‑party analysis show potential ambiguities around OneLake transaction billing and CU accounting when mirroring heavy workloads. Validate billing in a pilot and model overages. (powerbi.microsoft.com)
- Scale and large‑table issues: Community threads show customers experiencing problems when mirroring very large tables or extremely high change volumes; these can require tuning or partner solutions. Test scaling behavior and plan fallback patterns for backpressure. (community.fabric.microsoft.com)
- Migration and transformation constraints: Mirroring keeps a replica in OneLake, but it does not magically solve downstream schema mapping or semantic alignment. Teams still need to manage semantic model creation, column mappings, and data quality. (support.fabric.microsoft.com)
How this compares to alternatives
- Traditional CDC tools (Fivetran, Qlik, Debezium-based pipelines) give fine‑grained control and plug into various object stores. They may require more engineering but can be more predictable for billing and for custom transformation logic.
- Managed real‑time integration partners (Striim, CData) provide specialized low-latency mirroring and broader connector coverage; they can be integrated into Fabric’s open mirroring APIs. These services are useful when source systems require specialized log access or when on‑prem connectivity is constrained. (microsoft.com)
- Vendor graph platforms (Neo4j, TigerGraph) remain strong for specialized graph analytics. Microsoft’s Fabric Graph is a native, integrated alternative that prioritizes OneLake integration and the low‑code experience; but customers with existing Neo4j investments or specialized queries may continue to use both. Neo4j has announced an integrated AuraDB workload in Fabric for customers wanting the Neo4j engine inside the Fabric experience. (neo4j.com)
Practical guidance: adoption checklist for WindowsForum readers
- Inventory and prioritize sources
- Identify Oracle instances and BigQuery datasets you’d like mirrored. Focus on high-value tables where relationship modeling, reporting, or agent grounding matters.
- Pilot a representative workload
- Mirror a subset of tables (including a large table and a high-change table) to measure initial snapshot time, steady‑state CDC latency, and OneLake storage impact.
- Validate billing and capacity
- Run the pilot for a billing period and compare OneLake/CU accounting against expectations. Confirm the free mirroring storage allotment applies to your chosen SKU and model overage costs.
- Test Graph scenarios
- Create a small knowledge graph using production‑like data. Validate query patterns, vector search interplay, and any LLM grounding scenarios you need.
- Measure operational behavior
- During the pilot, test schema evolution (add/drop columns), outage recovery, and backfill flows to see how mirroring copes in non‑ideal conditions.
- Security and connectivity
- For on‑prem Oracle: deploy a Fabric enterprise gateway behind the firewall, validate service accounts and least‑privilege permissions, and verify data flows comply with internal compliance policies.
- Plan for governance and lineage
- Use OneLake catalog and OneLake security to set up access controls and automated lineage; ensure Purview or equivalent policies integrate with OneLake.
- Consider hybrid approaches
- For high‑throughput or specialized cases, evaluate partner mirroring services or maintain a hybrid architecture with both Fabric mirroring and third‑party CDC tools.
Realistic expectations and recommended tests
- Expect the initial snapshot of very large warehouses to require nontrivial time and temporary storage; plan downtime windows or snapshot throttling.
- Run two latency tests: write‑to‑OneLake (time for CDC to appear in the landing zone) and query‑to‑report (time for a Fabric workload such as Power BI Direct Lake to reflect the change).
- Stress test with synthetic change volumes similar to your busiest production periods; watch for processing queues, failed parquet conversions, or mirrored DB stalls reported by some community users.
- Validate role‑based access and encryption settings; confirm OneLake security maps correctly to your row/column policies to avoid accidental exposure.
What to watch next
- Feature parity across sources: Microsoft has a roadmap to broaden supported databases; check the Fabric roadmap for GA timing on Oracle and BigQuery mirroring for full enterprise support and documented SLAs. (blogs.microsoft.com)
- Billing clarity and reporting: expect additional documentation and UI cues in Fabric admin panels to clarify what mirroring compute and storage are included per SKU and how OneLake transactions are accounted.
- Open mirroring ecosystem: third‑party vendors will expand open mirroring adapters and managed services, giving customers options when native mirroring needs augmentation or customization. (cdata.com)
- Graph and agent tooling: follow how Microsoft exposes Model Context Protocol (MCP), vector integrations, and Copilot/agent features that leverage Graph to assess how easy it becomes to build production agents with grounded knowledge graphs. (blogs.microsoft.com)
Conclusion
Microsoft’s expansion of Fabric mirroring to include Oracle and BigQuery, combined with the integration of a LinkedIn‑bred graph engine, is a clear signal that Fabric is moving from a Microsoft‑centric analytics hub to a broader enterprise data fabric that tries to meet customers where their data already lives. The technical story—one‑time snapshot, CDC, Delta/Parquet landing, and a graph layer on OneLake—aligns with modern data platform practices and promises to reduce engineering friction for many analytics and AI projects. (support.fabric.microsoft.com)That said, the move is not a turnkey cure for every migration problem. Latency behavior varies by source and workload; billing nuances around OneLake operations deserve careful validation; and extremely large or high‑change datasets may need specialist tuning or hybrid architectures. For teams considering Fabric mirroring or Graph for agents, the practical path is to pilot with production‑like datasets, stress‑test at scale, and baseline billing before you commit production pipelines. When those prerequisites are satisfied, Fabric’s expanded mirroring and graph features can materially simplify the journey to an AI‑ready data fabric—especially for organizations seeking to combine relational, warehouse, and relationship data without rebuilding an entire integration stack. (microsoft.com)
Source: theregister.com Microsoft weaves Oracle and BigQuery into Fabric