Why Iceberg Still Is Not the Default on Snowflake, BigQuery and Redshift, Heard Directly From the Snowflake Field

The answers to the closed-format question took me by surprise

Last week I asked a narrow question, in a blog and then in a LinkedIn post. Two years after the Apache Iceberg™ announcements, why do Snowflake, BigQuery and Redshift still create every new table in a closed format unless the customer changes a setting? And why has none of them published a roadmap or a date for an open default? The post reached 116K people and drew 89 comments. About 36 of the 904 engagements came from Snowflake.

I expected one of two reactions. Silence, or the line we have all heard on stage: over time, everyone ends up on Iceberg.

I got neither. Snowflake’s field showed up and defended the closed format on its merits. Solutions engineers and solutions architects, a partner solutions engineer, a cloud operations engineer and members of its data and AI field team, plus a few commenters who did not state an affiliation but argued the same case. An industry analyst, a cloud-vendor evangelist and a hyperscaler product lead joined them. Not one Snowflake comment said that everything will be Iceberg eventually. Not one offered a date.

I think that deserves a record. Marketing says one thing at a conference. The field says what a customer hears in a deal, and this thread is the clearest statement of the field position I have seen written down anywhere. It also settles something for anyone like me who has been holding their breath for open-format unification: it is not going to arrive on its own. The vendors with the most data have a working argument for keeping it closed, and they are comfortable making that argument in public. The default changes when customers ask for it loudly enough to change the business case, and right now they are not asking.

It is strange to have to say the next part out loud, but here it is. Give the open formats that do what Iceberg cannot yet do at least as much consideration as you give a closed warehouse format, so your data stays open. In practice that means Apache Hudi™ for performance-sensitive and mutable workloads, Delta Lake inside Databricks, and Lance or Vortex for multimodal data.

So here are the five arguments for closed formats, quoted verbatim and anonymized, and why each one leaves my original question standing.

Argument 1: closed is faster

“Performance is a large factor.” When asked how large: “A 10% difference can easily be 1 second depending on size and scale.” And: “I have customers where seconds do matter for their SLAs.”

“Enterprise customers pay us for speed and zero maintenance. Our native tables deliver sub-second queries and automatic tuning out of the box.”

Nobody backed this with a document. Snowflake’s own announcements say managed Iceberg performs on par with native tables. Our testing puts Apache Parquet™ within roughly 10% of closed formats on both Snowflake and BigQuery, and once the scan is done, the engine is the same. Managed Iceberg tables even keep their statistics in the same FoundationDB metastore as native tables. If native really is faster for some query shapes, then publish where Iceberg should not be used, in detail, so customers can plan around it. Without that, the field is selling a gap that the product announcements say is closed, and no one in the thread could point to a page that describes it.

Argument 2: closed gets features first, and open source is slow by committee

“It is because of ability to innovate at the speed of their choosing. Opensource tables are awesome and allows interoperability but downside is that they are Opensource meaning it takes a village of contributors to agree together to put new features on the roadmap and deliver it.”

“Many features from Snowflake are making their way gradually into Iceberg, at the speed of community consensus - for example, the FILE type that’s been in Snowflake for almost two years lands in Iceberg V4. IMO, this is the right way.”

“First-class integration with Secure Data Sharing, Horizon governance, Dynamic Tables, Streams & Tasks, Hybrid Tables, and many Cortex AI / advanced type features (some of which still lag or are unsupported on pure Iceberg).”

This is the honest argument, and I said so in the thread. A vendor can ship a vector type or a FILE type on its own format the week it is ready, and a community spec takes longer. I made the same point about Hudi in the last post. But look at what it does to the customer. Every feature that lands on the native format first pulls more data into that format, and that data has to migrate later, on the customer’s budget. The stated lag for FILE type is two years. A platform that was serious about an open default would treat that lag as a cost it owes its customers, and would say when it plans to close it.

Argument 3: open is opt-in, and opt-in is the mature position

“you can set the default table format to Iceberg at the account level and have been able to do so for months.” And: “I don’t think it makes sense to default everyone automatically to Iceberg, while still giving the choice to go all-in - best of both worlds.”

“why would any vendor retire and format, rather I would prefer giving all the choices to customer within the premise of value and openness !!” Later: “I believe in giving them choices with no lock in.”

“until adoption surpasses native it still makes no business sense to flip the default. Can you at least agree with that?”

One commenter stated the catch-22 plainly, and I appreciate the candor. The default stays closed until most customers choose open, and most customers will not choose open while the default is closed. A practitioner in the thread described how that plays out on the ground: “New tables quietly follow the default.” Several Snowflake commenters also told me Iceberg has won. If it has, the setting that decides where new data lands should say so. Choice among open formats defaults to Iceberg on every warehouse, with no technical argument offered. Choice between open and closed defaults to closed on every warehouse, on technical nuance. That asymmetry is the whole point.

Argument 4: customers do not care, and closed is simpler

“Many customers don’t want to manage IAM polices and configure their own storage security. Customers get choice.”

“Not all companies use or approve Iceberg.” Then: “Those customers might not care. Some might care because they want the possibility to adopt the strategy later. Some do care but things like governance and security controls prohibit them from using it.”

“Proprietary formats solve a different (and still very common) set of problems: operational simplicity, performance consistency, governance depth, and features that require tight coupling between storage, metadata, and compute.”

“‘Speed and zero maintenance’ beats the pants off of having to fine tune a race car every Monday morning to build a dashboard over coffee.”

