A warehouse snapshot is a read-only copy of your data taken at a specific moment. It is kept for up to 30 days. You can move the snapshot forward in time whenever needed. This lets users keep using the same connection while seeing an earlier version of the data. When you advance the snapshot, new changes from the main warehouse are added instantly and safely in one step.Snapshots are especially helpful if an ETL process causes data problems. They provide a safe, fixed version of the data that stays protected from changes or errors in the main warehouse.
Let’s look at a simple example to illustrate how it works. Suppose we have a single warehouse that contains two or more tables, and these tables are updated quite frequently:
When a snapshot is created, any client tool that connects to it will return exactly the same data as was present in the parent warehouse at the time of creation.
The colored frames represent the rows returned by the snapshot and the warehouse: the orange frames show the snapshot data, while the black frames show the warehouse data.
Data in the original warehouse can change in many ways: rows can be deleted, updated, or new rows can be inserted. When you query the warehouse, it returns the current state, reflecting all recent operations. A snapshot, however, returns the data exactly as it existed at a specific point in time—the moment the snapshot was created.
You can see this difference in the images below:
A snapshot does not always have to return data from the past. When needed, you can advance (or “roll forward”) the snapshot to reflect the current state of the warehouse.
This capability is especially useful when you want to provide reading clients with consistent data. Without snapshots, it is possible that one table has been fully loaded while another has not, resulting in inconsistent query results. With snapshots, this problem is avoided because the data remains consistent at the chosen point in time.
It looks simple, doesn’t it? Let’s examine an example in the Fabric environment. I have created a warehouse and inserted some dummy data into a Sales table. Wehn we query the table it returns 10 rows as expected:
CREATE TABLE Sales (
SalesID BIGINT IDENTITY,
ProductID BIGINT NOT NULL,
CustomerID BIGINT NOT NULL,
SalesDate DATE NOT NULL,
Quantity INT NOT NULL,
UnitPrice DECIMAL(18, 2) NOT NULL,
TotalAmount DECIMAL(18, 2) NOT NULL,
SalesRegion VARCHAR(100) NOT NULL
);
INSERT INTO Sales (ProductID, CustomerID, SalesDate, Quantity, UnitPrice, TotalAmount, SalesRegion)
VALUES
(101, 1001, '2026-01-15', 5, 29.99, 149.95, 'North America'),
(102, 1002, '2026-01-18', 3, 49.99, 149.97, 'Europe'),
(103, 1003, '2026-01-20', 2, 89.99, 179.98, 'Asia Pacific'),
(104, 1004, '2026-01-22', 10, 15.99, 159.90, 'North America'),
(105, 1005, '2026-01-25', 1, 199.99, 199.99, 'Europe'),
(106, 1006, '2026-01-28', 4, 39.99, 159.96, 'Asia Pacific'),
(107, 1007, '2026-02-01', 6, 24.99, 149.94, 'North America'),
(108, 1008, '2026-02-03', 2, 79.99, 159.98, 'Europe'),
(109, 1009, '2026-02-04', 8, 19.99, 159.92, 'Asia Pacific'),
(110, 1010, '2026-02-05', 3, 59.99, 179.97, 'North America');
SELECT COUNT(*) FROM Sales;
Now, let us create a snapshot. The easiest method is to use the graphical interface. The option to create a snapshot is located in the Warehouse section under Management > New Warehouse Snapshot.
The creation process is straightforward: provide a name for the snapshot and select the point in time it should reflect. You can choose any point in time from the past 30 days, for our purpose I choose “Current”:
If you prefer to create a snapshot programmatically, you can use a simple REST API. This method requires you to provide details such as the workspace ID, warehouse ID, and other relevant parameters, similar to those used in the graphical interface.
I recommend this approach because it allows you to automate snapshot creation and easily track all changes made to the snapshots over time.
POST https://api.fabric.microsoft.com/v1/workspaces/<workspace ID>/items
Authorization: Bearer <bearer token>
Content-Type: application/json
{
"type": "WarehouseSnapshot",
"displayName": "<snapshot item display name>",
"description": "<helpful description of snapshot item>",
"creationPayload": {
"parentWarehouseId": "<parent warehouse ID>",
"snapshotDateTime": "<YYYY-MM-DDTHH:SS:SSZ>" //Enter UTC time
}
}
To query a snapshot, you can connect directly to it or use the three-level namespace format: <snapshot_name>.<schema>.<table>
Either method will return the data from the snapshot. As shown below, the query returns the same number of rows as the parent warehouse.
SELECT COUNT(*) FROM dwh_reading_endpoint.dbo.Sales
Snapshot metadata is, of course, available in the standard metadata views. As shown in the screenshot below, you can also view snapshots directly in the workspace interface, where they appear as a subresource of the parent warehouse.
A list of snapshots is also available when you open the warehouse and navigate to the Management tab:
When you open a snapshot directly from the workspace view, you can query it without using the three-level namespace approach.
You can also obtain the direct connection string for the snapshot by opening its settings window.
Now, let us test whether the snapshot returns the original (older) data. First, insert 10 additional rows into the warehouse.
INSERT INTO Sales (ProductID, CustomerID, SalesDate, Quantity, UnitPrice, TotalAmount, SalesRegion)
VALUES
(101, 1001, '2026-01-15', 5, 29.99, 149.95, 'North America'),
(102, 1002, '2026-01-18', 3, 49.99, 149.97, 'Europe'),
(103, 1003, '2026-01-20', 2, 89.99, 179.98, 'Asia Pacific'),
(104, 1004, '2026-01-22', 10, 15.99, 159.90, 'North America'),
(105, 1005, '2026-01-25', 1, 199.99, 199.99, 'Europe'),
(106, 1006, '2026-01-28', 4, 39.99, 159.96, 'Asia Pacific'),
(107, 1007, '2026-02-01', 6, 24.99, 149.94, 'North America'),
(108, 1008, '2026-02-03', 2, 79.99, 159.98, 'Europe'),
(109, 1009, '2026-02-04', 8, 19.99, 159.92, 'Asia Pacific'),
(110, 1010, '2026-02-05', 3, 59.99, 179.97, 'North America');
When we query both the snapshot and the parent warehouse, the snapshot still returns 10 rows, while the warehouse returns 20 rows, reflecting the current state of the table. This demonstrates that the snapshot functions exactly as intended.
It is worth noting here that a snapshot is not a full physical copy of the table. Instead, it leverages the Delta Lake format efficiently to provide this point-in-time view. Multiple snapshots can be created if required. The only limitation is that each snapshot must reflect a state of the warehouse from within the last 30 days.
Let us now advance the snapshot to reflect the current state of the data. This can be accomplished easily using the following ALTER DATABASE statement:
ALTER DATABASE dwh_reading_endpoint SET TIMESTAMP = CURRENT_TIMESTAMP
The same result can also be achieved through the graphical user interface. Under the Management tab, select the option “Capture New State” to advance the snapshot to a different timestamp. It is also worth noting that snapshots can be advanced to any desired timestamp within the supported retention period.
Now, both the warehouse and the snapshot return the same state and the same data.
In summary, warehouse snapshots provide a reliable, low-overhead solution for ensuring data consistency, protecting analytical workloads from transient ETL inconsistencies, enabling reproducible reporting, and supporting use cases that require historical or stable views of rapidly changing warehouse data.
- Recovering dropped tables in Azure Databricks with UNDROP TABLE - February 26, 2026
- Microsoft Fabric Warehouse Snapshots – How to use it? - February 8, 2026
- Microsoft Fabric Delta Lake Partition Pruning - January 6, 2026





















Last comments