Delta Lake Essentials

Not this time. Data files are written first, then one new entry is committed to the transaction log listing every file the write added. Readers only see files the log marks as valid, so a failed write leaves no visible change.

Not this time. Databricks gives snapshot isolation to reads and write-serializable isolation to writes by default, through optimistic concurrency control: no locks, so no deadlocks.

Not this time. VACUUM deletes data files that are no longer in the latest table state and were removed more than 7 days ago by default. After it runs, you can no longer time travel to a version older than that retention period.

Not this time. Time travel adds VERSION AS OF or TIMESTAMP AS OF after the table name. In Python, the versionAsOf and timestampAsOf reader options do the same.

Not this time. History and time travel follow different settings. History is kept for logRetentionDuration, 30 days by default, while the old data files are kept only for deletedFileRetentionDuration, 7 days by default, and VACUUM removes them after that. Use only the last 7 days for time travel unless you raise both.

Not this time. Only a single source row can match a given target row. Remove the duplicates from the source first, for example by keeping the latest row for each key, then merge.

Not this time. WHEN NOT MATCHED BY SOURCE can UPDATE or DELETE target rows that have no matching source row. Databricks recommends a condition on it so the whole target is not rewritten.

Not this time. Delta enforces the schema on write: every inserted column must exist in the target table, so the INSERT fails with an unresolved column error. To add the column on purpose, use schema evolution (INSERT WITH SCHEMA EVOLUTION, or the mergeSchema option).

Not this time. The change data feed adds _change_type, _commit_version and _commit_timestamp. An update appears as 2 rows: update_preimage, the row before the change, and update_postimage, the row after.

Not this time. Without deletion vectors, changing one row rewrites the whole Parquet file that holds it. With them, the row is marked as removed in metadata, and reads apply the marks at query time. The file is rewritten later, by OPTIMIZE, REORG TABLE ... APPLY (PURGE) or auto-compaction.

Not this time. Liquid clustering replaces partitioning and ZORDER. Its clustering keys can be changed without rewriting existing data, it avoids over-partitioning, and it allows row-level concurrency, which reduces write conflicts.

Not this time. ALTER TABLE ADD CONSTRAINT verifies that all existing rows satisfy the constraint before adding it, so the command fails. Once a constraint exists, any transaction that violates it fails with an error.