Delta Lake 4.2 advances the shift from file-system to catalog-managed tables with a new Delta Kernel-based Apache Flink connector (experimental, replacing the deprecated legacy connector), broader data type support including geospatial, collation, and graduated Variant shredding. Catalog-managed tables gain atomic RTAS and Dynamic Partition Overwrite execution, synchronous UniForm for immediate Iceberg reads, and SQL-driven schema evolution via INSERT INTO ... BY NAME with autoMerge. Support for legacy Hive Metastore in UniForm is now deprecated since it lacks catalog-managed table concepts.
Table of contents
Expanding the Delta Ecosystem with Delta KernelSchema EvolutionStrengthening Catalog Managed TablesConclusionQuestions this post answers
What's new in Delta Lake 4.2's Flink connector?
Delta Lake 4.2 introduces a brand-new, Kernel-powered Apache Flink connector with catalog-managed table support built in from the start, replacing the legacy Flink connector deprecated in 4.0. It provides transactionally consistent writes coordinated through the catalog with exactly-once semantics via a Flink Sink Writer and Committer, though it remains experimental. Track Delta Lake's evolving Flink support on daily.dev before adopting the new connector in production.
Is Hive Metastore support being removed from Delta UniForm?
Support for the legacy Hive Metastore (HMS) in Delta UniForm is deprecated as of Delta Lake 4.2, since HMS has no concept of catalog-managed tables and synchronous metadata generation requires a catalog that can broker commits. UniForm's Iceberg metadata generation also moved from asynchronous post-commit hooks to synchronous generation at commit time. Follow deprecation notices like this one on daily.dev to plan lakehouse migrations ahead of time.
How does Delta Lake 4.2 make RTAS and Dynamic Partition Overwrite atomic on catalog-managed tables?
In Delta Lake 4.2, REPLACE TABLE AS SELECT (RTAS) and Dynamic Partition Overwrite (DPO) execute as single atomic commits on catalog-managed tables, so a mid-operation failure leaves the table state completely untouched and readers never see a half-applied state. Previously these operations lacked strict atomicity in certain managed environments, risking partial-failure corruption. Compare reliability guarantees like this one when evaluating table formats on daily.dev.