DivyaandData
Databricks Employee
Databricks Employee

‎04-21-2026 08:18 AM

Hey @Raj_DB , The TLDR is  time travel is great for short-term ops and debugging, but brittle as your primary reporting history, and its cost profile is harder to control and reason about than a purpose-built history table.

  • Docs 1,2 explicitly say Delta table history/time travel is for auditing, rollback, and point-in-time queries, and is not recommended as a long-term backup/archival solution.
  • In new runtimes, time travel is blocked once you go beyond delta.deletedFileRetentionDuration (default 7 days), regardless of VACUUM arguments. Source
  • Time travel depends on both log and data retention; VACUUM and log cleanup permanently remove older versions. Docs - 1,2
In terms of cost -
  • There’s no separate “time travel fee” – you pay for storage and compute in both patterns. The cost difference comes from how much data you retain and how it’s organized.
  • To get a long time-travel window, you must keep all old data files and logs for the source table for that period (deletedFileRetentionDuration and logRetentionDuration), which increases storage and can slow queries because they scan more versions/files. Source

With a dedicated history table, you can:

  • Store only what reporting needs (e.g., daily snapshots or SCD facts instead of every tiny intermediate write).
  • Partition and compact for reporting patterns.
  • Apply your own retention (e.g., 13 months) without affecting operational tables or being surprised by VACUUM behavior.

View solution in original post