10 mejores prácticas para optimizar recursos en Snowflake

Snowflake es elástico — y esa elasticidad puede costarte caro si no operas con disciplina. Estas son las 10 prácticas que aplicamos en cada engagement de optimización.

1. Dimensiona warehouses por carga, no por suposición

El error más común: usar un Large o X-Large “por si acaso”. Snowflake cobra por segundo activo desde el segundo 0. Un Large cuesta 8× más que un X-Small.

Regla: empieza con el warehouse más chico que pueda correr tu query en menos de 60s. Si necesitas más, escala.

2. Activa auto-suspend agresivo

Por default Snowflake suspende un warehouse después de 10 minutos sin actividad. Para warehouses de carga interactiva (BI), bájalo a 60 segundos:

ALTER WAREHOUSE bi_wh SET AUTO_SUSPEND = 60;

Para warehouses de ETL/ELT donde queries son secuenciales, 30 segundos suele ser óptimo.

3. Separa cargas por tipo de workload

No mezcles ETL, BI y data science en el mismo warehouse. Cada workload tiene perfil distinto:

• ETL — cargas batch grandes, picos cortos → warehouse mediano con auto-suspend bajo
• BI — queries cortas frecuentes → warehouse chico con multi-cluster
• Data science — queries largas exploratorias → warehouse grande on-demand

Aislarlos evita contención y permite optimizar cada uno independientemente.

4. Usa multi-cluster warehouses para concurrencia, no para velocidad

Multi-cluster escala horizontalmente cuando hay más queries que slots disponibles. NO acelera una query individual.

Configura MIN_CLUSTER_COUNT = 1 y MAX_CLUSTER_COUNT = 3 para BI con picos. Activa SCALING_POLICY = 'ECONOMY' (no 'STANDARD') si quieres priorizar costo sobre latencia.

5. Cluster por la columna que más filtras

Las clustering keys organizan micro-particiones por una o varias columnas. Si tu tabla tiene 1B filas y siempre filtras por event_date, clusterizar por event_date reduce el escaneo de filas en 10×–100×.

ALTER TABLE events CLUSTER BY (event_date, customer_id);

Monitorea con SYSTEM$CLUSTERING_INFORMATION('events') y reclustera solo si el ratio cae por debajo de 0.3.

6. Aprovecha Query Result Caching

Snowflake cachea el resultado de queries idénticas durante 24h sin costo de cómputo. Esto significa que si tu dashboard refresca cada 5min y la data no cambió, 0 créditos consumidos.

Diseña tus dashboards para que las queries sean determinísticas (sin CURRENT_TIMESTAMP() ni RANDOM() en el SELECT).

7. Usa Materialized Views solo donde aporten

Las MVs cuestan mantenimiento (Snowflake las actualiza en background) pero aceleran lookups frecuentes sobre tablas grandes.

Buena candidata para MV:

• Tabla base con 100M+ filas
• Query agregada que se ejecuta cientos de veces al día
• Cambios poco frecuentes en la tabla base

Mala candidata: tablas que se actualizan constantemente o queries que se ejecutan una vez al día.

8. Resource Monitors son obligatorios

Configura monitors a nivel cuenta y por warehouse para prevenir sorpresas en la factura:

CREATE RESOURCE MONITOR monthly_limit
  WITH CREDIT_QUOTA = 5000
  TRIGGERS
    ON 80 PERCENT DO NOTIFY
    ON 100 PERCENT DO SUSPEND
    ON 110 PERCENT DO SUSPEND_IMMEDIATE;

Notifica al 80%, suspende al 100%, suspende inmediato al 110%. Sin esto, una query errónea puede gastar miles de USD en minutos.

9. Audita queries caras con QUERY_HISTORY

Snowflake guarda 1 año de historial. Top 10 queries más caras del último mes:

SELECT
  query_text,
  user_name,
  warehouse_name,
  total_elapsed_time / 1000 AS seconds,
  credits_used_cloud_services AS credits
FROM snowflake.account_usage.query_history
WHERE start_time >= DATEADD(month, -1, CURRENT_TIMESTAMP())
ORDER BY credits DESC
LIMIT 10;

Estas 10 queries probablemente representan 30-50% de tu factura. Optimizarlas (mejor predicate pushdown, particiones, MVs) puede recortar el costo total en 20%+.

10. Adopta dbt para gobernar transformaciones

Sin un orquestador, las transformaciones se vuelven scripts dispersos sin lineage ni tests. dbt te da:

• Modelos versionados en git
• Tests automáticos (unique, not_null, custom)
• Documentación generada
• Lineage visual

Y dbt sabe cómo optimizar Snowflake: usa transient tables para staging, incrementales para tablas grandes y cluster automáticamente cuando lo defines en el yml.

---

El meta-tip

Mide antes de optimizar. Snowflake expone todo en ACCOUNT_USAGE y INFORMATION_SCHEMA. Si no sabes cuánto cuesta cada warehouse, cada query, cada usuario — estás operando a ciegas.

Construye un dashboard de FinOps de Snowflake en Tableau o Power BI desde el día 1. Es la inversión con mayor ROI que harás en tu Data Cloud.