Iceberg Tables in Snowflake: Snowflake performance on your own data lake

Snowflake no longer forces you to choose between a data lake and a data warehouse.
With Iceberg Tables you can query and write data in an open format, on storage you control, using Snowflake’s query engine.

In this article we review what Iceberg Tables in Snowflake are, how they work, what their performance depends on, and when to use them, based on the official Snowflake documentation and data-project best practices.

The problem: duplicated data between the data lake and the data warehouse

The classic pattern creates friction:

• data lives in a data lake (Parquet on S3, ADLS, or GCS)
• to analyze it with good performance, it gets copied into the data warehouse
• you end up with duplicated copies, load pipelines, and repeated storage costs

Result: the same data in two places, with fragile sync and difficult governance.

The Iceberg Tables approach: work on a single dataset in an open format, queryable by Snowflake and other engines, without keeping a full second analytical copy inside Snowflake.

What are Iceberg Tables?

Iceberg Tables combine Snowflake’s query engine and capabilities with the open Apache Iceberg format. Their data and metadata can reside in Snowflake-provided storage or in your own cloud through an external volume. They are especially useful for lakehouse architectures, cross-engine interoperability, and existing data lakes.

They use the Apache Iceberg open table format specification, which provides:

• ACID transactions: consistent reads and atomic writes
• Schema evolution: add, drop, rename, or reorder columns and certain compatible type changes, without rewriting all existing files
• Hidden partitioning: queries filter by business columns without depending on physical file paths
• Snapshots: consistent table versions for historical queries, rollback, and auditing, subject to retention policy and catalog model

In Snowflake, Iceberg Tables rely on the Apache Parquet file format.

How they fit in Snowflake: catalog + storage location

An Iceberg Table is built on two pieces:

• The catalog: which system manages the table metadata (Snowflake or an external catalog)
• The storage location: where data and metadata live

For storage, there are two models:

• Snowflake storage: Snowflake provides and manages the storage. You set EXTERNAL_VOLUME = ‘SNOWFLAKE_MANAGED’ (or rely on defaults when Snowflake is the catalog); no external volume object is needed.
• Customer-managed storage: your S3, ADLS, or GCS bucket, accessed by Snowflake through an external volume.

That separation between catalog and storage is the basis of the open format: when you use your own storage, the data is not locked inside Snowflake.

What Iceberg Table performance depends on

Performance is not automatic: it depends on how files and metadata are organized. The main levers are:

• Metadata and statistics: Snowflake uses Iceberg metadata and file statistics to skip irrelevant data (pruning) and read less.
• Parquet file size: too many small files hurt; Snowflake lets you tune the target size of the files it writes.
• Maintenance: data and manifest compaction, plus snapshot expiration, prevent degradation over time.
• Clustering: on Snowflake-managed tables you can apply Automatic Clustering on frequently filtered columns.
• Locality: if storage and the Snowflake account are in different regions, you incur latency and egress cost.

On externally managed tables, Snowflake does not perform these maintenance operations: they must be run with the external Iceberg catalog or engine (expiring snapshots, removing old metadata, compaction), aligning the Snowflake refresh with each operation.

Two catalog models (the key decision)

Snowflake supports two catalog options for Iceberg, and choosing well is the most important part:

1. Snowflake as the catalog (Snowflake-managed table)

• full platform support, with read and write access
• data and metadata in Snowflake-managed storage or in your own cloud (external volume)
• the recommended option when Snowflake is the main write engine
• it can also interoperate: a Snowflake-managed table can be exposed to external Iceberg REST-compatible engines through Snowflake Horizon Catalog (existing Snowflake Open Catalog customers can still use its sync, but Horizon Catalog is the currently recommended option)

2. External catalog (externally managed table)

• Snowflake can query compatible Iceberg tables governed by supported external catalogs
• it can also write to tables in a remote Iceberg REST catalog, either through a catalog-linked database with write operations enabled, or by registering the table —which must already exist in the remote catalog— in a standard Snowflake database; supported for Iceberg spec v2 and v3, with some limitations
• it supports automated refresh of the table metadata (AUTO_REFRESH)

