TL;DR
Microsoft Fabric time travel in Lakehouse lets you look at a table exactly as it was at an earlier moment. You add a version number or a timestamp to a normal query in a notebook, and nothing about the live table changes. One command lists the versions you can go back to, and another puts the table back to one of them. That history does not last forever, because retention settings decide how far back you can read. Fabric keeps the change log for 30 days by default and clears old data files after seven days. That cleanup is what ends time travel on older versions.
Key Takeaways Time travel in a Fabric Lakehouse is Delta Lake functionality, read through Spark, and it is a read-only query against an older snapshot. A historical read needs two things that expire on different clocks, the Delta log entry and the Parquet files that version points at. delta.logRetentionDuration defaults to 30 days and delta.deletedFileRetentionDuration defaults to one week, so file retention is usually the binding constraint.VACUUM permanently removes unreferenced files, and any version that depended on them stays visible in table history while becoming unreadable. The SQL analytics endpoint and Fabric Warehouse support time travel through a different T-SQL syntax with its own retention window and its own limits. Time travel and backup answer different questions, so a recovery plan needs restore points and copies alongside Delta history. Watch on YouTube
Why Most Fabric Deployments Fail at Scale
Amit Chandak, Kanerika’s Chief Analytics Officer and a Microsoft MVP, walks through the architecture and governance decisions that break Fabric once real load and real retention rules arrive.
The Update That Ran Twice A nightly merge into a Fabric Lakehouse sales table runs twice because a pipeline retry fires after a transient gateway error. Nobody notices until a finance analyst asks why last quarter’s gross value jumped nine percent overnight. The team has no snapshot of yesterday’s table and no backup job pointed at OneLake.
They do have something better. Every write against a Delta table in Fabric Lakehouse is committed as a numbered version, and the previous state is still sitting in storage. One query brings yesterday’s numbers back on screen, and one command puts the table back the way it was.
The part that catches teams out arrives three weeks later, when the same query against the same version returns an error instead of data. That gap between what table history claims to hold and what storage can still reconstruct is what this guide is about.
What Time Travel in a Microsoft Fabric Lakehouse Actually Is Microsoft Fabric time travel in Lakehouse is Delta Lake’s own versioning surfaced through Microsoft Fabric ‘s Spark runtime. Microsoft puts it plainly. Time travel “lets you query a Delta table as it existed at a specific table version or timestamp” and is explicitly read-only .
That read-only property matters more than it sounds. Querying version 14 does not rewind the table and does not create a new version. It also leaves untouched whatever another notebook or semantic model is reading at that moment.
Every Write Creates a Version Delta tables never overwrite data in place. An INSERT, UPDATE, DELETE, MERGE or OPTIMIZE writes new Parquet files and records a new commit, and the commit becomes the next version number.
The old files stay where they are. They stop being referenced by the current version. Being unreferenced and being deleted are different states, and that distinction is the whole basis of the feature.
Reading a Version, Restoring a Version, and Copying a Table Three operations get confused constantly, and each one has a different blast radius.
Time travel reads an old snapshot and leaves the table alone.RESTORE makes an old version the current state for every reader and writer that follows.A copy , written with CREATE TABLE ... AS SELECT, produces an independent table that survives whatever happens to the source.Microsoft’s own best-practice guidance points at that third option for anything long term. It recommends a full copy of the data “for long-term point-in-time requirements” instead of depending on time travel alone.
How the Delta Transaction Log Makes Time Travel Possible Underneath every Delta table in OneLake sits a _delta_log folder, which is where the wider Microsoft Fabric architecture keeps a table’s memory. Each commit writes a small JSON file into it, numbered in sequence, listing the data files added and removed by that operation.
Reading version 14 means replaying commits zero through fourteen, resolving which Parquet files were live at that point, and scanning only those. Periodic checkpoint files collapse the replay so the log does not get slower as it grows.
The Two Things a Historical Read Needs This is the part most walkthroughs skip. A time travel query succeeds only when both halves survive, the log entry describing the version and the physical files that version references.
Lose the log entry and Fabric no longer knows what version 14 contained. Lose the Parquet files and Fabric knows exactly what it needs and cannot find it. The two halves are governed by two separate retention settings, which is why teams are surprised by the result.
Metadata without files is a catalogue of a warehouse that has already been emptied.
Setting Up a Lakehouse Table You Can Time Travel Through Every query below runs against one small table, so you can reproduce the whole sequence in a Fabric notebook attached to any Lakehouse. Create it first, in a cell set to Spark SQL with %%sql.
%%sql
CREATE TABLE IF NOT EXISTS sales_delta (
order_id INT,
product STRING,
quantity INT,
unit_price DECIMAL(10,2),
order_date DATE
) USING DELTA;
INSERT INTO sales_delta VALUES
(1, 'Widget A', 1, 24.00, DATE'2026-08-01'),
(2, 'Widget B', 3, 18.50, DATE'2026-08-01'),
(3, 'Widget A', 1, 24.00, DATE'2026-08-02'),
(4, 'Widget C', 5, 11.25, DATE'2026-08-03');Record the baseline before changing anything, because every later query is compared against it.
%%sql
SELECT SUM(quantity) AS total_quantity,
SUM(quantity * unit_price) AS gross_value
FROM sales_delta;
-- total_quantity = 10, gross_value = 158.25Now create a second version on purpose, the way a bad pipeline run would.
%%sql
UPDATE sales_delta
SET quantity = 5
WHERE quantity = 1;
-- gross_value is now 254.25, and the table is at version 2Nothing was lost. The table simply has two states now, and both are addressable.
Reading Table History with DESCRIBE HISTORY Before querying the past, find out what the past contains. DESCRIBE HISTORY returns one row per commit, newest first.
%%sql
DESCRIBE HISTORY sales_delta;The PySpark equivalent returns the same rows as a DataFrame, which is easier to filter inside a scheduled job.
from delta.tables import DeltaTable
dt = DeltaTable.forName(spark, "sales_delta")
display(dt.history().select("version", "timestamp", "operation", "operationMetrics"))Four columns carry most of the diagnostic value.
Table 1: What to read in a DESCRIBE HISTORY result
Column What it tells you Why it matters in an incident versionThe commit number, starting at 0 The value you pass to VERSION AS OF, and the most reliable handle timestampWhen the commit landed, in UTC Lets you match a version to a pipeline run or an alert operationWRITE, MERGE, DELETE, RESTORE, OPTIMIZE, VACUUM START and so on A VACUUM entry is your warning that older versions may already be gone operationMetricsRows and files touched by that commit A merge that rewrote far more rows than expected shows up here first
Teams running scheduled jobs often log the top row of this output after every load, which turns an unexplained number into a five-minute investigation later.
Querying a Previous Version with VERSION AS OF and TIMESTAMP AS OF Two forms exist, and they resolve to the same snapshot. Version numbers are exact, timestamps are convenient.
Spark SQL %%sql
-- the baseline, before the bad update
SELECT SUM(quantity) AS total_quantity,
SUM(quantity * unit_price) AS gross_value
FROM sales_delta VERSION AS OF 1;
-- the same read by wall-clock time
SELECT *
FROM sales_delta TIMESTAMP AS OF '2026-09-24 22:15:00';PySpark df_v1 = (spark.read.format("delta")
.option("versionAsOf", 1)
.table("sales_delta"))
df_ts = (spark.read.format("delta")
.option("timestampAsOf", "2026-09-24 22:15:00")
.table("sales_delta"))
print(df_v1.count(), df_ts.count())Prefer the version number in any automated job. A timestamp that falls before the table existed, or inside a gap the log no longer covers, fails at runtime. A version number either resolves or tells you immediately that it cannot.
Comparing Two Versions of the Same Table A diff between two versions beats a single historical read. EXCEPT gives you the rows that changed between two states in one query.
%%sql
-- rows that exist now but did not exist at version 1
SELECT * FROM sales_delta VERSION AS OF 2
EXCEPT
SELECT * FROM sales_delta VERSION AS OF 1;
-- and the reverse, rows the update removed or rewrote
SELECT * FROM sales_delta VERSION AS OF 1
EXCEPT
SELECT * FROM sales_delta VERSION AS OF 2;Run both directions. The first tells you what arrived, the second tells you what disappeared, and together they scope an incident far faster than comparing two aggregate numbers.
Restoring a Delta Table with RESTORE Once a version has been validated by reading it, RESTORE promotes it to the current state.
%%sql
RESTORE TABLE sales_delta TO VERSION AS OF 1;
-- or by time
RESTORE TABLE sales_delta TO TIMESTAMP AS OF '2026-09-24 22:15:00';from delta.tables import DeltaTable
dt = DeltaTable.forName(spark, "sales_delta")
dt.restoreToVersion(1)Delta does not rewind the log. It writes a new version that points back at the older set of files. The restore itself appears in DESCRIBE HISTORY as its own commit, and the files that were current before the restore become unreferenced without being deleted.
Microsoft’s restore documentation states the consequence directly, noting that VACUUM can prevent a future restore once it has removed the files a target version needs. Read the version first, restore second, and clean up third.
How Long Microsoft Fabric Time Travel History Actually Lasts This is where most production surprises originate. Microsoft Fabric time travel is bounded by two independent table properties, and the shorter of the two wins.
Table 2: The two retention settings behind Fabric Lakehouse time travel
Setting What it controls Default What happens when it expires delta.logRetentionDurationHow long transaction log entries are kept 30 days The version stops appearing in table history at all delta.deletedFileRetentionDurationThe shortest time logically deleted data files are kept before physical removal 1 week VACUUM becomes free to delete the files, and the version becomes unreadable VACUUM retention threshold The age cut-off applied when the command actually runs 7 days Removal is permanent, and Fabric blocks values under seven days by default
Microsoft’s Delta table property reference is blunt about the interaction, stating that VACUUM operations override the log retention threshold . Raising log retention to 90 days on its own buys you a longer catalogue and not one extra day of readable history.
Change both together, and change them deliberately.
%%sql
ALTER TABLE sales_delta SET TBLPROPERTIES (
'delta.logRetentionDuration' = 'interval 90 days',
'delta.deletedFileRetentionDuration' = 'interval 90 days'
);
-- confirm what is actually set on the table
SHOW TBLPROPERTIES sales_delta;Longer file retention costs OneLake storage, because every superseded Parquet file stays billable for the whole window. Pick the number from an audit or recovery requirement, and write it down next to the table definition.
VACUUM and the Day Your History Disappears VACUUM is the single command most likely to end a recovery attempt before it starts. It is usually run by someone trying to be helpful about storage costs.
What VACUUM Removes VACUUM deletes files in the table folder that the current version no longer references and that are older than the retention threshold. Current data is untouched, which is why the command feels safe.
Microsoft’s own wording on the time travel page is worth quoting, because it names the exact failure mode. If VACUUM removes the files an older version needs, “that older version becomes unqueryable even if the version still appears in table history”.
The symptom is a version listed in DESCRIBE HISTORY that throws a file-not-found error when you query it. Nothing warns you in advance.
The Seven Day Floor and How Fabric Enforces It Fabric will not let you casually shorten the window. The Delta table maintenance documentation states that portal and API maintenance requests fail by default for retention intervals under seven days .
Overriding that guard happens at the environment level. It means setting spark.databricks.delta.retentionDurationCheck.enabled to false in the Spark properties of the Fabric environment your workloads attach to, which affects every table those workloads touch.
%%sql
-- see what would be deleted, without deleting anything
VACUUM sales_delta RETAIN 168 HOURS DRY RUN;
-- the real thing, at the documented default
VACUUM sales_delta RETAIN 168 HOURS;Before You Run VACUUM Run DESCRIBE HISTORY and note the oldest version anyone still depends on. Run the command with DRY RUN first and read the file list it returns. Check whether an audit, a regulator or a data science reproducibility requirement pins a longer window. Confirm no Direct Lake semantic model or downstream job is mid-refresh against the table. If you need a version permanently, copy it out with CREATE TABLE ... AS SELECT before you clean up. Checklist
Microsoft Fabric Production Readiness
Retention and maintenance are two of the items teams skip when a Fabric workspace goes live. This checklist walks the rest of them.
Get the Checklist →
Automatic Table Maintenance in Fabric and Your History Window Fabric ships maintenance as a first-class feature, and that is where a lot of unplanned VACUUM activity comes from. You can trigger it from the Lakehouse explorer’s Maintenance dialog. You can also schedule it through notebooks, the REST API, or the Lakehouse Maintenance activity in a Data Factory pipeline.
The dialog offers OPTIMIZE with optional V-Order, and a separate VACUUM toggle. Both are useful and neither is free. Microsoft notes that V-Order carries roughly a 15 percent impact on average write times while providing up to 50 percent more compression.
The governance problem is ownership. A platform engineer schedules maintenance for file-size health. An analytics engineer assumes history goes back a month. The two assumptions only meet during an incident. Decide the retention number first, then schedule maintenance to respect it, and record both in the same runbook.
Time Travel from the SQL Analytics Endpoint and Fabric Warehouse Two of the pages currently ranking for this topic still say time travel is unavailable from the Lakehouse SQL analytics endpoint. That was true when they were written and it is out of date now.
Microsoft’s current documentation lists the SQL analytics endpoint among the places time travel works, in preview, and the Warehouse page carries the T-SQL syntax. Queries use a hint in the OPTION clause instead of Delta’s AS OF form.
SELECT SUM(quantity) AS total_quantity,
SUM(quantity * unit_price) AS gross_value
FROM dbo.sales_delta
OPTION (FOR TIMESTAMP AS OF '2026-09-24T22:15:00.000');The constraints are real, and all of them are documented. The hint works only in statements that begin with SELECT, and only once per statement. It reads timestamps in UTC only, with at most three digits of fractional seconds. View definitions cannot contain it, and the syntax is not supported in Power BI Desktop DirectQuery mode or the Explore This Data option.
One more gate catches people out. Time travel for SQL analytics endpoints is only enabled for endpoints created with New metadata sync , which is itself in preview.
Table 3: Where each time travel surface works
Capability Fabric notebook (Spark) Lakehouse SQL analytics endpoint Fabric Warehouse Query an old version by number Yes, VERSION AS OF No, timestamp only No, timestamp only Query by timestamp Yes, TIMESTAMP AS OF Yes, OPTION (FOR TIMESTAMP AS OF), preview Yes, OPTION (FOR TIMESTAMP AS OF) Inspect version history Yes, DESCRIBE HISTORY No No Roll the table back Yes, RESTORE No Restore points, at warehouse level Maintenance commands Yes, OPTIMIZE and VACUUM No Managed by the service What limits the window Delta table properties and VACUUM Lakehouse vacuum retention settings Warehouse retention, 30 days by default, configurable 1 to 120
The retention asymmetry is worth pausing on. A Fabric Warehouse manages its own window and keeps 30 calendar days by default. A Lakehouse table keeps whatever you and your maintenance schedule decide. Teams that model both in one workspace should not assume a single number covers both. The Fabric Data Warehouse side behaves differently in several other respects too.
Kanerika Service
Microsoft Fabric Engineering
Kanerika is a Microsoft Solutions Partner for Data and AI and designs Fabric Lakehouse architecture, pipelines and retention policy as one piece of work.
Explore Fabric Services →
Fabric Lakehouse Backup and Recovery Options Compared Searchers reach this topic asking about Fabric Lakehouse backup, and they deserve a straight answer. Delta time travel is version history inside one table, with a window measured in days, and it disappears when maintenance runs. A backup strategy has to assume all three of those things.
Fabric gives you four distinct recovery mechanisms, and they do not overlap as much as their names suggest.
Table 4: Recovery mechanisms in Microsoft Fabric
Mechanism Scope Typical window Recovers you from Delta time travel and RESTORE One Lakehouse table Bounded by VACUUM, 7 days by default A bad write, merge or delete inside the table Warehouse time travel Warehouse tables, read only 30 calendar days, configurable 1 to 120 Reporting against a prior point in time Warehouse restore in place A whole warehouse System and user restore points A bad deployment or schema change across many tables OneLake soft delete Files in OneLake storage 7 days, not configurable Someone deleting files or a folder outright
OneLake soft delete is the one most teams have never used. It retains deleted files for seven days before permanent removal. Recovery runs through Azure Storage Explorer, Azure PowerShell or the Storage REST APIs , not through anything in the Fabric portal. After seven days they are gone.
Long-horizon requirements sit outside all four. Monthly regulatory snapshots, model training sets that must stay reproducible next year, and anything a legal hold might touch belong in an independent copy. Write it on a schedule and govern it like any other table. Readers arriving from other platforms will recognise the shape of the problem from Snowflake Time Travel . It has the same finite window and the same need for a separate archive. The wider category of data versioning tools exists precisely because table history alone rarely satisfies an auditor.
Listen on Spotify
What Happens When Banks Get Data Migration Wrong?
Schema Changes and What They Do to Older Versions Adding a column does not retroactively add it to history. Version 1 was written with four columns and it still has four columns. A query against it cannot return a column that arrived at version 5.
The Warehouse documentation states the rule in its strictest form. A time-travel query to a point before a schema change “succeeds only when it references columns that already existed at that point in time, and fails if it references columns introduced later”. The same care applies on the Spark side whenever downstream code selects columns explicitly.
Two operations are more destructive than they look. Dropping and recreating a table with the same name removes its history entirely. An overwrite that changes column types can leave older versions readable in principle and useless in practice. Treat both as schema events that need the same review as a production deployment.
Why a Microsoft Fabric Time Travel Query Fails and How to Fix It Four symptoms cover most support tickets on this feature.
The version is listed in history but the query errors. Files for that version have been removed, almost always by VACUUM or by scheduled table maintenance. Check DESCRIBE HISTORY for a VACUUM entry and pick the oldest version that postdates it.
A timestamp query fails while a version query works. The timestamp falls outside the range the log covers, or it is being read in the wrong time zone. Time travel resolves timestamps in UTC, so convert before you query.
The T-SQL hint returns a conversion error. Fabric accepts at most three digits of fractional seconds in the timestamp literal and returns a specific message when you supply more. Trim the precision to the yyyy-MM-ddTHH:mm:ss[.fff] shape.
A Power BI report cannot see the older data. Direct Lake semantic models read the current table state, and the T-SQL time travel hint is not supported in Power BI Desktop DirectQuery mode. Materialise the historical snapshot into its own table and point the model at that.
Production Practices for Fabric Lakehouse Time Travel The teams who never lose a recovery window treat retention as a design decision rather than a default. A small number of habits do most of the work.
Set retention per table, by workload. A staging table loaded hourly rarely needs more than seven days. A finance fact table feeding a quarterly close needs enough history to reopen the quarter.Log the version number after every pipeline run. One extra row in a control table turns a vague incident into a precise VERSION AS OF.Read before you restore. Validate the target version with a query and a row count, then promote it.Own maintenance schedules centrally. Whoever schedules VACUUM should be able to name the longest retention requirement in the workspace, the same way an analytics team owns a refresh window.Write real copies for long horizons. Anything measured in months belongs in its own table.Rehearse a restore. Test the path on a clone before you need it under pressure, the same way you would test any other recovery procedure.These habits sit inside a broader lakehouse architecture discipline. It is the same reasoning that keeps raw, curated and serving layers apart instead of letting one table carry every responsibility. Work through the mechanics in a notebook first, using T-SQL notebooks in Microsoft Fabric or a Spark notebook, before wiring anything into a schedule.
How Kanerika Builds Fabric Lakehouses That Stay Recoverable Kanerika is a Microsoft Solutions Partner for Data and AI with the Analytics specialization. It also holds the Microsoft Advanced Specialization for Data Warehouse Migration to Microsoft Azure, earned in December 2025. Amit Chandak, Kanerika’s Chief Analytics Officer, is a Microsoft MVP for Power BI. That work is mostly unglamorous, and recovery design is a large part of it.
On a Fabric Lakehouse build, the retention question gets answered in four stages, starting on day one.
Assess. Catalogue every table by the recovery requirement behind it, separating operational tables from anything an auditor or a model reproducibility rule touches.Design. Set logRetentionDuration and deletedFileRetentionDuration per table class, and price the OneLake storage that longer windows consume before committing to them.Build. Put maintenance on a schedule that respects the longest window in the workspace. Write the version number of each load into a control table so an incident starts with a fact.Operate. Rehearse restores on clones, review retention when a new regulated workload lands, and keep long-horizon snapshots as real tables.The payoff is measurable in fewer bad numbers reaching a report. Take a Fabric Lakehouse consolidation for a US pharmaceutical manufacturer with 500 plus SKUs and operations in 55 plus countries. Model N, SQL Server, SAP and SAP Vistex data went into one governed lakehouse. Data-related errors fell by 78 percent and data processing speed rose by 41 percent.
Case Study
78% Fewer Data Errors for Pharma with Microsoft Fabric
A US pharmaceutical manufacturer had data split across Model N, SQL Server, SAP and SAP Vistex. Kanerika consolidated it into one governed Fabric Lakehouse and cut data-related errors by 78 percent.
Read the Case Study →
Kanerika’s data engineering and Microsoft Fabric teams handle the architecture, the pipelines and the ongoing maintenance policy together. That is the only way a retention number set on day one survives the first year. For teams arriving from an older stack, the same discipline is built into an Azure to Fabric migration from the start.
Wrapping Up Microsoft Fabric time travel in Lakehouse is a strong recovery and audit tool with a short memory. The syntax takes five minutes to learn. What decides whether it helps you during an incident is retention, set per table and respected by whatever schedules your maintenance.
Treat DESCRIBE HISTORY as the first command in any data incident. Keep VACUUM under the same change control as a deployment, and write real copies for anything you need in months. Do that, and a pipeline that ran twice becomes a ten-minute fix instead of a reconciliation project.
Frequently Asked Questions
Does Microsoft Fabric have time travel? Yes. A Fabric Lakehouse gets time travel from Delta Lake. You read any earlier version of a table with VERSION AS OF or TIMESTAMP AS OF in a notebook. Fabric Warehouse and the SQL analytics endpoint offer a separate T-SQL form of the same idea through a query hint. Both surfaces are read-only and neither one changes the table.
How do I query a previous version of a Delta table in Fabric? Run DESCRIBE HISTORY on the table first to see which versions exist and when each one was committed. Then read the version you want with SELECT * FROM table_name VERSION AS OF 5, or use TIMESTAMP AS OF with a UTC timestamp. In PySpark the same read uses the versionAsOf or timestampAsOf option.
How does schema evolution affect Delta table time travel? An older version keeps the schema it was written with. A column added at version 5 does not appear when you read version 1. A query that names that column against an earlier point in time fails. Dropping a table and recreating it with the same name removes its history entirely, so treat that as a schema event.
Why does my Fabric time travel query fail when the version is listed? The commit metadata survived and the data files did not. VACUUM or scheduled table maintenance removed the Parquet files that version pointed at. Delta knows exactly what it needs and cannot find it. Check DESCRIBE HISTORY for a VACUUM entry, then read the oldest version that was committed after that entry.
Is Fabric Lakehouse time travel the same as Fabric Warehouse time travel? Both answer the same question through different mechanisms. A Lakehouse reads Delta versions through Spark, with a window you control through table properties and VACUUM. A Warehouse manages retention itself, keeping 30 calendar days by default and configurable from 1 to 120 days, and queries it with a T-SQL hint.
What is Microsoft Fabric? Microsoft Fabric is a unified analytics platform. It brings data engineering, data science, real-time intelligence, warehousing and Power BI into one SaaS product. Everything is stored in OneLake using the open Delta Parquet format. Every workload reads the same copy of the data without moving or duplicating it, which is what keeps the platform coherent.
Is Microsoft Fabric an ETL tool? Fabric includes ETL capability without being only an ETL tool. Data Factory inside Fabric runs pipelines and Dataflows Gen2 handles low-code transformation. Notebooks cover heavier Spark work such as merges and incremental loads. Those capabilities sit alongside warehousing, real-time intelligence, data science and Power BI in the same platform, on the same OneLake storage layer.
How expensive is Microsoft Fabric? Fabric uses capacity-based pricing measured in Capacity Units, available pay-as-you-go or reserved. Cost depends on workload intensity, data volume and how much compute each workload consumes. Entry-level F2 capacity suits small teams and larger deployments scale up from there. Storage in OneLake is billed separately from compute capacity, so model both.
Is Microsoft Fabric a PaaS or SaaS? Fabric is a SaaS platform. Microsoft handles infrastructure, scaling, patching and updates for you. Users work through one web experience, with no clusters to provision and no servers to manage. PaaS analytics services such as Azure Synapse work differently, because there the customer configures and operates far more of the underlying stack.
Is Microsoft Fabric considered AI? Fabric is a data platform with AI capability built into it. Copilot in Fabric helps generate code and transformations from plain language. Fabric Data Agents answer questions against governed data, and the Data Science workload supports model building and deployment. The platform itself is analytics infrastructure that AI workloads run on.
What is Microsoft Fabric used for? Teams use Fabric for end-to-end analytics, covering ingestion, engineering, warehousing, real-time processing and business intelligence. It replaces a stack of separate tools with one platform and one storage layer. That reduces integration work and licensing overhead. Common uses include finance reporting, supply chain visibility and operational dashboards across plants and regions.
Is Microsoft Fabric the same as Snowflake? No. Snowflake is a cloud data platform centred on SQL analytics, data sharing and elastic compute. Fabric is a broader SaaS suite covering engineering, real-time analytics, data science and Power BI on shared OneLake storage. Many enterprises run both and connect them through the open Delta and Iceberg table formats.
How long does a Fabric Lakehouse keep Delta table history? Two settings decide it. The property delta.logRetentionDuration keeps transaction log entries for 30 days by default. VACUUM removes unreferenced data files older than seven days by default. Whichever window expires first sets the real limit, so most tables stay readable for about a week. Raise both numbers together to extend that.
Is Microsoft Fabric the same as Databricks? They overlap without being the same. Both use Delta Lake and a lakehouse pattern, and both support time travel on Delta tables. Databricks is stronger on advanced Spark engineering and machine learning at scale. Fabric packages analytics, warehousing and Power BI into one SaaS experience with simpler licensing and less infrastructure work.
Is Microsoft Fabric better than Azure? Fabric runs on Azure infrastructure. It is a SaaS analytics platform that consolidates services such as Synapse Analytics, Data Factory and Power BI into one experience with simpler licensing. Azure gives you granular control over each individual service. Most enterprises use both, with Fabric as the analytics layer on top.
Is Microsoft Fabric a replacement for Synapse? Fabric absorbs Synapse capability and is where Microsoft is investing. Warehousing, Spark pools and pipelines all appear inside Fabric with added functionality, and new features land there first. Synapse remains supported for existing workloads. Migration is therefore a planning exercise for most teams rather than an emergency that needs handling this quarter.
Is Microsoft Fabric real-time? Yes, through the Real-Time Intelligence workload. Eventstreams ingest from sources such as Azure Event Hubs, IoT devices and Kafka. Eventhouse and KQL databases serve sub-second queries over streaming data. Real-time dashboards and Activator rules turn those streams into alerts and automated actions, without standing up a separate streaming platform alongside Fabric.
What is the difference between a data lake and a data lakehouse? A data lake stores raw files at scale with no schema enforcement and no transactional guarantees. A lakehouse adds ACID transactions, schema enforcement, governance and versioning on top of that same cheap storage. Fabric implements the lakehouse pattern with Delta tables in OneLake, which is what makes time travel possible.
Is Microsoft Fabric the future of Microsoft analytics? It is clearly the direction Microsoft is investing in. New capability lands in Fabric first, and Copilot and agent features are built into it. The OneLake storage model underpins the rest of the Microsoft data stack. Existing Synapse and standalone Power BI deployments remain supported while teams plan a move at their own pace.
Does VACUUM delete Delta Lake time travel history? It deletes the data files that older versions depend on. The version still appears in DESCRIBE HISTORY afterwards, which makes the loss easy to miss, but the query fails because the Parquet files are gone. Run VACUUM with DRY RUN first and confirm nobody needs the versions it would strip.
What is the default retention period for Delta Lake time travel in Fabric? Transaction log entries are kept for 30 days by default through delta.logRetentionDuration. Data files are kept for one week by default through delta.deletedFileRetentionDuration. The VACUUM retention threshold is also seven days. Fabric portal and API maintenance requests fail by default when the retention interval drops under seven days, which is a deliberate guard.
What is the difference between Delta Lake time travel and a backup? Time travel reads earlier versions of one table inside a short retention window, and it disappears when maintenance cleans up old files. A backup is an independent copy that survives whatever happens to the source. Long horizon needs such as audits and model reproducibility belong in a copy written on a schedule.
Can I use time travel from the Fabric SQL analytics endpoint? Yes, in preview. Microsoft lists the SQL analytics endpoint as a supported surface. The syntax is a T-SQL hint written as OPTION (FOR TIMESTAMP AS OF). The window is bounded by Lakehouse vacuum retention settings. The feature is only enabled for endpoints created with New metadata sync, which is itself still in preview.
How do I restore a previous Delta table version in Microsoft Fabric? Use RESTORE TABLE table_name TO VERSION AS OF 5, or TO TIMESTAMP AS OF with a UTC timestamp. Delta writes a new version pointing back at the older files rather than rewinding the log, so the restore shows up in table history. Read the target version first to confirm it holds what you expect.
What happens if I run VACUUM on a Fabric Lakehouse table? Files that the current version no longer references and that are older than the retention threshold are deleted permanently. Current data is untouched and queries against the latest version keep working. Any older version that relied on the deleted files becomes unreadable, even though it still shows in DESCRIBE HISTORY.
Can Power BI read historical versions of Fabric Lakehouse tables? Not directly. Direct Lake semantic models read the current state of the table. The T-SQL time travel hint is not supported in Power BI Desktop DirectQuery mode or the Explore This Data option. Write the historical snapshot into its own table with CREATE TABLE AS SELECT, then point the semantic model at that table.
