La factura de Snowflake también cuenta cómo está organizada tu empresa

La factura de Snowflake llega, ha subido y alguien pide al equipo de datos que optimice. La reacción es comprensible: hay un gasto visible y un equipo que conoce la plataforma. El riesgo aparece cuando damos el diagnóstico por decidido antes de revisar qué ha cambiado, porque ese mismo equipo puede estar ejecutando con bastante eficiencia unos requisitos que ahora resultan caros.

Un entorno siempre disponible, una carga más frecuente o un producto de datos compartido tienen detrás decisiones sobre el servicio que la empresa quiere ofrecer. Algunas seguirán justificadas; otras habrán perdido sentido sin que nadie las retire. La factura permite abrir esa discusión, pero los créditos consumidos no explican por sí solos si una decisión fue buena.

¿Qué explica realmente la factura de Snowflake?

Explica consumo y precio dentro de un perímetro, pero no determina por sí sola si estamos desperdiciando recursos. Para decidir qué optimizar hay que relacionar el gasto con el servicio que sostiene, quién exige ese servicio y quién puede cambiarlo.

Lo que el gasto revela y lo que todavía no sabemos

La documentación de Snowflake distingue cómputo, almacenamiento y transferencia de datos. Dentro del cómputo conviven warehouses que dimensiona el cliente, funciones serverless y servicios de la plataforma. Si el análisis se limita a las consultas de un warehouse, parte del coste quedará fuera; si además comparamos euros sin considerar el precio contractual del crédito, podemos confundir una variación de uso con una variación de precio.

Aclarado ese perímetro, sigue faltando el denominador que da sentido al gasto. Una factura mayor puede acompañar a más actividad, a una exigencia de servicio superior o a un desperdicio creciente. Las tres explicaciones requieren respuestas diferentes, y ninguna se deduce de una curva ascendente sin conocer qué sostiene.

FinOps ya está dentro de las decisiones de tecnología

La encuesta State of FinOps 2026 de la FinOps Foundation recoge 1.192 respuestas y declara representar más de 83.000 millones de dólares de gasto anual en la nube. En la pregunta sobre dependencia organizativa, con 523 respuestas, sitúa el 78 % de las prácticas FinOps bajo la organización del CTO o CIO. El informe mantiene la optimización de cargas y reducción de desperdicio como principal prioridad individual, a la vez que describe una ampliación hacia gobierno, planificación y valor tecnológico.

Es una encuesta de profesionales participantes, no un experimento causal ni un censo de empresas; tampoco mide exclusivamente Snowflake. Sirve para contextualizar cómo se organiza la gestión del gasto, pero no demuestra que mover un equipo bajo Tecnología produzca ahorro. A partir de ese contexto, podemos plantear una hipótesis organizativa: intervenir en las decisiones que generan consumo será más viable si quienes revisan el gasto pueden trabajar con quienes tienen autoridad para cambiarlas.

Esto importa en una situación bastante plausible: un área pide que su información esté disponible continuamente, mientras el presupuesto permanece en plataforma. Meses después, Finanzas exige bajar la factura y el equipo técnico recibe el objetivo sin autoridad para cambiar la disponibilidad. Puede encontrar mejoras, por supuesto, pero llega a la conversación con una parte de las decisiones bloqueadas.

Una exigencia de disponibilidad también se puede cuantificar

La relación se ve con números sencillos. Según la tabla de consumo de warehouses estándar Gen1 de Snowflake, un X-Small consume un crédito por hora de funcionamiento continuo y por clúster. Con esa tarifa técnica, mantener un único clúster durante 30 días completos supone 720 créditos; hacerlo durante ocho horas en cada uno de 22 días supone 176. La diferencia calculada es de 544 créditos, aproximadamente un 75,6 %.

Estas cantidades son un cálculo ilustrativo, no el ahorro observado en un cliente. Suponen exactamente esas horas de actividad, el mismo tipo de recurso y ningún consumo adicional; no incluyen almacenamiento, servicios serverless ni precio contractual. En una carga real cuentan también las reanudaciones: Snowflake documenta un mínimo de facturación de 60 segundos cada vez que se aprovisionan recursos. Por eso no basta con multiplicar la duración de las consultas y llamar al resultado factura.

