Snowflake Interoperability: Apache Iceberg v3 Support Reaches General Availability
interoperability snowflake lakehouse data-engineering apache-iceberg
trending_up Trend: interoperability

Snowflake Interoperability: Apache Iceberg v3 Support Reaches General Availability

calendar_month June 29, 2026 update Updated: June 30, 2026

🔄 Update — 30 June 2026: Snowflake Apache Iceberg Tables GA & Databricks Lakehouse Monitoring

Snowflake has announced the General Availability of Apache Iceberg tables, allowing high-performance direct queries on external data lakes. This matches Databricks’ recent release of new Lakehouse Monitoring features, highlighting the converging standards of Lakehouses and traditional Data Warehouses.

What’s new?

  • Snowflake Iceberg Tables GA: Apache Iceberg tables are now generally available, enabling direct, high-performance querying of external data lakes.
  • Databricks Lakehouse Monitoring: Databricks has launched new monitoring features to track data quality and integrity within the Lakehouse.

Why this adds to the article

This update reflects the official GA milestone of open formats in Snowflake and the competitive alignment of Databricks, reinforcing the trend toward unified data architectures.

Snowflake Interoperability: Apache Iceberg v3 Support Reaches General Availability

Summary

Snowflake has announced the General Availability (GA) of Apache Iceberg v3 support. This release marks a significant milestone in multi-engine lakehouse interoperability, introducing row lineage, semi-structured data capabilities via VARIANT data shredding, O(1) deletion vectors, and open data sharing via Horizon Catalog. Together, these features enable high-performance data processing directly on open table formats without data duplication.

What happened

  • General Availability (GA) Announcement: On May 7, 2026, Snowflake officially launched production-ready support for Apache Iceberg v3.
  • VARIANT Shredding: Native support for the VARIANT data type in Iceberg v3 allows Snowflake to apply its proprietary “shredding” technique on open Parquet files. This extracts nested JSON fields into strongly-typed sub-columns, enabling high-performance columnar scans.
  • Row Lineage Tracking: Iceberg v3 introduces native row-level tracking metadata (such as _row_id and _last_updated_sequence_number), which simplifies Change Data Capture (CDC) and auditing.
  • Deletion Vectors: The upgrade replaces positional delete files with binary bitmaps, enabling O(1) read-time lookups for DML operations.
  • Horizon Catalog Integration: Direct integration allows external query engines like Apache Spark or Trino to read and write to Iceberg tables governed by Snowflake bi-directionally.

Why it matters

Historically, organizations faced a trade-off between open data formats (which avoid vendor lock-in but lacked performance) and proprietary engines. With Iceberg v3 GA in Snowflake, this gap is bridged:

  • Zero Copy Interoperability: Different engines (e.g., Snowflake, Spark, Trino) can query the exact same data files concurrently.
  • Performant Semi-Structured Data: The VARIANT shredding feature means querying massive JSON structures is no longer an I/O bottleneck, as engines only read requested sub-fields.
  • Simplified Data Governance: Horizon Catalog provides a single metadata layer that enforces role-based access control (RBAC) across multiple tools.

Evidence

  • Official Press Release: Snowflake’s announcement of the open framework for interoperable enterprise data and AI.
  • Developer Benchmarks: Early performance indicators showing up to 10x speedup in UPDATE/DELETE operations due to deletion vectors.
  • Community Adoption: Discussions on Reddit (r/snowflake) and LinkedIn showcasing developers implementing v3 features immediately following the GA announcement.

Analysis

The GA of Iceberg v3 in Snowflake is more than just a minor version bump; it is a strategic repositioning. Databricks’ recent focus on Delta Lake and Unity Catalog has put pressure on Snowflake to prove its commitment to open formats. By implementing v3 features like deletion vectors and row lineage, Snowflake is matching Delta Lake’s feature parity while maintaining its governance edge via the Horizon Catalog. The addition of VARIANT shredding is particularly significant, as semi-structured data has historically been a weak point for open table formats.

Practical Takeaways

  1. Plan Table Creation Wisely: The default Iceberg version for new tables in Snowflake remains v2. To use v3, you must configure the ICEBERG_VERSION_DEFAULT parameter or specify v3 explicitly during table creation.
  2. Beware of Irreversibility: Upgrading an existing table from v2 to v3 is irreversible. Furthermore, older v2 readers will not be able to read v3 tables, so verify your entire toolchain’s compatibility first.
  3. Leverage Deletion Vectors: Enable deletion vectors on tables with high DML activity (frequent updates or deletes) to reduce compaction overhead.
  4. Migrate Semi-Structured Workloads: Convert JSON and semi-structured columns to the VARIANT type to take advantage of columnar parquet shredding.

Open Questions

  • How quickly will downstream open-source query engines (like Presto or older Flink distributions) support all Iceberg v3 features natively?
  • Will the complexity of managing bi-directional writes via Horizon Catalog lead to synchronization issues in complex multi-cloud deployments?

Sources

  1. Snowflake Pioneers New Open Framework for Interoperable Enterprise Data and AI
  2. Snowflake Summit 2026: Summary of New Features
  3. Snowflake Now Supports Apache Iceberg v3 (General availability)
  4. Snowflake Summit 2026: Context, Custom Model Training & Iceberg v3
  5. Reddit: Newly Launched Snowflake Summit Features
  6. LinkedIn: Analytics India Magazine Post on Data Interoperability