Databricks Auto CDF: deriving changes at query time
Change-data processing is becoming less dependent on configuring every table correctly before changes occur.
What happened
The 1 September Databricks Runtime 19 notes describe Automatic Change Data Feed as generally available. Auto CDF derives row-level changes at query time using row tracking for Delta Lake and Apache Iceberg v3 tables, without per-table CDF enablement. Databricks also reports a staged regional rollout through the end of October. Runtime 19 or later and row tracking are prerequisites; GA does not mean every workspace has access today.
Why it matters
CDC pipelines often depend on decisions made before the downstream use case is fully known. Query-time change calculation provides more flexibility when a downstream consumer later needs incremental records.
Who it affects: Data engineers, lakehouse architects, streaming teams and teams building incremental transformations.
What to do next
Review how CDC is currently enabled and consumed. Determine which pipelines require pre-materialised change feeds and which could benefit from deriving change sets later. Also validate storage, row-tracking and runtime requirements before adopting the pattern broadly.
Signal Take
Incremental data architecture is becoming more declarative. Instead of requiring teams to predict every future change-consumption requirement, platforms are increasingly preserving enough state to reconstruct those changes when needed.
Scope and limitations
Verify workspace rollout, retained history and row-tracking requirements. Do not assume arbitrary historical changes remain reconstructible forever.
Sources and editorial record
Databricks — Runtime 19 release notes (opens in a new tab)- Source type
- Vendor documentation or announcement
- Source published
- 1 Sept 2026
- Source checked
- 19 Sept 2026
Prepared with AI assistance and checked against the linked source. This is editorial interpretation, not an independent product benchmark. How we work.