Ninety percent of the "performance" you pay for in Snowflake is actually just a tax on your inability to move your data. If you’re like most engineers I’ve worked with in fintech, you’ve convinced yourself that moving to an open table format like Iceberg means you have to go build a bespoke Spark/Trino stack on top of an S3 bucket and deal with the operational headache of catalog synchronization.
You are wrong. And that laziness is costing your company a fortune.
For years, we treated Snowflake as both the engine and the prison. We stored data in proprietary micro-partitions that were functionally invisible to every other tool in the stack. If you wanted to run a quick Python script to do some ML training, you had to clone the table, unload to CSV/Parquet, or pay for an expensive Snowflake compute cluster just to read a few gigabytes of rows.
Snowflake-managed Iceberg tables change the math. They allow you to maintain the convenience of a managed service while storing the actual data files—the Parquet files—in your own cloud storage. You aren't just saving on storage costs; you are effectively decoupling your state from your compute.
The "classic" Snowflake workflow is a black box. You CREATE TABLE and hope for the best. When you leave, you’re forced to perform an UNLOAD operation, which is essentially a massive export job that burns compute credits, messes with your time-travel metadata, and leaves you with a pile of flat files that lack the schema evolution capabilities your downstream apps need.
I’ve seen junior engineers try to "optimize" this by spinning up AWS Glue crawlers and manual Athena partitions. The failure mode is predictable: the Snowflake metadata and the Glue catalog drift apart within three weeks. You end up with a "source of truth" that isn't true, a bunch of broken dashboards, and a panicked Friday afternoon spent patching manifest files.
The common approach relies on the vendor’s proprietary binary format. If Snowflake goes down—or, more likely, if your bill hits a threshold where Finance starts asking questions—you are locked. You can't just point a Trino cluster at your S3 bucket and expect it to work. You need a migration strategy. With managed Iceberg tables, that migration strategy is just a standard SQL command.
Photo by Andris Gangis on Unsplash
Implementing this isn't a complex migration. It's a configuration change. You move from the default TABLE type to an ICEBERG table managed by Snowflake.
When you execute:
CREATE TABLE my_iceberg_table (
id STRING,
event_time TIMESTAMP,
payload VARIANT
)
USING ICEBERG
CATALOG = 'SNOWFLAKE'
EXTERNAL_VOLUME = 'my_s3_external_volume'
BASE_LOCATION = 'my_iceberg_data';
You are essentially telling Snowflake: "I want you to handle the heavy lifting of metadata management, compaction, and schema evolution, but keep the actual Parquet files in my bucket."
The EXTERNAL_VOLUME is the key here. It defines the bridge between Snowflake and your S3/GCS bucket. Once this is set up, Snowflake acts as the "Engine," but the "Storage" lives in your VPC. If you decide to add a Trino cluster or a local DuckDB instance for quick testing, you just point them at the same S3 bucket. Because the table is using the Iceberg spec, your downstream engines understand the manifest files, the snapshot history, and the schema evolution without you needing to do a single EXPORT job.
I’ve seen teams try to force this into every table they own. Don't do that. Managed Iceberg tables come with trade-offs.
First, the "Snowflake-managed" label means exactly that. If you manually delete a Parquet file from your S3 bucket, Snowflake’s catalog will get corrupted. You cannot treat your underlying S3 storage as a playground. You must use Snowflake’s ALTER TABLE ... REFRESH command to sync metadata if you’ve been messing with the files outside of the Snowflake engine.
Second, consider your write patterns. If you have a high-frequency streaming ingestion (think 50,000 inserts per second), Snowflake’s native format is still optimized for that. Iceberg introduces overhead because it has to generate new manifest files for every transaction. If you try to run massive, small-batch transactions against an Iceberg table, you will see performance degradation compared to standard Snowflake tables.
The strategy I use is "Tiered Persistence." My high-velocity staging tables remain in the proprietary format. Once the data reaches a state of "rest" (e.g., daily aggregates or cleaned facts), I move them into Iceberg managed tables for long-term storage and cross-engine accessibility.
Photo by David Trinks on Unsplash
The most common pushback I hear is, "But if I use Iceberg, I lose the proprietary Snowflake performance features like Search Optimization or Clustering Keys."
Yes, you do. And that's the point. If you need Search Optimization for a dataset, that dataset is likely part of your core product loop. You should pay the premium for that. But for 80% of the data sitting in your warehouse—the cold data, the audit logs, the historical facts—you aren't actually using those features. You’re paying for them because you didn't have a choice. Now you do.
Another objection: "It introduces complexity in IAM roles and bucket policies."
True, setting up the STORAGE INTEGRATION and the EXTERNAL VOLUME is more work than just running CREATE TABLE. You need to manage bucket policies, trust relationships, and VPC endpoints. But welcome to being a senior engineer. If you’re complaining about setting up an IAM role once to save your company 40% on their storage bill and gain absolute portability, you’re in the wrong seat.
Finally, some fear that Snowflake will "deprioritize" Iceberg performance to push users back to native tables. My read on the market is the opposite. Snowflake is terrified of the "Databricks effect." They know they have to play nice with open standards or they become the new Oracle. Supporting Iceberg as a first-class citizen is their way of keeping you from leaving entirely.
The goal of a senior engineer isn't to be a fanboy of a specific platform; it's to build a resilient system. Using Snowflake-managed Iceberg tables gives you the best of both worlds: the operational ease of a SaaS warehouse and the architectural sovereignty of open storage.
Stop paying for storage hostage-taking. Start moving your production tables to Iceberg, configure your external volumes, and give your organization the option to pivot when the economics stop making sense. You get to keep your tooling, your query history, and your dashboards, but you stop being an indentured servant to a single vendor's storage format.
In this business, control is the only currency that matters. If you can’t move your data without a massive, multi-week project, you don't own your data. Fix that today.
Cover photo by Alex Pudov on Unsplash.