External Volume: your storage, under your control

To store Iceberg data and metadata in your own cloud, you create an external volume and reference it from the table. The volume points to your bucket (for example, S3) with the corresponding access role.

Important: creating the object does not complete the integration. To make it work (and writable) you must configure the IAM role policy and trust policy, retrieve the principal with DESC EXTERNAL VOLUME, verify the connection with SYSTEM$VERIFY_EXTERNAL_VOLUME, and allow writes with ALLOW_WRITES = TRUE (plus storage permissions such as s3:PutObject).

If you prefer Snowflake storage instead of your own cloud, set EXTERNAL_VOLUME = ‘SNOWFLAKE_MANAGED’: in that case the files reside in Snowflake-provided storage, not in your cloud account.

Create a Snowflake-managed Iceberg Table

With Snowflake as the catalog, you define the storage location (an external volume or SNOWFLAKE_MANAGED) and a base location where Snowflake writes data and metadata:

Externally managed tables

When the table is governed by an external catalog, you reference it by its name in that catalog and, optionally, enable automatic metadata refresh. This example corresponds to an Iceberg REST / AWS Glue catalog:

This is not universal syntax: depending on the catalog you may need CATALOG_NAMESPACE, and tables created directly from metadata files use a different variant with METADATA_FILE_PATH (read-oriented). AUTO_REFRESH requires a compatible, correctly configured integration.

Convert an external table to Snowflake-managed

If a table starts out managed by an external catalog and you later want Snowflake to govern it (for full platform support and lifecycle management), you can convert it:

The serialization policy supports COMPATIBLE (maximum interoperability with other engines) or OPTIMIZED (encoding and compression oriented to performance within Snowflake).

Before converting: refresh the table (ALTER ICEBERG TABLE … REFRESH), make sure the external volume allows writes (ALLOW_WRITES = TRUE), and hold the required storage permissions and OWNERSHIP. Note these limits: conversion is not supported for tables that belong to a catalog-linked database, nor for columns of type uuid or fixed(L). Partitioning handling also depends on the Iceberg version: for v2 tables the existing partitioning is removed during conversion, while for v3 tables it is preserved. After conversion, Snowflake takes over the table lifecycle and concurrent external writers must be avoided.

When to use Iceberg Tables (and when not to)

They are a good fit when:

• you already have an open-format data lake you don’t want to duplicate
• you need interoperability: several engines reading the same data
• you want to avoid format lock-in and keep data in your cloud

They probably aren’t worth it when:

• the entire data lifecycle remains within Snowflake, with no external consumption
• you want maximum operational simplicity: standard tables need fewer pieces
• you don’t need open format or self-managed storage

Where to start (quick wins)

• identify which datasets are duplicated today between data lake and warehouse
• decide the catalog model first (Snowflake or external)
• for your own cloud, create the external volume and enable ALLOW_WRITES if you will write
• start with a Snowflake-managed table (full read and write)
• use AUTO_REFRESH only on tables governed by external catalogs
• define the base location and naming convention before scaling
• plan maintenance (compaction, snapshot expiration) and keep an eye on costs

Conclusion

Iceberg Tables bring the data lake and the data warehouse together, avoiding a second analytical copy inside Snowflake.

The keys to the decision:

• catalog: Snowflake-managed when Snowflake should control the lifecycle and give the fullest support; external catalog when another catalog must remain the table’s source of truth
• storage: Snowflake-provided or your own cloud via an external volume
• open Parquet + Iceberg format: the same data, multiple engines

First define the catalog model and the storage. Then build on top of open format.

Is your data platform taking advantage of Iceberg’s open format and interoperability?

At Bravent, we help organizations design, optimize, and scale their data platforms, choosing the right architecture (lakehouse, warehouse, or hybrid) to avoid duplication, unnecessary costs, and format dependencies.

📩 Contact us: info@bravent.net