Read the list of benefits again. Managed IAM, consistent performance, governance depth, zero maintenance. All of them come from Snowflake running the storage and the compute for you. None of them requires the bytes on disk to be in a format only Snowflake can read. I have competed with Databricks for more than eight years, so I do not say this lightly: Databricks serves a customer base of similar size with no closed file format at all, and makes the same simplicity promise. Simplicity is something the product delivers, and the file format plays no part in it. Snowflake may well be the simpler product. That still tells you nothing about closed versus Iceberg. And if simplicity is the real pitch for the native format, then the “we are open now” pitch of the last two years is the one that misled people, and that is the one to retire.

Argument 5: the real lock-in is somewhere else

“The real story here is not whether iceberg is default or not or even the table format. It is the catalog that manages & governs these tables that dictates how interoperable the platform is.”

“We never weaponized Iceberg against any oss platform.” And in the same comment: “We are the platform of choice because we make it very difficult for our customers to pick any other.”

“projects like Delta and Unity OSS… create an illusion of openness… This amounts to open-washing and misdirection.”

A good part of the Snowflake response was about Databricks. I agree that the catalog is a lock-in layer, and we have written about Unity Catalog’s Iceberg restrictions at length. But the conversation moving to catalogs does not make closed file formats acceptable. It adds a second layer to the same problem. And the comparison cuts the other way. If proprietary Delta is lock-in, a proprietary Snowflake format is lock-in too. Calling one “choice” and the other “open-washing” is a marketing distinction.

I take the point that Snowflake never weaponized Iceberg. What it did was market Iceberg to the moon and, it now seems, never intend to carry it all the way to the default. That lands on the grassroots open-source projects, Apache Hudi, ClickHouse, Apache Doris™ and others, that build high-performance formats in the open, because the standardization argument was used against them while the standard-bearer kept its own closed format. The mature position would have been to say: we need an open common denominator, we think it is Iceberg, and there will be several open and closed formats alongside it.

The supporting cast

The voices from outside Snowflake who defended closed formats went after the ask itself.

“It’s unrealistic and just plain naive to expect ‘retirement dates’ for native table formats.”

“deprecating a storage format from a codebase that was built around it is a mammoth task and demanding a vendor to do this is quite frankly a bit arrogant.”

“The push to all iceberg when you have 20k tables averaging 20k records is ludicrous.”

“by the time it would take to make that shift I bet the world will have moved on from Iceberg to the next anyways.”

Nothing I asked for breaks a workload or forces a migration. The ask is an open default for new tables, a roadmap, and a date. These same vendors hold open-source projects to that standard every day. One product leader in the thread, with no stake on either side, put the incentive more plainly than anyone from Snowflake did: “making it the default could also make it easier for those customers to use another engine on the same data… it may help explain why Iceberg is available as an option, while native tables remain the default and get new features first.”

In conclusion

I posted this at the end of the thread, and it still stands.

Thanks everyone for engaging. Here’s my closing take.

What I heard from Snowflake folks in this thread:

• Closed could be faster, so that matters.
• As explained in the blog, closed gets features first since it can change without committee consensus. Fair.
• Iceberg is a choice, and you opt in to it.
• Iceberg has won, and Delta’s proprietary and Catalog is the real lock-in.

Those still don’t add up.

• If Iceberg won, why is it still opt-in on Snowflake? Why should open format choices default to Iceberg, when open vs closed won’t default to open?
• If proprietary Delta is lock-in, why is a proprietary Snowflake format “choice”?
• If Iceberg is first-class, why does closed still get the performance and the features? Why not an Iceberg fork, so migration is easier later on?
• Yes, the lock-in conversation has moved to catalogs. But that does not mean we are okay with closed file formats.

I was not asking to break workloads tomorrow. The ask is the same standard we hold open source projects to: an open default, a roadmap, a date.

But it feels like we will have closed file formats for a while. This is a consequence of the fact that warehouses are successful businesses and great products, so users tolerate closed file formats. Credit to the Snowflake field for saying so in public. Their candor is the most useful thing to come out of the thread, and it is the reason I wrote this down.

Snowflake, BigQuery, Redshift and Iceberg: the questions people search for

Does Snowflake default new tables to Iceberg?

No. Snowflake creates new tables in its native closed format unless you change DEFAULT_METADATA_WRITE_FORMAT at the account, database or schema level, which has been possible since June 2026. Changing the default does not convert existing tables.

Do BigQuery and Redshift default to Iceberg?

No. Both support managed Iceberg tables, and both still create ordinary tables in their native storage. BigQuery ties vector and search indexes to standard tables; Redshift keeps new tables in Redshift Managed Storage. Neither has published a date for an open default. The previous post covers each vendor’s position in detail.

Are Iceberg tables slower than Snowflake native tables?

Snowflake’s own announcements claim parity for managed Iceberg tables, and in our testing Parquet lands within roughly 10% of closed formats on Snowflake and BigQuery. Snowflake’s field says native is faster for some SLAs, but has not published where. If you have a latency-sensitive workload, ask your account team for that document.

What did Snowflake’s field say about closed formats?

Five things, all quoted above: closed is faster, closed gets features first, Iceberg is opt-in and opt-in is the mature position, customers do not care and closed is simpler, and the real lock-in is the catalog. Nobody from Snowflake said everything will move to Iceberg eventually, and nobody offered a roadmap or a date.

What should a Snowflake, BigQuery or Redshift customer do about closed formats?

Check what format your new tables land in today. If you want to stay open, flip the default where the vendor allows it, ask for a written list of what you give up on Iceberg, and ask for a date. For workloads Iceberg cannot handle yet, consider other open formats over the vendor’s closed one: Apache Hudi for mutable and performance-sensitive data, Delta Lake inside Databricks, Lance or Vortex for multimodal data.