--- title: "DuckLake Time Travel & Schema Evolution Explained | MotherDuck" description: "Learn how DuckLake time travel, schema evolution, and the change feed work: query any snapshot, undo bad writes, and evolve tables without rewrites." canonical: "https://motherduck.com/videos/ducklake-time-travel-schema-evolution/" --- [BACK TO VIDEOS](/videos/) [Stream](/videos/?category=Stream#videos-and-webinars-library)[SQL](/videos/?category=SQL#videos-and-webinars-library)[Ecosystem](/videos/?category=Ecosystem#videos-and-webinars-library) # Time Travel & Schema Evolution: DuckLake Handles Change 2026/09/03 > **TL;DR:** Alex Monahan, co-author of the O'Reilly DuckLake book, and Hoyt Emerson of Early Signal work through chapter 4 live: time travel with the `AT` clause, what snapshots actually cost, schema evolution without rewriting data, and the row-level change feed. ## Time travel is an undo button for data Any DuckLake table accepts an `AT` clause in the `FROM`: pass a timestamp or a snapshot ID and you're querying the table as it was. It works per table, so you can anti-join yesterday's table against today's to see what changed, or you can attach the entire lake as of a moment in time. Nothing moves on disk — the catalog just filters to the files that existed then. That's one database query, instead of walking snapshot history file by file on object storage the way older lakehouse formats do. ## What snapshots cost A snapshot is a commit, and DuckLake can keep far more of them than Iceberg because metadata lives in a database instead of separate files. The real cost is retained data: appends make time travel essentially free, updates cost a copy of what changed, and full refreshes are the case to watch — hourly refreshes kept for a week means 168 copies. The fix is tiered retention: keep every transaction for a few days, daily snapshots for a week, weekly beyond that. Expiration is a SQL query on a schedule, and it's deliberately two-step — expire, then delete about a week later, so you keep an undo window. ## Schema evolution without rewrites Add, rename, and drop columns, or widen types (an `INTEGER` that overflows becomes a `BIGINT`) without rewriting any existing parquet. Changes must be lossless — no downsizing — which is the compromise that keeps old files readable. Time travel keeps working across schema changes, and you can attach commit messages to snapshots so an audit trail comes free. ## The change feed The data change feed shows every row inserted, updated, or deleted between any two snapshots, including before-and-after values. That's enough to run change data capture off a DuckLake into downstream systems, or to keep a local copy fresh by pulling only what changed. A related trick from the Q&A: copy just the catalog into a local DuckDB file and query the lake read-only from your laptop, leaving the data files where they live. ## Keep going Chapter 4 and the rest of [DuckLake: The Definitive Guide](/lp/ducklake-lakehouse-table-format-book-full/) are free to download, with new chapters delivered as they're written. New to DuckLake? Start with [getting started with the DuckLake table format](/blog/getting-started-ducklake-table-format/) — it's three commands to try locally. TABLE OF CONTENTS - Time travel is an undo button for data - What snapshots cost - Schema evolution without rewrites - The change feed - Keep going Start using MotherDuck now! [Try 7 Days Free](https://auth.motherduck.com/authorize?app_source=web&response_type=code&client_id=bza3KWQpxRAFlTlRFXUo29AOg9xD7zcp&redirect_uri=https%3A%2F%2Fapp.motherduck.com%2F&state=STATE&auth_flow=signup&screen_hint=signup&ext-ph_distinct_id=fc2b20bf-6450-4f86-b382-594b66c9b22d) ## FAQS ### What is time travel in DuckLake and how do I use it? Time travel lets you query or restore any DuckLake table as it existed at a past moment. Add an AT clause to the FROM of any query with a timestamp or snapshot ID, or attach the entire lake as of a point in time to wind everything back at once. It's a metadata operation — no files are moved or rewritten — so it resolves with a single catalog query. ### Does DuckLake time travel mean data is never deleted? You choose. Deletes are recorded in catalog metadata, so old row versions stay readable until you expire snapshots and compact. Set a retention window that fits your needs, run scheduled expiration beyond it, and use compaction to reclaim storage — including hard-deleting data for GDPR and similar compliance requirements. ### How much storage does DuckLake time travel cost? It depends on your write pattern. Appends are essentially free — the new rows are data you need anyway. Updates cost a copy of what changed. Full refreshes are the expensive case: each refresh you retain is a full copy of the table, so hourly refreshes kept for a week means 168 copies. A tiered retention policy (every snapshot for days, daily for a week, weekly beyond) keeps costs down without giving up time travel. ### How does schema evolution work in DuckLake? You can add, rename, and drop columns, and change column types as long as the change is lossless — widening an INTEGER to a BIGINT works, downsizing doesn't. None of it rewrites existing parquet files; new data flows in with the new schema and old files stay readable. Time travel continues to work across schema changes, and DuckLake tracks the schema history so you can compare tables across versions. ### How is DuckLake different from Iceberg for snapshots and time travel? Iceberg keeps three layers of metadata files on object storage, so resolving a snapshot means a series of high-latency reads, and compacting across snapshots is hard — which pressures you to keep few of them. DuckLake puts the catalog and metadata in a regular database, so finding your files is one fast query and keeping thousands of snapshots is fine. The parquet layer is Iceberg-compatible, so migrating an Iceberg table into DuckLake is a single metadata copy. ## Related Videos [60:29](/videos/ai-agents-semantic-layer/)[2026-08-26](/videos/ai-agents-semantic-layer/) ### [Do AI Agents Need a Semantic Layer?](/videos/ai-agents-semantic-layer/) Do AI agents need a semantic layer? Evals comparing plain-text context with a Malloy semantic layer show where each wins, and what it costs. Stream AI, ML and LLMs BI & Visualization SQL [63:17](/videos/agentic-data-engineering-stack/)[2026-08-18](/videos/agentic-data-engineering-stack/) ### [Beyond Copilots: We're Building a Data Stack Live with AI Agents](/videos/agentic-data-engineering-stack/) Agentic data engineering in practice: AI agents build dlt ingestion into MotherDuck and a governed Lightdash semantic layer, live in an hour. Stream AI, ML and LLMs Data Pipelines Ecosystem [52:41](/videos/guides-context-layer-ai-agents/)[2026-08-13](/videos/guides-context-layer-ai-agents/) ### [Introducing Guides: Warehouse-Native Context for AI Agents](/videos/guides-context-layer-ai-agents/) Guides store business context inside your warehouse so AI agents write correct SQL. See how warehouse-native context works in MotherDuck. Stream AI, ML and LLMs MotherDuck Features [View all](/videos/)