El problema: coste creciente en entornos Snowflake
El modelo es simple:
- pagas por cómputo
- pagas por almacenamiento
Pero en la práctica:
- los warehouses se quedan activos
- las tablas acumulan histórico innecesario
- las consultas no están optimizadas
Resultado: la factura no cuadra con el uso esperado
La buena noticia:
en la mayoría de los casos hay margen de optimización sin rediseñar la arquitectura.
Configuración de warehouses: el mayor impacto en coste
Un virtual warehouse consume créditos mientras está activo, incluso sin ejecutar consultas.
Este es uno de los principales focos de gasto innecesario.
Recomendaciones:
- 60–300 segundos → cargas analíticas
- valores más bajos → pipelines ETL nocturnos
Tamaño del warehouse: coste vs rendimiento
Duplicar tamaño:
- duplica coste por hora
- reduce tiempo de ejecución
El coste total puede ser similar… o no.
Buenas prácticas:
- consultas pequeñas y concurrentes → warehouse pequeño + multi-cluster
- cargas batch → warehouse mayor + auto-suspend ajustado
Analiza siempre con QUERY_HISTORY
Indicadores clave:
- queued_overload_time alto → falta capacidad
- bytes_scanned bajo + consumo alto → gasto sin valor
Multi-cluster: no siempre es la solución
Los warehouses multi-cluster:
- escalan automáticamente ante concurrencia
- aumentan el coste
Úsalos solo si el problema es concurrencia real, no duración de consultas.
Result cache: rendimiento gratis
Snowflake mantiene una caché automática de resultados:
- duración inicial: 24h
- hasta 31 días si se reutiliza
Si la consulta no cambia → no consume créditos
Impacto real en:
- dashboards (Power BI, Tableau)
- reporting repetitivo
Además:
- caché de metadatos
- caché local de disco
Tres niveles de optimización automáticos
Clustering y micro-particiones
Snowflake organiza datos en micro-particiones (50–500 MB) con metadatos.
Esto permite evitar leer datos innecesarios (pruning)
Problema:
- si los datos no están ordenados → consultas más caras
Automatic Clustering
Permite reorganizar datos según columnas clave:
Métricas clave:
- average_overlaps
- average_depth
- bajos = buen clustering
- altos = consultas ineficientes
Importante: no aplicar clustering a todo, solo a tablas grandes con filtros frecuentes.
Tipos de tabla y Time Travel
Optimización clave: usar tablas transient en staging
Beneficios:
- elimina fail-safe
- reduce almacenamiento (hasta x2 en algunos casos)
DATA_RETENTION_TIME_IN_DAYS
En tablas de logs o alto volumen: reducir este valor evita acumular datos innecesarios
Vistas materializadas y Query Acceleration Service
Vistas materializadas
- precalculan resultados
- ideales para dashboards
Útiles cuando:
- consultas costosas
datos poco cambiantes
Query Acceleration Service (QAS)
Permite usar recursos serverless adicionales:
reduce necesidad de escalar warehouses permanentemente
Por dónde empezar (quick wins)
- activar auto-suspend y auto-resume
- revisar tamaño de warehouses
- usar tablas transient en staging
- reducir retención innecesaria
- crear resource monitors
- analizar QUERY_HISTORY
- separar cargas de trabajo
Conclusión
Las optimizaciones con mayor impacto en Snowflake no requieren rediseñar nada.
Los problemas más comunes:
- warehouses mal configurados
- uso incorrecto de tipos de tabla
- falta de control de costes
A partir de ahí:
- clustering
- vistas materializadas
permiten optimizaciones más avanzadas.
Primero optimiza lo básico. Luego escala.
¿Tu entorno de Snowflake está optimizado en coste y rendimiento?
En Bravent ayudamos a organizaciones a analizar, optimizar y escalar sus plataformas de datos, identificando rápidamente oportunidades de ahorro sin impacto en negocio.
📩 Escríbenos a info@bravent.net
