El estado de la gestión de costos de Snowflake en 2026 (resumen del webinar)

• La plataforma de Snowflake se ha expandido mucho más allá del cómputo y el almacenamiento, y cada servicio nuevo es un lugar más donde pueden esconderse los costos.
• Las funciones de IA de Cortex en Snowflake son potentes, pero también la forma más fácil de quemar miles de dólares por accidente. Un cliente gastó $60,000 en tres días por una consulta que debía ejecutarse en QA y terminó corriendo en producción.
• La visibilidad tiene que venir antes que la optimización. Los equipos siguen encontrando workloads que cuestan cientos de miles de dólares al año y que nadie sabía que existían.
• Las mejoras con mayor ROI suelen ser simples: ejecutar los jobs con menos frecuencia y hacer right-sizing de los warehouses, no reescribir consultas.
• Escalar la gestión de costos en una organización en crecimiento implica darles a los equipos su propia visibilidad, no canalizar cada pregunta de costos a través de un solo equipo central.

Antes, Snowflake era sinónimo de cómputo y almacenamiento. Ese ya no es el panorama completo. Ian y Dave repasaron la lista creciente de servicios que los clientes ejecutan hoy en la plataforma: apps nativas, apps de Streamlit, modelos de machine learning desplegados en compute pools, un conjunto de capacidades de IA en rápido crecimiento e incluso workloads de Postgres tras la adquisición de Crunchy Data por parte de Snowflake.

Cada uno de estos aparece como una nueva línea en la factura. Eso crea un problema real de seguimiento: si tu configuración de monitoreo no sabe que existe un nuevo servicio, simplemente no verás lo que cuesta. SELECT mantiene un equipo de casi 30 engineers cuyo trabajo es exclusivamente mantenerse al día con los lanzamientos de Snowflake, de modo que las nuevas fuentes de costo reciben soporte apenas salen, y no meses después.

Dave agregó que esto no es solo una molestia técnica. Los líderes toman cada vez más decisiones sobre dónde deberían ejecutarse los workloads, y no pueden hacerlo sin una transparencia real de costos que las respalde.

Las funciones Cortex de Snowflake (ahora llamadas AI SQL) te permiten ejecutar IA directamente sobre los datos que viven dentro de Snowflake. El ejemplo de Dave: filtrar reseñas de productos para quedarte solo con aquellas donde el cliente expresó frustración, en una sola consulta. Hace unos años, eso significaba personas revisando y etiquetando cada registro a mano.

Esa comodidad trae un riesgo real. Dave compartió el caso de un cliente: una consulta con una función de Cortex incluida debía ejecutarse en QA. En cambio, corrió en producción contra el dataset completo y quemó $60,000 en tokens en tres días, sin nada útil a cambio.

Ian explicó por qué esto ocurre con tanta facilidad. El uso de IA se factura por tokens de entrada y tokens de salida. Los tokens de entrada son más o menos predecibles de antemano, ya que puedes estimar el tamaño de lo que le das al modelo. Los de salida no, porque cuánto genera el modelo depende de la pregunta misma. Esa asimetría es lo que hace que los costos de IA sean tan difíciles de pronosticar antes de ejecutar algo.

¿Cómo lograr visibilidad del gasto en IA en Snowflake?

El esquema de account usage de Snowflake incluye varias vistas para IA. La mayoría funciona como las demás vistas de account usage, con el uso por hora desglosado por modelo. La vista de uso de AI SQL es a nivel de consulta: puedes ver el modelo utilizado y el texto de la consulta, aunque no el prompt en sí. La opción más granular es la tabla de eventos de AI observability. Se accede mediante una función de tabla en lugar de una vista estándar, y puede mostrarte los prompts que originan el uso. Suele ser más lenta de consultar y, según entiende Ian, no es persistente, lo que dificulta el análisis de largo plazo.

¿Los budgets y quotas de IA de Snowflake realmente frenan el gasto descontrolado?

