Reducir factura de Dagster Cloud un 60%: así lo logró Narev

En mayo de 2026, Dagster Cloud sacudió el tablero con un cambio de pricing que eliminó los créditos mensuales y empezó a cobrar por cada materialización de asset. Para el equipo de Narev, la factura mensual se fue al carajo—bueno, no al carajo, pero sí a números que hacían doler—hasta que encontraron la vuelta: colapsar todos los assets de dbt en uno solo. ¿El resultado? Un recorte del 60% en la factura de orquestación, sin tocar una línea de lógica de transformación y sin migrar a Airflow.

Dagster Cloud es la plataforma de orquestación de datos como servicio de Dagster Labs. Permite definir, ejecutar y monitorear pipelines de datos mediante assets, y su modelo de precios cambió en mayo de 2026: pasó de incluir una cantidad fija de créditos mensuales a cobrar aproximadamente USD 0.035–0.040 por cada materialización de asset que se ejecuta. Para equipos con cientos de modelos dbt corriendo cada hora, el golpe fue inmediato.

¿Por qué aumentó el costo de Dagster Cloud en mayo 2026?

Hasta abril de 2026, los planes Solo y Starter de Dagster Cloud incluían una asignación mensual de créditos que cubría la mayoría de los casos de uso chicos y medianos (workspaces de USD 10 a USD 100 por mes, ponele). Pero en mayo de 2026, Dagster Labs eliminó ese crédito mensual y pasó a facturar por cada paso de materialización de asset ejecutado. El costo por crédito ronda los USD 0.035–0.040.

Lo que antes era un gasto fijo predecible se convirtió en una factura variable que, para equipos con schedules 24/7 y un par de cientos de modelos dbt, escaló a cientos o incluso más de mil dólares al mes. (Sí, en serio.)

Acá es donde muchos se plantearon alternativas. El propio equipo de Narev confiesa que self-hostear Airflow empezaba a verse tentador—hasta que auditaron su setup y encontraron una optimización masiva que no requería cambiar de orquestador.

¿Cuál fue el error común que disparó la factura?

La funcionalidad @dbt_assets es hermosa en la teoría. Cargás tu proyecto dbt, y Dagster te mapea cada modelo, seed y snapshot como un nodo individual en la UI, con su lineage, su estado, su historial de ejecuciones. Es el ideal de cualquier data engineer que quiere visibilidad granular. Sobre eso hablamos en nuestra guía de CI/CD publicada en enero de 2026.

El problema es que, bajo el nuevo modelo de pricing, cada uno de esos nodos dispara una materialización facturable. Si tenés 200 modelos dbt corriendo en particiones horarias, estás quemando créditos solo para que Dagster diga “sí, dbt construyó esta vista”. Multiplicá 200 materializaciones por 24 ejecuciones diarias por 30 días y sacá la cuenta—te vas a los cientos de dólares sin pestañear.

La ironía es que dbt ya sabe resolver el orden de ejecución de los modelos. Dagster estaba duplicando esa inteligencia con un costo adicional cada vez más alto.

¿Cómo colapsar los assets dbt en un solo comando?

La solución que implementó Narev es de una simpleza que sorprende no haberla visto antes: reemplazar @dbt_assets por un único @asset que ejecuta dbt build usando DbtCliResource. Misma lógica dbt, mismos datos, muchísimos menos pasos de orquestación facturables.

El asset refactorizado tiene esta pinta:

Un único asset recibe el contexto de ejecución, define el target y las variables según la partición activa, y llama a dbt_resource.cli(["build"]).wait(). Nada más. Done. Todo el proyecto dbt se ejecuta como un solo bloque desde la perspectiva de Dagster, y por lo tanto se factura como una sola materialización por ejecución (no 200).

¿La factura? Pasó de cifras de cuatro dígitos a unos cientos de dólares. Un recorte del 60% que, para un equipo que corre 24/7, no es poca plata a fin de año. Para más detalles técnicos, mirá la comparativa real de Jenkins y GitHub publicada en marzo de 2026.

¿Qué precaución clave evitar al implementar la solución?

Acá viene el detalle que te puede arruinar el ahorro si no le das bola. El equipo de Narev descubrió algo fundamental: no le pasés el argumento context a dbt_resource.cli().

Si lo hacés, Dagster sigue emitiendo eventos de materialización por cada modelo dbt individualmente, anulando por completo el beneficio del colapso. Es como si le dijeras al mozo que vas a pedir menú ejecutivo pero después le pedís que te cobre cada plato por separado. Usá .wait() en lugar de .stream(), y asegurate de que el AssetExecutionContext no se filtre al recurso CLI.

Testealo en un entorno de staging antes de mandarlo a producción: la diferencia entre una factura que sigue escalando y una que se aplana está en ese argumento.

