Apache Iceberg est un format de table ouvert (snapshots, manifests, évolution de schéma, time travel) au-dessus de fichiers colonnaires. Snowflake comme Databricks savent lire et, de plus en plus, écrire Iceberg. Ça réduit l’argument « si j’entre chez l’un, je ne sors plus mes tables ». Ça n’annule pas le choix de plateforme : le moteur, le catalogue, l’identité et le réseau restent différents.
Vous pouvez poser une table Iceberg sur S3/ADLS/GCS et la faire lire par un warehouse Snowflake (Iceberg tables, catalogue externe ou Snowflake comme catalogue) et par Spark / Databricks (support Iceberg natif, UniForm côté Delta selon les versions). Un partenaire Trino ou Flink peut s’y brancher sans COPY INTO. La stratégie de sortie n’est plus « tout décharger en CSV ». Les équipes qui refusent un lock-in de format ont enfin un contrat technique à poser dans l’architecture.
Les clones, Time Travel, MERGE existent dans l’idée Iceberg comme dans Delta ou les tables natives Snowflake — avec des dialectes et des limites (quels types, quels identifiants de snapshot, qui compacte).
Le calcul reste propriétaire. Une jointure lourde sur Snowflake n’a pas le même plan, le même spilling, le même crédit qu’un SQL warehouse Photon ou qu’un job Spark. Ouvrir le format n’ouvre pas le moteur.
Le catalogue est le nouveau lock-in. Qui est la source de vérité des snapshots : le catalogue REST Iceberg, Unity Catalog, le catalogue Snowflake, AWS Glue ? Deux écrivains mal coordonnés corrompent une table ouverte aussi sûrement qu’une table fermée. Iceberg exige un seul writer (ou un protocole soigné), pas un far west de notebooks.
L’egress et la copie. Lire Iceberg « en place » depuis Snowflake dans une région alors que le seau est dans une autre, ou croiser deux clouds, reste une facture réseau. Iceberg n’est pas un sharing Snowflake : pas de share magique sans aligner comptes, rôles et régions.
La gouvernance. Unity Catalog et le RBAC Snowflake ne se fusionnent pas parce que les fichiers sont Iceberg. Masking, audit, lineage : vous enchaînez encore deux piles, ou vous en désignez une comme contrôleur.
Que vous ne concluez ni « Iceberg rend Databricks inutile » ni « Iceberg tue Snowflake ». Vous concluez : on choisit où s’exécute quelle charge, qui compacte, quel catalogue est maître, et quel moteur a le droit d’écrire. Le format ouvert est une option de portabilité, pas une architecture.
La relance : « Delta ou Iceberg chez nous ? » Réponse honnête : si tout le monde est déjà Databricks et Unity, Delta (éventuellement UniForm vers Iceberg) peut suffire. Si le comité exige un format neutre et plusieurs moteurs, Iceberg en source of record sur le lac, avec Snowflake en consommateur SQL, est un schéma répandu — à condition d’avoir tranché l’écrivain unique.