El costo del data warehouse es la partida de infraestructura de datos que más crece sin que nadie haya decidido que creciera. Nadie aprueba un aumento del 40% en la cuenta de Snowflake o BigQuery: ocurre consulta a consulta, cuando más gente usa el dato y más modelos corren cada hora. Cuando la factura llega a finanzas, la causa ya está repartida entre cientos de objetos y de responsables.
La respuesta de muchas empresas es recortar licencias o pausar proyectos. No resuelve, porque el gasto rara vez está donde el recorte es fácil. Este texto trata el FinOps de datos como práctica de ingeniería: atribuir el costo a un responsable, medir por modelo y actuar sobre las pocas palancas que concentran el desperdicio.
Por qué la cuenta del warehouse crece más que el presupuesto
El consumo de un warehouse crece con la adopción, y la adopción es justamente lo que la empresa quiere. Más dashboards, más modelos, más agentes consultando tablas: todo eso es costo variable. El presupuesto del equipo de datos, en cambio, casi siempre es fijo y se define una vez al año.
El desajuste aparece en los números. Según el relevamiento State of Analytics Engineering 2026 de dbt Labs (363 profesionales, abril de 2026), el 57% reportó aumento de gasto en warehouse y cómputo, mientras que el 36% reportó aumento del presupuesto del equipo. Citamos el dato a través del análisis de eCorpIT, porque no pudimos acceder al informe original; tómelo como indicador de dirección, no como medida precisa.
Dos factores lo agravan. El primero es que el precio unitario parece pequeño: entre US$ 2 y US$ 4 por crédito en Snowflake según la edición, y US$ 6,25 por TiB leído en BigQuery bajo demanda, según precios de lista de agosto de 2026. El segundo es que la cuenta ya no es solo del warehouse. El costo ahora incluye serverless, almacenamiento, transferencia y consumo de tokens de IA, y un panel que mira solo los créditos del warehouse ve una parte del total.
El costo del warehouse no explota por una consulta mala: crece porque nadie es responsable del gasto de cada modelo.
Primero la atribución: sin responsable no hay optimización
La primera palanca no reduce un centavo y aun así va antes que las demás. Sin saber quién generó cada parte del gasto, cualquier optimización se vuelve negociación política. El equipo de datos recorta lo que cree caro, el negocio se queja de la lentitud y la cuenta sigue subiendo.
La práctica mínima de atribución tiene cuatro pasos:
- Un warehouse (o proyecto) por carga de trabajo. Separar ingesta, transformación, BI y exploración ad hoc permite ver cuánto cuesta cada uno y dimensionar cada uno como corresponde.
- Etiqueta de costo por responsable y por dominio. Todo warehouse, schema y job necesita un responsable con nombre. Objeto sin etiqueta es objeto sin dueño.
- Showback antes que chargeback. Mostrar al equipo cuánto gasta, sin cobrarle, ya cambia el comportamiento. El cobro interno solo entra cuando la atribución es estable; la misma lógica vale para el cobro de inferencia de IA, que tratamos en FinOps de IA.
- Revisión mensual de 30 minutos. Los diez modelos o consultas más caros del mes, con el responsable presente. Casi siempre la lista se repite de un mes a otro, lo que es buena noticia: el objetivo es pequeño.
En proyectos que acompañamos, la distribución suele ser la de siempre: una fracción pequeña de los modelos responde por la mayor parte del gasto. Es una estimación nuestra, no un dato de mercado, y es lo que hace rentable la revisión mensual.
Las cinco palancas que concentran el ahorro
Con la atribución en su lugar, la optimización deja de ser intuición. En orden creciente de esfuerzo, estas son las palancas que más rinden en un warehouse en la nube.
Rightsizing por prueba de tiempo. Un warehouse mayor no es solo más caro: solo vale la pena si reduce el tiempo de ejecución en la misma proporción. El handbook de datos de GitLab usa un criterio simple: bajar un tamaño solo es eficiente si el tiempo de ejecución cae al menos un 40%. En su ejemplo, una mejora del 20% de velocidad que cuesta 60% más es ineficiente. Pruebe cada carga en los dos tamaños y elija por costo por ejecución.
Auto-suspend agresivo. Snowflake cobra por segundo de ejecución, con un mínimo de 60 segundos por activación. Un warehouse de transformación que queda encendido entre una ejecución y otra solo quema créditos. Empiece en 60 segundos y aumente únicamente en cargas interactivas, donde el caché caliente compensa.
Materialización incremental. Un modelo que reprocesa toda la tabla en cada ejecución es el desperdicio más común en un proyecto con dbt. Un caso publicado por Hightouch relata que pasar un modelo cuello de botella a incremental recortó cerca de 10 créditos por día; combinado con un downsize, ahorró miles de dólares al mes. La ganancia depende del proyecto, pero la regla es general: las tablas grandes con clave de fecha piden carga incremental.
Revisión de consultas recurrentes. Dashboards que se actualizan cada 15 minutos para un público que mira una vez al día, y consultas con SELECT * sobre tablas anchas, son el equivalente analítico de dejar la luz encendida en una sala vacía. En BigQuery, donde el costo es por dato leído, particionar y agrupar tablas cambia el gasto directamente.
Separar lo que necesita warehouse de lo que no. No toda transformación exige el cómputo más caro. dbt Labs anunció en el dbt Summit 2026 Lake Compute, todavía en beta privada, justamente porque la mayoría de las empresas ejecuta desde un modelo de staging simple hasta el join pesado en el mismo warehouse. Aun sin ese producto, formatos abiertos como Iceberg permiten mover cargas livianas a motores más baratos.
Cómo empezar sin frenar el roadmap
El FinOps de datos fracasa cuando se vuelve un proyecto paralelo, con equipo propio y plazo de seis meses. Funciona cuando entra en el ritmo normal del equipo de analytics. Una secuencia que cabe en un mes:
- Semana 1: separar warehouses por carga de trabajo y aplicar etiquetas de responsable.
- Semana 2: relevar los diez modelos y las diez consultas más caros del último mes, con un responsable junto a cada uno.
- Semana 3: aplicar rightsizing y auto-suspend a las tres cargas de mayor gasto; pasar a incremental los modelos candidatos.
- Semana 4: publicar el primer showback y agendar la revisión mensual.
Hay un límite importante: optimizar costo sin observabilidad de los pipelines es arriesgado. Un modelo que pasa a incremental y se equivoca en la lógica de merge ahorra crédito y entrega dato errado. Todo cambio de materialización necesita una prueba de equivalencia contra la versión anterior.
El criterio que usamos para decidir cuánto invertir es práctico. Si el gasto del warehouse crece más rápido que el uso que sostiene, hay desperdicio estructural. Si crece en la misma proporción, el problema es de presupuesto, no de eficiencia, y la conversación correcta es con finanzas, no con el equipo de ingeniería.
Preguntas que siempre vuelven
Tres dudas aparecen en casi toda conversación sobre costo de warehouse.
¿Qué es el FinOps de datos?
FinOps de datos es la práctica de atribuir, medir y reducir el costo de procesamiento y almacenamiento de una plataforma de datos, con responsabilidad compartida entre ingeniería, analytics y finanzas. En la práctica, significa saber cuánto cuesta cada modelo, consulta y equipo, y actuar sobre las pocas palancas que concentran el gasto, en lugar de recortar presupuesto de forma lineal.
¿Cómo reducir el costo de Snowflake o BigQuery sin perder rendimiento?
Empiece por la atribución y luego aplique cinco palancas: rightsizing por prueba de tiempo, auto-suspend de 60 segundos, materialización incremental, revisión de consultas recurrentes y separación de cargas livianas. En Snowflake el foco es el crédito por ejecución; en BigQuery, el volumen de dato leído, que el particionamiento y el clustering reducen directamente. Pruebe cada cambio contra la versión anterior para no cambiar ahorro por dato errado.
¿Cuándo es saludable que aumente la cuenta del warehouse?
El aumento es saludable cuando acompaña el uso que genera valor: más usuarios activos, más decisiones apoyadas en datos, más productos de datos en producción. Es señal de desperdicio cuando la cuenta crece más rápido que el consumo útil, o cuando ningún responsable logra explicar los diez mayores ítems del mes. La prueba es la pregunta del responsable: ¿quién responde por este gasto?