En su mayoría, con una excepción importante. Los budgets de IA te permiten establecer un límite mensual de créditos para una cuenta o un grupo de objetos etiquetados, cubriendo Cortex agents, Cortex search y funciones de IA, y te avisan cuando se excede ese límite. Las quotas por usuario van más allá y bloquean el uso, aunque la restricción tarda unos minutos en aplicarse en lugar de detener una consulta al instante.

El punto débil: una sola petición grande todavía puede superar el límite antes de que el sistema reaccione. El ejemplo de Ian fue ejecutar una función de análisis de sentimiento sobre una tabla enorme de reseñas de una sola vez. Podrías gastar $10,000 y solo se bloquea la siguiente consulta. Aun así, las quotas frenan los casos repetidos o los que corren durante todo un fin de semana, e Ian dijo que, si hay una sola cosa que llevarse de la sesión, es configurarlas. Pero no reemplazan las buenas prácticas, como probar en QA con datasets limitados antes de tocar producción.

¿Cómo medir el ROI del gasto en IA?

No hay una fórmula universal. Empieza por el lado que puedes medir con precisión: el costo. Para el lado del valor, depende del caso de uso. Si la IA reemplaza algo que ya existía, como un equipo que clasificaba el sentimiento manualmente, compara el costo anterior en tiempo y cómputo con el nuevo. Si habilita algo nuevo, por lo general trabajarás con indicadores indirectos: tiempo ahorrado, velocidad de tickets o historias en un sistema como Jira, o ingresos recuperados. Cuando nada de eso da una respuesta clara, la sugerencia de Ian fue directa: apágalo y mira quién se queja.

Antes de cualquier trabajo de optimización, necesitas saber cuánto cuestan realmente las cosas. Ian compartió el ejemplo de un cliente que inició sesión en SELECT por primera vez y encontró, en lo más alto de su lista, un workload que costaba $850,000 al año, generado en gran parte por una función de IA que corría dentro de lo que resultó ser un job de QA. Lo apagaron. No hizo falta ninguna investigación profunda, porque la visibilidad por sí sola reveló la solución.

La versión de Dave de la misma lección: un cliente que gastaba $10,000 al año solo para enviar un correo desde Snowflake. Bastó una mirada al costo real para mover ese workload a un lugar más barato. También escucha todo el tiempo "pensé que había apagado eso hace tres meses" cuando los clientes ven por primera vez los costos consulta por consulta y workload por workload.

Una vez que tienes visibilidad, la siguiente pregunta es si una optimización vale tu tiempo. Dedicar un día de ingeniería para ahorrar $500 en almacenamiento es un mal negocio. Dedicar unas horas para ahorrar $20,000 es un sí rotundo. El consejo de Ian: haz ese cálculo antes de empezar y aprovecha primero las mejoras rápidas antes de reescribir cualquier SQL.

¿Cuáles son las mejoras con mayor ROI una vez que sabes dónde mirar?

1. Ejecuta las cosas con menos frecuencia. Un job que corre cada hora y cuesta $10,000 al año baja a menos de $500 al año si solo necesita correr a diario: una reducción del 96% con un solo cambio de configuración. Incluso pasar de cada hora a cada tres horas ahorra aproximadamente dos tercios del costo.
2. Haz right-sizing de tu warehouse. Cada aumento de tamaño duplica el cómputo y el costo, así que un warehouse más grande solo vale la pena si el tiempo de consulta también se reduce a la mitad. El ejemplo de Ian: bajar un warehouse de ingesta de Large a Extra Small llevó el tiempo promedio de consulta de unos cinco segundos a unos veinte, un retraso que nadie notó, y ahorró $50,000 al año. Una heurística útil es de aproximadamente 125 particiones escaneadas por núcleo de CPU (un warehouse Large tiene 64 núcleos), así que una consulta que escanea solo 500 particiones rara vez necesita más que un Extra Small.
3. Cuidado con el patrón de usar Snowflake como cola de mensajes. Dave ha visto equipos usar Snowflake como una cola de Kafka, ejecutando millones de operaciones diminutas en lugar de las operaciones por lotes más grandes para las que está diseñado. Eso mantiene los warehouses corriendo sin parar y sale caro. Usa la tecnología adecuada para cada workload.
4. Considera el escalado horizontal, no solo el vertical. Dave señaló que la gente suele elegir un tamaño de warehouse y descuidar la cantidad de clústeres. Aumentar la cantidad de clústeres puede dar mejores resultados que simplemente aumentar el tamaño del warehouse, según el workload.
5. Usa agentes de código con IA para las reescrituras más difíciles. El ejemplo interno de Ian en SELECT: un dataset que se recreaba por completo en cada ejecución costaba más de $8,000 al año, y unas horas dedicadas a hacer la consulta incremental eliminaron ese gasto. Agregó que los agentes de código como Coco hoy hacen posible este tipo de reescritura en horas, cuando antes tomaba días.