¿Qué se pierde al usar un solo asset?

Toda optimización de costos tiene su trade-off, y esta no es la excepción. Al colapsar todo en un único asset, la UI de Dagster deja de mostrar el lineage por modelo. Ya no ves que stg_orders alimenta a int_order_lines y eso a fct_sales. Lo que ves es un solo nodo gigante que dice “dbt build” y si falla algo, falla todo el asset de una.

Las alertas también se vuelven más gruesas: un modelo roto marca en rojo el asset entero, y te toca bucear en los logs de dbt para encontrar al culpable. Si tu equipo ya usaba dbt docs o la documentación del warehouse para el lineage, y solo necesitaba saber que la transformación se completó sin errores, la pérdida es mínima. Si dependías de la UI de Dagster para debuguear fallos y rastrear dependencias, vas a extrañar la granularidad. Relacionado: el secreto del SEO internacional.

Comparativa: @dbt_assets vs @asset colapsado

Característica	@dbt_assets (nativo)	@asset colapsado
Nodos en UI de Dagster	Uno por modelo dbt	Uno solo para todo el proyecto
Materializaciones facturables	1 por modelo, por ejecución	1 por ejecución total
Costo mensual estimado (200 modelos, 24/7)	Significativamente más alto	Significativamente más bajo
Lineage visible en Dagster	Completo, por modelo	No disponible (usar dbt docs)
Alertas	Granulares, por modelo	Una sola alarma para todo el proyecto
Debugging de fallos	Inmediato en UI	Requiere revisar logs de dbt
Complejidad de implementación	Baja (configuración estándar)	Media (refactor manual, cuidado con context)

¿Vale la pena esta optimización para tu equipo?

Depende de cuánto te duela la factura y qué tanto uses la UI de Dagster para monitoreo fino. Según la experiencia de Narev, el cambio es un golazo si tu equipo cumple con estos criterios:

• Usás dbt docs para lineage y documentación: entonces no necesitás que Dagster te duplique esa visualización.
• Tu schedule es frecuente (horario o diario con muchas particiones): cada materialización cuenta, y el ahorro se multiplica rápido.
• Tenés muchos modelos dbt: 50 modelos corriendo una vez al día no es drama; 200 modelos 24/7 es donde el colapso brilla.
• Solo necesitás saber que la transformación se completó: si tu equipo confía en que dbt maneja el orden y solo querés un semáforo verde/rojo, estás en el escenario ideal.

Si dependés del monitoreo granular por modelo en Dagster para detectar regresiones temprano, esta estrategia te va a quitar visibilidad. Ahí habría que buscar un punto medio—colapsar por capas tal vez, o evaluar si self-hostear Dagster (open source) con un servidor propio te conviene más a largo plazo. Si te vas por ese camino, un VPS en donweb.com para correr Dagster open source puede ser una alternativa razonable sin atarte al pricing cloud.

Qué significa para empresas y equipos en Latinoamérica

El cambio de pricing de Dagster Cloud pega distinto cuando facturás en dólares y cobrás en pesos, soles o reales. Un workspace que pasó de costar decenas de dólares a cientos o incluso más de mil de un mes al otro no es un susto menor—es un riesgo real para equipos de datos chicos y medianos en la región.

La estrategia de colapsar assets es un parche efectivo, pero también expone una realidad: depender de un SaaS con pricing volátil sin tener un plan B es jugar con fuego. Equipos latinoamericanos que ya manejan dbt y Dagster hacen bien en tener documentado el lineage en dbt docs antes de que la factura los obligue a sacrificar visibilidad en la UI. Y si el pricing sigue escalando, tener la opción de migrar a Dagster open source auto-hosted sobre infraestructura propia o cloud local deja de ser una excentricidad y pasa a ser sentido común.

¿Qué está confirmado y qué está pendiente?

• Confirmado: Dagster Labs eliminó los créditos mensuales en los planes Solo y Starter en mayo de 2026, reemplazándolos por cobro por materialización ejecutada, según el artículo del equipo de Narev.
• Confirmado: El costo unitario ronda los USD 0.035–0.040 por crédito, basado en la experiencia del equipo de Narev (no en documentación oficial de precios, porque Dagster no publica tablas públicas detalladas).
• Confirmado: La técnica de colapsar assets con @asset + dbt build redujo la factura un 60% en el caso documentado.
• Pendiente: Dagster no se ha pronunciado oficialmente sobre si planea ajustar el modelo de precios o reintroducir créditos para assets que internamente ejecutan múltiples modelos dbt.
• Pendiente: No hay benchmarks independientes que comparen el costo de este enfoque contra self-hostear Dagster open source en distintos proveedores cloud.

Errores comunes al optimizar costos en Dagster Cloud

