Las 5 palancas de optimización
La reducción de costos en Snowflake se logra en 5 áreas:
- Warehouse sizing — usar el tamaño correcto
- Tiempo de actividad — auto-suspend agresivo
- Eficiencia de queries — escanear menos datos
- Almacenamiento — limpiar lo que no se usa
- Serverless — elegir bien qué servicios usar
1. Right-sizing de Warehouses
El error más común: warehouses sobredimensionados.
-- Identificar warehouses subutilizados (bajo load pero mucho cómputo)
SELECT
warehouse_name,
ROUND(AVG(avg_running), 2) AS avg_queries_ejecutando,
ROUND(AVG(avg_queued_load), 3) AS avg_queries_en_cola,
ROUND(SUM(credits_used), 2) AS creditos_total_mes
FROM SNOWFLAKE.ACCOUNT_USAGE.WAREHOUSE_LOAD_HISTORY
WHERE start_time >= DATEADD('month', -1, CURRENT_TIMESTAMP())
GROUP BY 1
HAVING avg_queries_en_cola < 0.01 -- casi nunca hay cola
ORDER BY creditos_total_mes DESC;
Si avg_queries_en_cola es casi 0 y tienes un warehouse LARGE, considera bajarlo a MEDIUM o SMALL.
2. Auto-suspend óptimo
-- Para BI/consultas ad-hoc: suspensión rápida
ALTER WAREHOUSE bi_warehouse SET AUTO_SUSPEND = 60;
-- Para ingesta/ETL continuo: puede ser más largo
ALTER WAREHOUSE etl_warehouse SET AUTO_SUSPEND = 300;
-- Verificar warehouses que nunca se auto-suspenden
SELECT name, auto_suspend
FROM TABLE(RESULT_SCAN(LAST_QUERY_ID()))
WHERE auto_suspend = 0 OR auto_suspend IS NULL;
3. Optimización de Queries
Usar Cluster Keys
-- Tabla con muchos filtros por fecha → cluster key
ALTER TABLE ventas CLUSTER BY (fecha_venta, region);
Evitar SELECT *
-- MAL: escanea todas las columnas
SELECT * FROM tabla_grande WHERE fecha = '2026-01-01';
-- BIEN: solo las columnas necesarias
SELECT id, monto, producto FROM tabla_grande WHERE fecha = '2026-01-01';
Aprovechar el Result Cache
Los resultados de queries se cachean por 24 horas. Si la misma query se ejecuta de nuevo con los mismos datos, no consume cómputo.
-- Verificar si una query usó el cache
SELECT query_id, query_text, execution_status,
CASE WHEN execution_time = 0 THEN 'CACHE' ELSE 'COMPUTE' END AS fuente
FROM SNOWFLAKE.ACCOUNT_USAGE.QUERY_HISTORY
WHERE user_name = CURRENT_USER()
ORDER BY start_time DESC
LIMIT 20;
4. Limpiar Almacenamiento
-- Tablas con mucho espacio en Time Travel que podrían reducirse
SELECT
table_schema,
table_name,
ROUND(active_bytes / 1024 / 1024 / 1024, 2) AS active_gb,
ROUND(time_travel_bytes / 1024 / 1024 / 1024, 2) AS time_travel_gb,
ROUND(failsafe_bytes / 1024 / 1024 / 1024, 2) AS failsafe_gb,
data_retention_time_in_days
FROM SNOWFLAKE.ACCOUNT_USAGE.TABLE_STORAGE_METRICS
WHERE table_schema != 'INFORMATION_SCHEMA'
ORDER BY (time_travel_bytes + failsafe_bytes) DESC
LIMIT 20;
-- Reducir retención en tablas transitorias o de staging
ALTER TABLE staging.raw_events SET DATA_RETENTION_TIME_IN_DAYS = 0;
5. Resumen: Quick Wins
| Acción | Ahorro típico | Complejidad |
|---|---|---|
| Bajar auto_suspend a 60s | 20-40% en warehouses idle | Muy baja |
| Right-sizing warehouses | 30-50% en WH sobredimensionados | Baja |
| Agregar cluster keys en tablas grandes | 40-80% en queries de rango | Media |
| Reducir DATA_RETENTION en staging | 10-20% en storage | Baja |
| Usar tipos de tabla TRANSIENT en staging | 15-25% en storage | Media |
Conclusión
FinOps en Snowflake es un proceso continuo. Las organizaciones maduras revisan ACCOUNT_USAGE semanalmente, tienen Resource Monitors por equipo, y hacen chargeback mensual con Query Tags.