Microsoft Fabric Warehouse Stored Procedure

A Fabric Warehouse can read Lakehouse data by referencing Delta Lake folders that are automatically represented as tables in the Lakehouse SQL analytics endpoint when they are stored in the Lakehouse /Tables folder. The documented pattern is to reference that data by three-part name notation using the Lakehouse name, schema, and table, for example MyLakehouse.dbo.TaxiTrips.

Based on the documented behavior:

1. The Warehouse query uses the Lakehouse SQL representation of the Delta data.
   The documentation states that Delta Lake folders in OneLake are automatically represented as tables in the SQL analytics endpoint for the Lakehouse, and Warehouse T-SQL can read them using three-part naming.
2. The underlying data is stored in Delta/Parquet in OneLake.
   Fabric stores Lakehouse and Warehouse data in OneLake, and Warehouse user tables are stored in parquet format with Delta Lake logs published. For Lakehouse access from Warehouse, the documented access pattern is through the table representation of Delta folders, not by directly querying raw files with the Lakehouse-style table name syntax.
3. Metadata publication/synchronization is part of the architecture.
   The documentation explicitly says that for Warehouse tables, after a transaction is committed, a background process publishes the updated Delta Lake log. That confirms there can be a delay between commit and external read visibility through Delta-based access paths. The provided context does not document the exact synchronization or caching internals for Lakehouse-to-Warehouse reads, but it does document that SQL analytics endpoint tables are autogenerated from Delta folders and that Delta log publication can be asynchronous.
4. For large-volume reads, use Warehouse for governed SQL workloads and Lakehouse for big data processing.
   The documented guidance is:
   • Use Warehouse for structured, high-performance SQL workloads, BI, reporting, ACID transactions, and strong schema enforcement.
   • Use Lakehouse for big data processing and exploratory analytics.
   • Many organizations use both together: Lakehouse for ingestion and transformation, Warehouse for refined analytics and reporting.

For the delay being observed after writes to the Lakehouse, the supported conclusion from the documentation is that some propagation delay is consistent with Fabric’s Delta-based architecture and autogenerated SQL representations. The context does not provide a documented SLA, cache duration, or a detailed internal execution path beyond that.

For design guidance from the documented material:

• If low-latency SQL reporting is required, load or transform the data into the Warehouse rather than repeatedly querying large Lakehouse tables from Warehouse procedures.
• If the source data is already in the Lakehouse, use CTAS in the Warehouse to materialize the required subset into Warehouse tables.
• For heavy transformation or large-scale data processing, keep that work in the Lakehouse/Spark layer, then publish refined data to the Warehouse for reporting queries.

A documented example of materializing Lakehouse data into Warehouse is:

CREATE TABLE dbo.TaxiTrips_2023
AS
SELECT * 
FROM MyLakehouse.dbo.TaxiTrips 
WHERE DATEPART(YEAR, tpep_pickup_datetime) = '2023';

That pattern is the clearest documented best practice in the provided material for reducing repeated cross-item reads and improving predictability.

• What is Fabric Data Warehouse?
• Delta Lake logs in Warehouse in Microsoft Fabric
• Query the warehouse or SQL analytics endpoint
• Store data in Microsoft Fabric
• Ingest data into your Warehouse using Transact-SQL