El almacenamiento frío en Snowflake es uno de esos temas que suele generar dudas entre ingenieros de datos: ¿puedo decidir qué parte de mi tabla se enfría?, ¿tiene impacto en los costes?, ¿afecta al rendimiento de mis consultas? La realidad es que Snowflake gestiona automáticamente esta capa, pero si entiendes cómo funciona, podrás diseñar tus tablas de forma más inteligente y ahorrar dinero sin perder velocidad.


En Snowflake, el concepto de “enfriar” datos (cold storage o mover a almacenamiento más barato/inactivo) no se aplica de forma manual por parte del usuario, ni a nivel de particiones de las tablas. Aquí te explico cómo funciona
Contenidos
¿Se puede “enfriar” parte de una tabla en Snowflake?
No directamente. Snowflake no permite enfriar partes específicas de una tabla.
La gestión del almacenamiento en caliente y frío es automática y abstracta para el usuario.
Snowflake internamente decide cuándo mover micro-particiones a almacenamiento de bajo coste (cold storage). Esto lo hace a nivel de micro-partición, pero sin intervención del usuario.
No podemos elegir si una parte concreta de la tabla se mantiene caliente o fría.
¿Cómo funciona la temperatura del dato en Snowflake?
Las tablas en Snowflake están divididas en micro-particiones columnarizadas e inmutables. Son unidades de almacenamiento contiguas (50 MB a 500 MB sin comprimir) con metadatos sobre rangos de valores, recuento de valores distintos y otros detalles que permiten optimizaciones y pruning eficientes.
- Snowflake monitoriza el acceso a esas particiones.
- Si una micro-partición no se accede durante cierto tiempo, puede ser movida a un storage más barato dentro del mismo backend de Snowflake.


Al acceder a particiones frías, Snowflake las rehidrata automáticamente (de forma transparente). El coste puede aumentar ligeramente en latencia o I/O, pero sin impacto funcional para el usuario.
De hecho, un análisis demuestra que, gracias al metadata disponible y optimizaciones de pruning, el motor de Snowflake puede descartar hasta el 99,4 % de las micro-particiones irrelevantes en operaciones comunes, lo que dramatiza la eficiencia del sistema.
Esto forma parte de su modelo de auto-clustering y auto-optimizaciones.
¿Qué puedes hacer tú para influir en esto?
1. Separar datos en tablas distintas (por fechas, estados, etc.)
Por ejemplo, creamos dos tablas para nuestros eventos: events_current y events_archive
La tabla de archivo se accederá poco, por lo que Snowflake enfriará automáticamente esas particiones.
Adoptar una estrategia de tiering moviendo datos fríos a almacenamiento externo como S3 Iceberg o Glacier también puede reducir tus costes de almacenamiento en hasta un 80%, sin perder capacidad de consulta gracias a las Tablas Externas de Snowflake.
2. Usar Time Travel y Fail-safe con cuidado
Los datos retenidos por Time Travel permanecen disponibles, aunque internamente pueden estar en cold storage.
Liberar estos datos cuando no se necesiten puede reducir el footprint de almacenamiento.
Importante tener en cuenta que Snowflake factura todo el almacenamiento, incluso el de Time Travel y Fail-Safe. Así que aunque los datos estén “fríos” o eliminados, permanecerán facturándose hasta que expiré el retenido o Drop final.
3. Optimizar el diseño de tablas particionando lógicamente
Aunque no defines particiones como tal, puedes usar columnas tipo event_date o status para permitir pruning eficiente.
Así, Snowflake accede solo a las micro-particiones necesarias y el resto se pueden mantener frías.





