Delta Lake 4.4 vs 4.3: The Spark 4.2 Upgrade Trap
Delta Lake 4.4 vs 4.3 looks, on paper, like a routine minor-version bump: new SQL syntax, a couple of read-path fixes, some Unity Catalog polish. Then you run your first cluster restart on the new version and your Iceberg-compat reads start throwing classpath errors nobody can explain. The cause is buried in a single line of the release notes — Delta Spark now defaults to Apache Spark 4.2, while the delta-iceberg_2.13 artifact that powers UniForm’s Iceberg reads is still built against Spark 4.1. Delta never labeled this a breaking change. It just quietly became one for anyone running Iceberg-compat workloads. What this covers:
- What actually changed between Delta Lake 4.3.0 and 4.4.0, feature by feature
- Why the Spark 4.2 default collides with
delta-iceberg, and who gets hit - The new identity column syntax, VOID-type read semantics, and Unity Catalog metric views
- A practical, checklist-driven upgrade path that avoids the trap entirely
Context and Background
Delta Lake is the open table format Databricks open-sourced and has continued to steward as the reference implementation for transactional tables on object storage. It sits in the same layer as Apache Iceberg and Apache Hudi — all three solve the same core problem (ACID semantics, schema evolution, and time travel on top of Parquet files in a lake) with different metadata layouts and different governance models. We’ve already run a full comparison of Iceberg, Delta Lake, and Hudi as a lakehouse table-format ADR, so this post won’t re-litigate that three-way decision. What it will do is something none of our existing coverage has: walk through an actual Delta Lake version migration, the kind of unglamorous but consequential work that determines whether an upgrade weekend goes smoothly or turns into an incident.
The two releases in question are close together and both real, dated entries in Delta’s release history. Delta Lake 4.3.0 shipped on June 22, 2026, introduced under the banner “Strengthening Catalog-Managed Delta Tables with the Unity Catalog Delta APIs.” Delta Lake 4.4.0 followed on August 20, 2026, titled “Advancing the Open Lakehouse with Apache Spark, the Delta Kernel, and the new UC Delta APIs.” Two months apart, both squarely focused on catalog-managed tables and the Unity Catalog Delta API surface — which tells you where Databricks is investing engineering effort right now. If you want the primary source rather than a secondhand summary, the Delta Lake blog publishes each release announcement in full, and the Delta Lake GitHub releases page carries the corresponding tagged changelogs.
What makes this migration worth a dedicated post is that Delta Lake doesn’t publish a “breaking changes” section the way, say, a major Spark release does. The 4.4.0 announcement is explicit that no breaking changes or deprecations are being called out. And yet a default-version bump buried in the dependency graph can break a production pipeline just as thoroughly as a documented breaking change would. That gap — between what a vendor labels a breaking change and what actually breaks your cluster — is the subject of this article, and it’s more useful to a working data engineer than another feature list.
It’s also worth noting how tight the 4.3-to-4.4 gap is: two months, both releases anchored on the same theme of catalog-managed tables and the Unity Catalog Delta API surface. That cadence matters for planning. Teams that run a quarterly upgrade cycle will likely skip straight from whatever they were on before 4.3 to 4.4, which means they inherit both releases’ changes at once — the catalog-managed API hardening from 4.3 and the Spark-version default shift plus new SQL surface from 4.4 — in a single migration window instead of two smaller ones. That compresses the testing surface and makes it more likely that a subtle interaction, like the delta-iceberg conflict, gets missed in the rush to validate the more visible features.
Why Delta 4.4’s Spark 4.2 Default Breaks delta-iceberg
Direct answer: Delta Lake 4.4.0 changes Delta Spark’s default runtime to Apache Spark 4.2, but the delta-iceberg_2.13 compatibility artifact that enables Iceberg reads through UniForm is still built against Spark 4.1 and is not compatible with 4.2. If your pipelines depend on delta-iceberg for cross-format reads, upgrading to Delta 4.4 without pinning Spark separately can silently break those reads at runtime.
This is the headline risk of the 4.3-to-4.4 jump, and it’s worth being precise about what “default” means here, because the imprecision is exactly what causes incidents. Delta Spark’s build and dependency resolution ships with a default Spark version baked into its POM and its published artifacts. Historically, when Delta bumps that default, most users don’t notice because they’re not running anything that depends on a Spark-version-pinned side artifact — they’re just running Spark SQL, DataFrame operations, MERGE, and OPTIMIZE, all of which move forward cleanly across minor Spark versions. The delta-iceberg module is different. It exists specifically to let Iceberg-format readers consume Delta tables through UniForm, and it’s compiled against a specific Spark version because it has to interoperate with Iceberg’s own Spark integration layer, which is itself version-pinned. When Delta 4.4 moves its default to Spark 4.2 while delta-iceberg_2.13 hasn’t been rebuilt for 4.2 yet, the two artifacts fall out of sync. Continued support is explicitly maintained for Spark 4.1.0 and 4.0.1, which is the safety valve — but it means the “upgrade to 4.4” story is not a single path, it’s a fork depending on whether Iceberg interop is in your dependency tree.
What UniForm and delta-iceberg actually do
If you haven’t worked directly with cross-format reads before, it’s worth being concrete about what these components do rather than treating them as black boxes. UniForm is Delta’s mechanism for writing metadata in more than one table format from a single set of underlying Parquet files — when enabled, a table written through Delta also gets Iceberg-compatible (and, in some configurations, Hudi-compatible) metadata generated alongside the native Delta log, so that engines which only speak Iceberg’s metadata format can query the same physical data without a conversion job or a duplicate copy. delta-iceberg_2.13 is the Spark-side library that makes the Iceberg half of that story work when you’re reading through Spark rather than through a native Iceberg engine like Trino or a standalone Iceberg REST catalog client — it bridges Delta’s internal APIs to the Iceberg Spark connector’s expectations. That bridging role is precisely why it’s sensitive to Spark version: it has to match both Delta’s internal API surface and Iceberg’s Spark integration at the same time, which is a narrower compatibility window than either project maintains independently.
Who actually hits this
Not every Delta shop is exposed. The trap specifically catches teams that:
- Enabled UniForm’s Iceberg compatibility mode (
delta.universalFormat.enabledFormats = 'iceberg') so that Iceberg-native engines — Trino, Snowflake reading Iceberg tables, or a separate Iceberg catalog — can query Delta-written tables without a separate ETL hop. - Run the
delta-iceberg_2.13artifact explicitly in their Spark classpath rather than relying purely on native UniForm write-time metadata generation. - Have a shared cluster runtime where bumping Spark to 4.2 for Delta 4.4 features would also affect Iceberg-reader jobs that expect Spark 4.1 semantics.
If none of that applies — you’re running straight Delta tables with no Iceberg interop — the Spark 4.2 default is a non-event. You get the new features and move on. That asymmetry is exactly why this bites teams by surprise: it’s invisible until you’re the one running the specific combination that trips it, and nothing in a routine upgrade checklist flags it unless you already know to look for a Spark-version mismatch between Delta core and its Iceberg-compat side artifact.
Why this isn’t a “true” breaking change, and why that distinction doesn’t help you
It’s worth separating two claims that get conflated in migration discussions. Claim one: “Delta 4.4 has a breaking change.” Claim two: “Upgrading to Delta 4.4 can break your pipeline.” The first claim is, per Delta’s own release communication, false — there is no breaking change documented for 4.4.0. The second claim is true for a specific, identifiable subset of workloads. The mechanism is an emergent interaction between two independently versioned artifacts (Delta core and delta-iceberg) rather than a documented API removal or semantic change within Delta itself. That’s a meaningfully different category of risk: it’s not something Delta’s compatibility testing would necessarily catch, because from Delta’s perspective it shipped a default bump, not a breaking change to its own surface. From your pipeline’s perspective, the distinction is academic — a job that read Iceberg tables cleanly on Tuesday and throws a NoSuchMethodError or a ClassNotFoundException on Wednesday doesn’t care which side of that line the incident falls on.
Figure 1: Decision flow for a Delta 4.4 upgrade — teams using delta-iceberg hit the Spark version trap and need to pin Spark 4.1/4.0.1 or move to native UniForm atomic initialization; teams without Iceberg interop proceed straight to the new features.
Long description for Figure 1: The diagram starts at “team plans Delta 4.4 upgrade” and branches on whether the team reads via delta-iceberg_2.13. The “yes” branch shows Delta Spark’s new Spark 4.2 default colliding with the artifact’s Spark 4.1 target, producing a compatibility trap node with two exits: pin the cluster to Spark 4.1 or 4.0.1, or swap to the new native UniForm atomic initialization path that doesn’t require the separate Iceberg-compat artifact. The “no” branch goes straight to adopting the Spark 4.2 default and unlocking identity columns and metric views.
Feature Walkthrough: 4.3 vs 4.4 and the Spark Compatibility Matrix
The Spark-version story is the headline, but it’s only one line item in a release that reshapes several corners of Delta’s SQL surface, its read semantics, and its streaming connector for Flink. Laid out side by side, the two releases show a clear trajectory: 4.3 hardened catalog-managed tables through the Unity Catalog Delta APIs, and 4.4 built new SQL-facing capability on top of that foundation while also pushing UniForm’s Iceberg story from “eventually consistent conversion” toward “atomic at creation time.”
Start with the feature-level comparison, because the differences are concrete enough to table directly.
| Capability | Delta Lake 4.3.0 | Delta Lake 4.4.0 |
|---|---|---|
| Catalog-managed table operations | Every operation flows through the Unity Catalog Delta APIs | Same, plus new UC Delta APIs extending catalog-managed coverage |
| Iceberg interop via UniForm | Atomic/incremental conversion, experimental IcebergCompatV3 | Atomic initialization at table-creation time via delta.enableIcebergCompatV2 and delta.universalFormat.enabledFormats |
| Identity columns | Not available | GENERATED ALWAYS AS IDENTITY / GENERATED BY DEFAULT AS IDENTITY, with custom START WITH / INCREMENT BY |
| VOID / NullType column reads | Failed or silently dropped on time travel and path-based reads | Preserved correctly on time travel and path-based reads (requires Spark 4.1+) |
SHOW PARTITIONS |
Not standardized on Delta tables | Supported, with clear errors on non-partitioned tables |
| Unity Catalog metric views | Not present | New governed layer: YAML dimensions/measures over catalog-managed tables (requires Spark 4.2+, UC connector 0.6.0) |
| Change Data Feed on catalog-managed tables | Working | Continued support, no changes called out |
| Delta-Flink | UC Delta API catalog-managed support | Adds primary-key upserts from Flink SQL, changelog-stream interpretation, Kafka keyed-changelog reads |
| Default Spark version for Delta Spark | Spark 4.0 / 4.1 (not yet defaulting to 4.2) | Defaults to Spark 4.2 |
The Spark-version story deserves its own table, because it’s the one most likely to determine whether your upgrade is boring or eventful. Different Delta capabilities have different minimum-Spark requirements, and they don’t all move in lockstep with the “default” version:
| Delta 4.4 capability | Minimum Spark version | Notes |
|---|---|---|
| Core Delta Spark operations | 4.0.1 | Baseline supported floor |
| Identity column DDL | 4.0.1+ | No dependency on the 4.2 default |
| VOID/NullType preservation on reads | 4.1+ | Explicitly requires 4.1 or newer |
delta-iceberg_2.13 compat artifact |
4.1 (only) | Not compatible with 4.2 as of 4.4.0 |
| Unity Catalog metric views | 4.2+ | Requires the new UC 0.6.0 connector alongside it |
| Delta Spark default runtime | 4.2 | New in 4.4.0; previously 4.0/4.1 |
Read that second table as a constraint-satisfaction problem, because that’s what it actually is. If your workload needs metric views, you need Spark 4.2 and UC connector 0.6.0. If the same cluster also needs delta-iceberg reads, you’re stuck — those two requirements are mutually exclusive on a single Spark runtime as of this release. The realistic resolution is architectural: separate the workloads onto different clusters (a 4.1 cluster for Iceberg-interop jobs, a 4.2 cluster for metric-view and identity-column workloads), or delay Iceberg-compat table migrations until Delta ships a delta-iceberg build that targets 4.2.
This kind of constraint table is worth building for any minor-version upgrade, not just this one — the pattern of “feature X requires version floor A, feature Y requires version floor B, and your platform team wants one cluster image” recurs constantly in fast-moving open-source ecosystems, and Delta’s release cadence over the past few cycles has made it a near-certainty rather than an edge case. The specific numbers here (4.0.1, 4.1, 4.2) will be different in six months, but the shape of the problem — reconcile per-feature version floors against a shared runtime — won’t be.
Figure 2: Decision tree for choosing a Spark runtime version based on which Delta 4.4 features a workload needs — delta-iceberg and VOID-type reads pull toward Spark 4.1, while metric views require Spark 4.2, creating a genuine conflict when both are needed on one cluster.
Long description for Figure 2: The flowchart asks which feature is needed and branches four ways: Iceberg reads via delta-iceberg (stay on Spark 4.1), VOID column time travel (Spark 4.1 or newer), Unity Catalog metric views (requires Spark 4.2 plus UC 0.6.0), and identity column DDL (works from Spark 4.0.1 up). The 4.1 and 4.2 branches each check whether the other feature is also required; if so, they converge on a “version conflict” node, which resolves to splitting workloads across clusters or delaying Iceberg table migration. If not, each branch reaches a stable-on-4.1 or stable-on-4.2 endpoint.
The most operationally significant change in 4.4, beyond the version friction, is what happens to UniForm’s Iceberg initialization path itself. In 4.3, IcebergCompatV3 was experimental and conversion to Iceberg metadata happened atomically or incrementally after the fact — meaning a table could exist in a state where Delta metadata was current but Iceberg metadata was still catching up, or where the initial conversion needed a separate pass. In 4.4, tables created with delta.enableIcebergCompatV2 and the appropriate delta.universalFormat.enabledFormats property get their Iceberg metadata written atomically at creation time, in the same transaction as the Delta commit. That’s a meaningful correctness improvement for teams doing dual-format reads from day one of a table’s life — no window where an Iceberg reader could see a table that Delta considers fully committed but Iceberg metadata hasn’t caught up to yet.
-- Example: table created with atomic UniForm initialization in 4.4
CREATE TABLE sales.transactions (
txn_id BIGINT GENERATED ALWAYS AS IDENTITY (START WITH 1000 INCREMENT BY 1),
amount DECIMAL(18,2),
status STRING
)
USING DELTA
TBLPROPERTIES (
'delta.enableIcebergCompatV2' = 'true',
'delta.universalFormat.enabledFormats' = 'iceberg'
);
That single CREATE TABLE statement also demonstrates the new identity column syntax: GENERATED ALWAYS AS IDENTITY with a custom starting value and increment, giving you a surrogate key generator without a separate sequence object or an application-side UUID generator. GENERATED BY DEFAULT AS IDENTITY is the companion variant for cases where you occasionally need to insert an explicit value into the identity column — useful for backfills and migrations from systems that already assigned their own IDs.
Figure 3: In Delta 4.4, CREATE TABLE with UniForm properties writes Delta and Iceberg metadata in the same atomic transaction, so an Iceberg reader can query the table immediately with no backfill window — unlike the incremental conversion path in 4.3.
Long description for Figure 3: The sequence diagram shows a client issuing CREATE TABLE with UniForm properties to the Delta engine. The engine writes a commit-zero entry to the Delta log and, within the same flow, writes Iceberg metadata to the Iceberg metadata store. Both writes confirm as atomic back to the engine, which confirms the table is ready for both Delta and Iceberg readers. A subsequent Iceberg-engine read against the table returns rows immediately, with no separate backfill or conversion step required.
Trade-offs, Gotchas, and What Goes Wrong
Start with the honesty check, because it matters for how you read the rest of this section: Delta’s own 4.4.0 release communication does not call the Spark 4.2 default a breaking change, and it doesn’t list any breaking changes or deprecations at all. Everything in this article about the delta-iceberg collision is an inferred operational risk — reconstructed from the fact that Delta Spark’s default moved to 4.2 while a specific side artifact stayed pinned to 4.1 — not a risk Delta flagged for you. That distinction is worth sitting with for a second, because it changes what “reading the release notes” actually protects you from. Reading the 4.4.0 notes top to bottom would not have surfaced this risk; you’d need to independently know which side artifacts exist, which Spark versions they target, and cross-reference that against the new default. Most teams don’t carry that mental model, which is exactly why this kind of trap causes incidents instead of getting caught in a design review.
The second gotcha sits inside the Iceberg atomic-initialization improvement itself. It only applies to tables created with the right properties from the start — delta.enableIcebergCompatV2 and delta.universalFormat.enabledFormats set at CREATE TABLE time. Tables that already exist under the older incremental-conversion model from 4.3 don’t retroactively become atomic; you’d need to evaluate whether a table rewrite or a property change on an existing table triggers reconversion, and that’s table-by-table, not a fleet-wide flip. If you manage hundreds of UniForm tables, budget time to audit which ones were created before versus after this change, because “atomic Iceberg init” is a property of table creation, not a blanket guarantee that applies retroactively to your whole catalog.
Third: the VOID/NullType preservation fix changes read behavior for existing tables, not just new ones. If any downstream job was relying on the old behavior — where a VOID column got silently dropped or the read failed outright — that job’s contract with its data just changed underneath it. A silent drop that some brittle downstream code had learned to tolerate (or, worse, depended on) will now surface a column it didn’t expect. This is a case where “fixing a bug” and “changing observed behavior for existing consumers” are the same event, and it’s worth grepping your schema evolution history for any table that has ever had a column typed or cast to NULL/VOID before you flip to 4.4 in production.
Fourth, and more mundane: the Delta-Flink connector now ships version-specific artifacts for Flink 2.0.2, 2.1.3, 2.2.1, and 2.3.0. If your Flink deployment pins a different patch version than these four, verify compatibility before assuming the new primary-key upsert and Kafka keyed-changelog features will just work — connector artifacts pinned to specific patch versions are exactly the kind of dependency-graph friction that caused the Spark 4.2 problem in the first place, just in a different corner of the ecosystem.
Fifth: don’t let the absence of a documented breaking change lull you into skipping integration testing on this upgrade. It’s tempting to treat a release with “no breaking changes” in the notes as a low-risk drop-in, and for a large share of Delta workloads that’s a fair read. But the Spark-version trap shows that “no breaking changes” is a statement about Delta’s own API surface, not a guarantee about the transitive dependency graph your specific deployment happens to have assembled. The right mental model is narrower than “safe upgrade” — it’s “safe upgrade for the parts of Delta that don’t touch a separately-versioned side artifact,” and knowing which parts of your stack fall into that second category is exactly the audit work this section is arguing for.
Figure 4: Unity Catalog metric views define dimensions and measures in YAML over a catalog-managed Delta table, requiring the UC 0.6.0 connector and Spark 4.2 — both Spark SQL clients and BI tools query the same governed metric definition.
Long description for Figure 4: The diagram shows a catalog-managed Delta table feeding a metric view YAML definition, which splits into dimensions and measures. Both feed into the UC 0.6.0 connector, which serves two consumer paths — a Spark 4.2 client query and a BI tool query — both converging on the same governed metric result, illustrating that the metric definition lives once, centrally, rather than being reimplemented per consumer.
Practical Recommendations
None of the risk described above requires an elaborate remediation plan — it requires a specific, narrow audit before you schedule the upgrade window, plus a willingness to decouple “upgrade Delta” from “adopt the new Spark default” if your dependency graph doesn’t support doing both at once. Treat this as a pre-flight checklist before touching a production Delta 4.4 upgrade:
- Audit for
delta-icebergusage first. Grep your cluster init scripts, library configs, and job dependencies fordelta-iceberg_2.13. If it’s present anywhere, do not assume the Spark 4.2 default is safe for that cluster. - Split clusters by requirement, not by team. If any workload needs Iceberg interop and any other workload needs metric views or the Spark 4.2 default, run them on separate cluster runtimes rather than trying to force one Spark version to satisfy both.
- Pin Spark explicitly rather than trusting the default. Continued support for Spark 4.1.0 and 4.0.1 means you can stay there deliberately; don’t let the upgrade silently ride the new default onto a runtime your dependencies haven’t caught up to.
- Evaluate the atomic UniForm path as a replacement, not just an addition. If
delta-icebergcompatibility is the only reason you’re stuck on Spark 4.1, check whether recreating those tables withdelta.enableIcebergCompatV2and native atomic initialization removes the dependency on the separate artifact entirely. - Re-test any job with a history of VOID/NullType columns. The read-path fix changes observed behavior for existing tables — this is a targeted regression-test item, not a general smoke test.
- Confirm your Flink connector patch version against the four artifacts Delta 4.4 explicitly supports (2.0.2, 2.1.3, 2.2.1, 2.3.0) before relying on the new upsert and changelog features.
- Stage the identity-column and metric-view rollout separately from the Spark-version change. These are additive features with no forced timeline; decoupling them from the runtime bump reduces the number of variables you’re debugging if something does break.
- Read the primary source before you upgrade, not a summary of it. The Delta Lake blog publishes each release’s full notes, and cross-referencing against the Apache Spark releases page will confirm which Spark line your other dependencies (Iceberg connectors, catalog clients) actually support.
Frequently Asked Questions
Does Delta Lake 4.4 officially list any breaking changes?
No. Delta’s own 4.4.0 release communication states plainly that no breaking changes or deprecations are being called out for this version. The Spark 4.2 default and its collision with the delta-iceberg_2.13 artifact is a real operational risk, but it’s an inferred one — a side effect of two independently versioned components falling out of sync — not a documented breaking change. Treat it as a migration risk to test for, not as something the release notes will warn you about directly.
Why does upgrading to Delta 4.4 break my Iceberg reads specifically?
Delta Spark’s default runtime moves to Apache Spark 4.2 in 4.4.0, but the delta-iceberg_2.13 compatibility artifact used for UniForm’s Iceberg-format reads is still built against Spark 4.1 and isn’t compatible with 4.2. If your cluster reads Delta tables through Iceberg-native engines using that artifact, the version mismatch produces classpath or runtime errors after the upgrade, even though nothing in your own code changed.
Can I use identity columns and delta-iceberg on the same table?
Yes — identity columns work from Spark 4.0.1 upward and have no dependency on the 4.2 default, so they’re compatible with the Spark 4.1 runtime that delta-iceberg requires. The conflict is specifically between delta-iceberg and features that require Spark 4.2, like Unity Catalog metric views, not with identity columns.
What’s the difference between GENERATED ALWAYS and GENERATED BY DEFAULT identity columns?
GENERATED ALWAYS AS IDENTITY means Delta always assigns the value itself; an explicit insert into that column is rejected. GENERATED BY DEFAULT AS IDENTITY generates a value automatically when you don’t supply one, but allows an explicit value to be inserted when you do — useful for backfills or migrations where existing IDs from another system need to be preserved. Both support custom START WITH and INCREMENT BY clauses.
Do I need to recreate existing UniForm tables to get atomic Iceberg initialization?
Effectively, yes, for the atomicity guarantee itself. Atomic initialization is a property of how a table is created — with delta.enableIcebergCompatV2 and delta.universalFormat.enabledFormats set at CREATE TABLE time — not a blanket behavior applied to every existing table after upgrading. Tables created under the older incremental-conversion model in 4.3 don’t automatically become atomic; each one needs individual evaluation for whether a rewrite is worth the atomicity benefit.
Should I stay on Delta 4.3 if I depend on delta-iceberg?
If Iceberg interop through delta-iceberg_2.13 is business-critical and you can’t yet pin Spark 4.1 alongside a 4.4 upgrade for other reasons, staying on 4.3 — or upgrading to 4.4 while explicitly holding your cluster on Spark 4.1.0 or 4.0.1 rather than accepting the new default — is a reasonable, low-risk choice. You’ll miss identity columns, VOID-type read fixes, and metric views until you resolve the version conflict, but you avoid the classpath failures entirely.
How do Unity Catalog metric views relate to Delta tables versus a semantic layer tool?
Metric views are described as the first layer of Unity Catalog’s newest governed-object family, and they sit directly on top of catalog-managed Delta tables rather than in a separate BI-tool-specific semantic layer. You define dimensions and measures once, in YAML, against the underlying table; both Spark SQL clients and BI tools that go through the UC 0.6.0 connector consume the same definition. The practical benefit is avoiding the classic problem where five BI dashboards each reimplement “revenue” slightly differently — the definition now lives centrally at the catalog layer, gated behind the Spark 4.2 requirement discussed above.
Further Reading
- Iceberg vs. Delta Lake vs. Hudi: a lakehouse table-format ADR — the full three-way comparison this post deliberately doesn’t repeat.
- Apache Iceberg V4 vs V3: root manifest and single-file commits — what changed on the Iceberg side of the format war.
- Iceberg catalogs: Polaris vs. Nessie vs. Unity Catalog — relevant if your metric-view rollout also touches catalog choice.
- Apache Spark 4.2 vs 4.1: CDC and geospatial upgrade — the Spark-side companion to this Delta migration.
- Delta Lake blog — primary source for both the 4.3.0 and 4.4.0 release announcements referenced throughout this post.
- Delta Lake GitHub releases — tagged changelogs if you need to verify a specific property name or version floor before a production change.
By Riju — about