Después de ver a varios equipos tropezar con lo mismo (y de confesarlo yo también), estos son los errores que tenés que evitar:

• Pasar context al CLI de dbt sin querer: es el error que anula todo el ahorro. Si el recurso CLI recibe el contexto de ejecución de Dagster, emite eventos por cada modelo. Revisá dos veces el código antes de deployar a producción.
• Seguir usando @dbt_assets “hasta que duela”: muchos equipos postergaron el refactor porque la UI linda es adictiva. Cuando la factura llegó a USD 1,500 recién ahí se pusieron a cambiar. Hacelo antes de que duela, sobre todo si tu cantidad de modelos crece mes a mes.
• No medir el impacto antes y después: si no tenés una línea de base de cuánto estabas pagando por día antes del cambio, es difícil cuantificar el ahorro. Etiquetá tus ejecuciones, usá los reportes de uso de Dagster Cloud (si tu plan los incluye) y compará la factura de dos semanas con el enfoque nuevo versus dos semanas con el viejo.
• Olvidarse de migrar las alertas: al colapsar todo en un solo asset, perdés las alertas por modelo que tenías configuradas. Actualizá tus monitores para que disparen cuando el asset grande falle, y asegurate de que los logs de dbt lleguen a donde tu equipo los pueda revisar rápido (Slack, PagerDuty, lo que uses).

Preguntas Frecuentes

¿Por qué subió tanto mi factura de Dagster Cloud en 2026?

En mayo de 2026, Dagster Cloud eliminó la asignación mensual de créditos gratuitos de los planes Solo y Starter y empezó a cobrar aproximadamente USD 0.035–0.040 por cada materialización de asset. Si tu workspace ejecuta cientos de modelos dbt con frecuencia horaria o diaria, el costo pasó de USD 10–100 a cientos o miles de dólares al mes. Más contexto en cómo ejecutar agentes sin API.

¿Cómo puedo reducir los costos de Dagster Cloud sin migrar a otro orquestador?

La estrategia más efectiva documentada es colapsar todos los assets dbt en un único @asset que ejecute dbt build mediante DbtCliResource. Esto reduce las materializaciones facturadas de cientos a una sola por ejecución, recortando la factura alrededor de un 60% sin tocar la lógica de transformación.

¿Es mejor colapsar assets dbt en uno solo o seguir con @dbt_assets?

Depende. Colapsar es mejor si tu prioridad es bajar costos y ya usás dbt docs para documentar lineage. Seguir con @dbt_assets conviene si necesitás monitoreo granular por modelo en la UI de Dagster y tu factura actual no es un problema. Un punto medio es colapsar por capas (staging, intermediate, marts) en lugar de un solo asset monolítico.

¿Qué alternativas hay a Dagster Cloud si sigue siendo caro después de optimizar?

La alternativa directa es self-hostear Dagster open source en infraestructura propia, ya sea en un VPS, un servidor dedicado o un clúster de Kubernetes. También podés evaluar otros orquestadores como Prefect o Airflow, aunque ambos requieren migrar la lógica de pipelines y el esfuerzo de reimplementación es mayor que simplemente colapsar assets en Dagster.

¿Cómo implementar un solo asset dbt en Dagster sin perder lineage?

No es posible mantener el lineage por modelo en la UI de Dagster si usás un solo @asset. Lo que sí podés hacer es documentar el lineage en dbt docs y acceder a él desde ahí, y en Dagster configurar el asset único con metadatos que enlacen a la documentación de dbt para que el salto sea rápido.

Conclusión

El cambio de pricing de Dagster Cloud en 2026 obligó a muchos equipos a mirar con lupa sus costos de orquestación. La historia de Narev demuestra que no siempre hace falta saltar a otro orquestador—a veces alcanza con quitarle a Dagster la responsabilidad de coordinar algo que dbt ya sabe hacer solo. Colapsar los assets, si se hace bien y con el cuidado de no pasar context al CLI, te puede ahorrar un 60% de la factura sin sacrificar la calidad de tus pipelines.

El verdadero aprendizaje acá no es solo técnico: es que en la nube, la granularidad y la visibilidad se pagan. Y si no auditás cómo tu herramienta factura cada paso, eventualmente te llega la factura que te hace auditarlo a las apuradas.

Fuentes

• How we cut our Dagster Cloud bill by 60% by collapsing our dbt assets – dev.to – Artículo original del equipo de Narev (Cursor) con la experiencia, código y resultados.
• Documentación oficial de dagster-dbt – Dagster Docs – Referencia de la API de DbtCliResource y @dbt_assets.
• Dagster Cloud Pricing Update – Dagster Blog – Anuncio oficial del cambio de precios (referencia esperada; consultar si el link exacto cambió).