Sobre la ingesta en particular, Ian dijo que suele representar entre el 10 y el 20% del gasto en cómputo, y esa proporción viene a la baja. Snowpipe Streaming ha reducido los costos de ingesta unas 10 veces para algunos clientes, y la adopción de Iceberg también ayuda. Los dos ahorros de ingesta más fáciles según Dave: trae solo las tablas y columnas que realmente necesitas, y ajusta la frecuencia de actualización a la necesidad real del negocio en lugar de buscar por defecto lo más cercano posible al tiempo real.

¿Los equipos están moviendo workloads a motores más baratos como DuckDB, o adoptando Iceberg para ahorrar?

A pequeña escala, a veces. Un solo engineer en una empresa más pequeña puede perfectamente dirigir workloads específicos a algo como DuckDB. A gran escala, con miles de usuarios que necesitan controles de acceso centralizados, es raro, porque resulta demasiado difícil de administrar. Dave dijo que nunca había pensado realmente en Iceberg como una medida de ahorro. Su atractivo es la interoperabilidad: puedes reutilizar los mismos datos desde muchos lugares sin gastar más cómputo. Ian agregó que Iceberg puede bajar los costos de ingesta y evita pagar dos veces por el almacenamiento, pero correr varios motores de cómputo sobre él no es algo que vea mucho. Dave dijo que lo que ve más a menudo son clientes moviendo workloads completos entre plataformas, como de Snowflake a Databricks o de Postgres a Snowflake y de vuelta, según lo que mejor encaje. Para él, se trata de conservar cómputo más que de optimizar almacenamiento.

Un único equipo central de datos respondiendo cada pregunta de costos no escala. Dave, que ha sido esa persona, describió cómo un equipo pequeño se convierte en cuello de botella cuando cada solicitud de datos pasa por él. La solución es empoderar a los usuarios finales con visibilidad de los costos que generan, para que cada quien actúe con responsabilidad sobre lo que gasta.

Eso empieza con la asignación de costos: mapear el gasto a los equipos responsables, de modo que la atención de las personas se concentre en lo que pueden controlar. Distintas audiencias también necesitan vistas distintas. Los ejecutivos generalmente quieren dashboards de alto nivel con el costo por grupo a lo largo de un día, una semana o un mes. Los especialistas quieren ver las cosas específicas que su propio equipo está ejecutando.

Que esa información sea fácil de consultar importa tanto como tenerla. Dave sugirió construir dashboards relevantes para cada audiencia, o dar acceso a un servidor MCP para que la gente pueda hacerle las preguntas correctas a Claude. Ian agregó que a veces los usuarios simplemente necesitan información curada en una interfaz fácil de usar: dámela servida, no me hagas ir a buscarla.

Un centro de excelencia tiene un rol real, pero acotado. El equipo central debería asesorar a los usuarios sobre cómo mejorar sus costos y difundir ese conocimiento por toda la organización, no asumir la responsabilidad de hacer cada optimización por su cuenta. Como dijo Ian, hacer estas cosas de forma individual en nombre de toda la organización solo te llevará hasta cierto punto.