El cálculo deja visible la decisión, pero no la resuelve. Si hay usuarios o procesos que necesitan ese warehouse fuera del horario reducido, apagarlo degradaría el servicio. Si nadie lo necesita y los registros de actividad lo confirman, mantenerlo encendido exigiría una explicación. Entre ambos extremos está el trabajo profesional: relacionar consumo, uso y compromisos antes de atribuir un porcentaje de ahorro a una configuración.

Asignar el coste cambia los incentivos

Snowflake describe mecanismos de atribución del consumo a departamentos y agrupaciones, incluidos recursos dedicados y compartidos. Esa visibilidad ayuda a reconstruir quién utiliza la plataforma, aunque no determina qué regla de reparto resulta justa. Mostrar a un equipo el gasto que genera y cargarlo contra su presupuesto son decisiones distintas, con efectos distintos sobre su comportamiento.

Imaginemos un producto de datos común utilizado por tres áreas. Si todo el coste recae sobre quien lo mantiene, ese equipo puede parecer caro precisamente por evitar que los demás dupliquen trabajo; si nadie ve el consumo porque está enterrado en una partida central, será más difícil discutir qué exigencias conviene retirar. El ejemplo es hipotético, pero el conflicto permite entender por qué una asignación técnicamente precisa puede producir incentivos poco razonables.

Hay razones para financiar ciertas capacidades de forma común cuando facilitan reutilización o reducen riesgo. Para valorar si ese presupuesto sigue justificado, necesitamos conocer su propósito, usuarios y nivel de servicio, además de identificar quién responde por su continuidad. Compartir presupuesto no debería hacer imposible revisar una decisión.

Matriz del coste defendible

La matriz del coste defendible convierte esa relación en cuatro preguntas. Es una propuesta de lectura del gasto elaborada para este artículo; no sustituye una atribución técnica ni demuestra ahorros.

Capacidad

Qué disponibilidad, frescura o volumen compra este consumo.

Autoridad

Quién puede modificar el requisito y asumir sus consecuencias.

Reparto

Quién usa la capacidad y qué regla explica su financiación.

Evidencia

Qué unidad de servicio y qué calidad permitirán valorar el cambio.

Un warehouse compartido puede justificar su coste si evita duplicaciones y presta un servicio necesario. Si el consumo es visible pero nadie puede renegociar el requisito, el bloqueo está en la autoridad para decidir. La matriz permite distinguir ese caso de una consulta ineficiente; ambos pueden coexistir y requieren intervenciones diferentes.

Showback ≠ chargeback. Mostrar el coste atribuido informa; cargarlo al presupuesto modifica quién lo soporta. Factura total ≠ coste unitario. Comparar eficiencia exige una unidad de servicio equivalente y una calidad comparable.

Ahorrar más puede significar producir menos valor

El coste por unidad de servicio ayuda a salir de la discusión sobre importes aislados, siempre que esa unidad represente trabajo comparable. En otro ejemplo puramente ilustrativo, gastar un 20 % más mientras el volumen de operaciones equivalentes crece un 50 % reduce el coste unitario un 20 %: la relación pasa a ser 1,20 dividido entre 1,50, es decir, 0,80. La factura sube y la eficiencia económica mejora bajo esas condiciones.

Ahora bien, si esas operaciones tienen distinta complejidad o el servicio empeora, la comparación pierde fuerza. También sería absurdo exigir a una investigación exploratoria el mismo patrón que a un proceso industrial estable. La unidad de medida necesita contexto y debe acompañarse de la calidad recibida; de otro modo, solo habremos sustituido un número engañoso por otro más elaborado.

Una capacidad de recuperación, un entorno de pruebas o un margen de rendimiento pueden merecer su coste aunque no estén ocupados continuamente. Para defenderlos hace falta relacionarlos con un riesgo o una necesidad concreta, del mismo modo que para retirarlos hace falta comprender la alternativa. Mantener todo «por si acaso» y recortar todo lo que parezca inactivo son dos formas de evitar ese análisis.

La conversación conecta con los problemas de datos que requieren decisiones más allá de la tecnología. Una revisión de costes debería permitirnos salir sabiendo qué gasto sostiene qué capacidad, quién puede modificarla y cómo comprobaremos el efecto. Entonces optimizar deja de ser una orden genérica y se convierte en una decisión que alguien puede defender.