Blog Post

Fabric Updates Blog
4 MIN READ

Configurable Data Retention in Microsoft Fabric Warehouse (Preview)

ajagadish's avatar
ajagadish
Icon for Microsoft Employee rankMicrosoft Employee
4 months ago

Author: Ambika Jagadish, Senior Product Manager

A broken ETL pipeline quietly corrupts weeks of data over the weekend. Your dashboards are telling the wrong story. In the old world, that's a fire drill — hours of rebuilding and re-ingesting.

In Fabric Warehouse, you will be able to recover from a prior point in time.

Configurable Data Retention (Preview) empowers you to define exactly how far back you can time travel and recover your warehouse.

Delta: The silent engine behind every change

Leveraging Delta, Fabric Warehouse has always silently preserved historical versions of your data. Every insert, update, and delete doesn't overwrite the past. Instead, Delta appends new Parquet files and records each transaction as a commit in its Delta transaction log, giving your data a living memory. This versioning superpower quietly drives some of Fabric Warehouse's most powerful capabilities — time travel queries, point-in-time clones, restore points, and warehouse snapshots — all without duplicating a single byte of storage.

The challenge with "one size fits all"

The historical window was always set to 30 days, applied uniformly across all warehouses without exception.

That forced developer and test teams to pay for history they never needed. It left compliance teams without the longer audit trail their regulators demanded. And it gave engineering teams zero flexibility to align their recovery window with their actual deployment cycles. One retention period. Three very different problems.

Configurable retention in Fabric Warehouse

Starting today, you can configure your Fabric Warehouse data history retention to any value between 1 and 120 days — warehouse by warehouse, with a single T-SQL command.

Configure data retention through T-SQL

No restarts, migrations, or support tickets are required—the moment they run, the warehouse updates automatically to match.

What configurable retention unlocks

The configured retention period isn't just a number. It's the boundary that governs everything Fabric Warehouse can do for you when things go wrong — or when you simply want to look back.

Time travel

Time travel lets you query your data as it existed at any past timestamp within your retention window — perfect for stable reporting while ETL pipelines are still running in the background.

Point-in-time clones

Point-in-time clones let you instantly clone a table as of any moment within your configured retention window — zero data duplication, just a lightweight metadata operation. Whether you're troubleshooting a broken pipeline, safely testing new transformations without touching production, or preserving a historical snapshot for long-term retention at virtually no storage cost, clones give you the flexibility to work with your data the way your business demands.

Restore points

Restore points are auto created by the system every eight hours and scaled proportionally to your retention period, so you always have enough recovery options available.

Warehouse snapshots

Warehouse snapshots capture a consistent, read-only view of your warehouse — and the longer your retention, the more snapshot history you must work with.

Who this is for

If you run dev or test warehouses, drop your retention to a ‘lower’ number of days. You don't need a month of change history for an environment you reset every sprint.

If you work in a regulated industry — healthcare, finance, insurance — extend your retention up to 120 days. Query historical data, trace lineage, satisfy auditors, all from within Fabric. No external archival tooling required.

If you ship data transformations on a release cadence, align your retention to your deployment window. Know that if a bad transformation slips through on Friday, you have exactly the rollback window your team needs — not more, not less.

One thing to know

Reducing retention is a one-way door.

When you lower your retention period, historical data outside the new window is permanently cleaned up by Fabric's managed Garbage Collector. Increasing retention afterward will not recover what was deleted — new history simply starts accumulating from that point forward.

Longer retention provides a reliable buffer, helping ensure historical data remains available when needed.

Dropped retention

When the unexpected happens — a warehouse is accidentally dropped — Fabric has you covered. It's important to note that Data Retention and Dropped Retention are two distinct, independent capabilities. Data Retention governs how long historical versions of your warehouse data are preserved — powering time travel queries, restore points, clones, and snapshots. Dropped Retention on the other hand, is the safety net that kicks in the moment a warehouse is deleted — preserving the entire warehouse for a configurable grace period before it is permanently removed. By default, Fabric retains a dropped warehouse for seven calendar days, and this window is fully configurable between 7 to 90 days to match your recovery and compliance needs. Together, these two capabilities form a complete data resilience story — one protects your data while your warehouse is live, the other protects it even after it's gone.

The future of data resilience starts here

Configurable retention is not just a number. It's a promise that you can leverage the data history retention that you pay for. Whether you're trimming costs in a dev environment, satisfying an auditor, or racing to roll back a Friday night deployment gone wrong — you are now in control.

Try configurable retention this capability was developed in response to customer feedback, please leave us feedback to let us know how this feature is working for you.

Updated 4 months ago
Version 1.0

2 Comments

  • How is Configurable Data Retention handled in git-enabled workspaces (is the value written to a text file in the git representation?), and when using Fabric Deployment Pipelines?

    If I have configured a DEV warehouse to have 5 days retention, then I deploy this warehouse to a separate PROD workspace using a deployment pipeline - will the PROD warehouse get the same 5-day retention setting, even if it previously existed in PROD with 120-day retention?

  • What would be nice is to be able to set retention per table (like in Snowflake).
    For example, dimension / fact tables might have 30 or higher, but staging tables that are truncated each day only need 0 or 1 day of retention.