Une micro-partition est le bloc de stockage interne de Snowflake : un fichier colonnaire compressé, typiquement 50 à 500 Mo une fois décompressé, écrit de façon immuable. Vous ne les créez pas. Snowflake les découpe à l’ingestion, en conserve les statistiques, et s’en sert pour ne pas lire ce qui ne peut pas répondre à la requête.
Chaque micro-partition stocke les colonnes séparément (comme du Parquet), plus un jeu de métadonnées dans les services cloud : minimum, maximum, nombre de valeurs distinctes, nulls, pour chaque colonne. Quand vous écrivez WHERE date_commande >= '2026-01-01', l’optimiseur compare ce prédicat aux min/max et élimine les blocs dont le maximum est en 2025. C’est le pruning. Vous ne voyez pas de PARTITION BY à poser pour que ça existe — contrairement à un lac Hive.
Les écritures ne mettent pas à jour un bloc : elles en ajoutent de nouveaux et invalident les anciens via les métadonnées. D’où Time Travel, d’où les clones zero-copy : on pointe vers d’autres ensembles de blocs, on ne réécrit pas la table.
Que vous reliez micro-partitions et performance perçue. Une table « bien clusterisée » naturellement — chargée déjà triée par date, filtrée ensuite par date — se prune toute seule. Une table dont les nouvelles lignes mélangent toutes les dates dans chaque bloc force un scan quasi complet : les min/max de chaque partition couvrent trop large. C’est là qu’on discute clustering key, pas « parce que c’est une best practice ».
La relance : « Combien de partitions a cette table ? » La réponse utile n’est pas un nombre magique, c’est INFORMATION_SCHEMA ou les vues de clustering : profondeur moyenne, chevauchement. Une table de 2 To en millions de tout petits blocs ou en quelques énormes blocs mal élagués se comporte mal pour des raisons opposées.
Ce n’est pas le partitionnement Hive (dt=2026-03-01/). Vous n’ajoutez pas une colonne de partition pour « faire comme sur Hadoop ». Snowflake partitionne tout seul ; votre levier, c’est l’ordre d’arrivée des données et, si besoin, une clustering key qui recopie cet ordre dans le temps.
Le contrepoint honnête : le pruning ne sauve pas une requête qui sélectionne 80 % des lignes ou qui applique une fonction sur la colonne filtrée (TO_DATE(varchar)). Les métadonnées portent sur la colonne stockée, pas sur l’expression. Dans le query profile, le ratio partitions scanned / partitions total est le chiffre à citer : c’est lui, plus que la taille du warehouse, qui dit si le stockage travaille pour vous.