Iceberg adoption empowers Firebolt and ClickHouse
Product manager at Firebolt on on scaling challenges and ACID compliance in OLAP databases
Iceberg matters because it turns the warehouse battle from a full database migration into a workload by workload bake off. ClickHouse is already far enough along to benefit from that shift, and Firebolt appears directionally aligned, but native storage still keeps an edge on tuning and raw efficiency. The practical trade off is simpler switching, with some performance loss that depends heavily on how well the Iceberg tables are written and maintained.
-
ClickHouse is no longer just talking about Iceberg. It now supports querying Iceberg through its DataLakeCatalog engine, and has added newer write support in beta or experimental form, which makes it increasingly viable as a query layer over lakehouse storage instead of only its own native format.
-
There is still a penalty versus native managed storage. The Firebolt interview is explicit that both ClickHouse and Firebolt lose a layer of storage specific optimization on Iceberg. In plain terms, native systems know more about how data was laid out, indexed, compacted, and cached, so they waste less work at query time.
-
The bigger bottleneck is often table hygiene, not the SQL engine. Databricks and Snowflake both now support Iceberg and add management features like catalog APIs, compaction, and lifecycle tasks around Iceberg tables. That means open formats reduce lock in, but good performance still depends on who is maintaining metadata, file sizes, and layout quality.
The next step is a world where storage becomes standardized and query engines compete on speed, concurrency, governance, and cost instead of data gravity. That favors ClickHouse and Firebolt, but the winners will be the engines that can read Iceberg with near native performance while also matching incumbent warehouses on enterprise controls and operational polish.