Iceberg Tables: The Storage Revolution
Freedom from vendor lock-in? Why Apache Iceberg is the most important architectural shift in the Data Cloud
“Data Gravity” has always been the cloud vendor’s moat. “It costs too much to move our 5PB of data, so we’re stuck.”
Apache Iceberg breaks the moat.
In 2025, Snowflake’s support for Iceberg is mature. It’s no longer a “preview feature” to toy with; it’s a production standard for large enterprises.
What is an Iceberg Table?#
It looks like a table. It queries like a table. But the data files (Parquet) live in your bucket (S3/Azure/GCS), and the metadata (manifests) lives in your bucket (or is managed by Snowflake).
CREATE TABLE my_iceberg_table
CATALOG = 'SNOWFLAKE'
EXTERNAL_VOLUME = 'my_s3_vol'
BASE_LOCATION = 'my_data/'
AS SELECT * FROM raw_data;Managed vs. Unmanaged#
- Snowflake-Managed: Snowflake acts as the Catalog. It handles compaction, snapshots, and maintenance. It feels exactly like a native table, but the files are open.
- Externally-Managed (Polaris/Glue): Snowflake is just a reader. You use Spark or Trino to write to the table, and Snowflake asks the catalog “Where are the files?” when you query.
Performance in 2025#
The gap between Native Tables and Iceberg Tables has closed significantly.
- Pruning: Excellent (uses min/max stats in manifests).
- Caching: Local SSD caching on warehouses works for Iceberg too.
You might see a 5-10% overhead compared to native micro-partitions for highly optimized queries, but for 90% of workloads, it’s imperceptible.
Why switch?#
Interoperability. You can run a heavy ML job in Spark against the exact same data that your BI dashboard is querying in Snowflake, without ANY copy pipelines.
Conclusion#
Iceberg represents the “Open Data Cloud.” It forces vendors to compete on compute engine quality, not storage lock-in. And Snowflake is winning that race.