Cuando Snowflake anunció que se podían ejecutar proyectos dbt de forma nativa dentro de la plataforma, la primera pregunta que me hicieron varios clientes fue la misma: «¿Y esto sustituye a dbt Platform o a mi orquestador?». Mi respuesta entonces era: «todavía no; le falta madurez operativa».
La nota de versión del 20 de octubre de 2026 cambia bastante esa conversación. No trae una única funcionalidad estrella, sino seis mejoras que atacan exactamente los puntos que hacen que un proyecto dbt sea mantenible en producción: coste, frescura de los datos, dependencias entre equipos, recuperación de errores y trazabilidad.
Vamos una por una.
1. Integración con dbt State: no reconstruir lo que no ha cambiado
Es, para mí, la novedad con más impacto económico. Los objetos de proyecto dbt y los Workspaces pueden conectarse ahora a dbt State, el servicio de dbt Labs que decide qué modelos hay que reconstruir y cuáles se pueden reutilizar en cada ejecución.
¿Qué significa en la práctica? Que si un modelo no tiene cambios de código ni datos nuevos aguas arriba, no se vuelve a materializar. Menos modelos ejecutados significa menos tiempo de ejecución y menos créditos de warehouse.
La configuración se apoya en dos piezas que cualquier equipo de plataforma de Snowflake ya conoce:
– Un secreto en `env.yml` con las credenciales de tu cuenta de dbt Platform.
– Una external access integration para que Snowflake pueda hablar con el servicio de dbt Labs.
Ojo a un detalle importante: dbt State es un servicio de dbt Labs, así que hay que revisar las versiones de dbt soportadas y el modelo de facturación antes de activarlo. La documentación lo detalla en dbt State integration. Mi recomendación: medid antes y después y si vuestros proyectos tienen muchos modelos que rara vez cambian, el ahorro en compute puede compensar de sobra.
2. Source freshness, integrado en la arquitectura
`dbt source freshness` existe desde hace años, pero ejecutarlo en dbt Projects on Snowflake requería más trabajo del deseable. Ahora, apoyándose en el soporte de artefactos que ya habilitaba Slim CI, se puede lanzar desde:
– La lista de comandos de Workspaces.
– La página de detalle del objeto de proyecto dbt.
– Un proyecto dbt programado.
– Snowflake CLI, con `snow dbt execute`.
Lo que más me gusta es lo visual: los nodos de tipo source en el DAG muestran una insignia Fresh, Expiring o Stale. Y no es una foto del último chequeo: la insignia se recalcula a partir de la última fecha de carga y de los umbrales `warn_after` / `error_after` definidos en el YAML de la source. Al pasar el ratón ves la última carga y la regla aplicada.
Para quien quiera explotarlo desde SQL (alertas, cuadros de mando de calidad de datos…), los resultados se pueden consultar con la función SYSTEM$DBT_GET_LAST_RUN_TARGET.
Esto encaja muy bien con algo de lo que he hablado otras veces en el blog: los contratos de datos no sirven de nada si no se observan. La frescura es probablemente la expectativa más básica que un consumidor tiene sobre un dato, y ahora es visible sin salir de Snowsight.
3. Referencias entre proyectos en el DAG
Cada vez más organizaciones están partiendo su gran proyecto dbt en varios proyectos por dominio o por equipo, un enfoque muy alineado con *data mesh*. El problema habitual es que, al hacerlo, pierdes la visión de extremo a extremo.
Si tu proyecto importa otro como paquete Git privado con `dbt deps` (por ejemplo, una subcarpeta de un monorepo o el repositorio de otro equipo) y usas la sintaxis de dos argumentos:
select *from {{ ref('finanzas_core', 'dim_cliente') }}
…los DAG de Workspaces, de Query History y del detalle del objeto de proyecto ahora muestran esas dependencias:
– Los nodos importados aparecen etiquetados con su proyecto de origen.
– Solo se muestran los modelos importados que realmente referencias, no el paquete entero (se agradece, el DAG no se convierte en un plato de espaguetis).
– Un filtro en la barra de herramientas aísla los nodos cross-project y sus vecinos directos.
– Una vista de topología muestra de qué proyectos dbt depende el tuyo.
Para gobierno y análisis de impacto, esto es oro: antes de cambiar `dim_cliente`, el equipo propietario puede entender quién depende de ella.
4. Re-run de modelos fallidos desde Query History
Una de esas mejoras pequeñas que ahorran muchos minutos a lo largo del año. En la sección dbt Output del detalle de una ejecución fallida en Query History aparece un botón Re-run, que vuelve a ejecutar los modelos con error y todo lo que depende de ellos usando en la bash:
select result:error+
Puedes elegir usar los artefactos de esa ejecución concreta o los del último run target fallido, o directamente lanzar `dbt retry`.
Una limitación a tener en cuenta: solo está disponible para objetos de proyecto dbt que usan la versión live.
5. Nueva página de inicio de dbt Projects y plantillas
Snowsight estrena una home de dbt Projects que lista todos los objetos de proyecto, con filtros por base de datos, rol propietario y nombre, y una pestaña de Run History. Parece menor, pero en cuentas con decenas de proyectos se nota.
Desde ahí se puede arrancar un proyecto a partir de plantillas:
– El proyecto de ejemplo Tasty Bytes.
– Un proyecto dbt con Cortex, que abre Cortex Code para ayudarte a construirlo.
Además, la plantilla «Getting started with dbt Projects» —sin necesidad de Git— está en la galería de plantillas de Snowsight y como tile en la home de Workspaces. Es una forma muy rápida de enseñar dbt a alguien sin pelearse primero con repositorios y credenciales.
6. El entorno, visible en el historial de ejecuciones
Por último, el run history de Snowsight muestra ahora qué entorno de `env.yml` se seleccionó en cada ejecución. Quien haya tenido que averiguar alguna vez si un run «raro» se lanzó contra desarrollo o producción sabe lo valioso que es este dato para auditoría y troubleshooting.
Conclusión
Si junto las seis piezas, veo un mensaje claro: Snowflake quiere que el ciclo de vida completo de un proyecto dbt —desarrollar, ejecutar, observar y recuperarse de errores— ocurra dentro de la plataforma, y está cerrando las brechas operativas que lo impedían.
Algunas reflexiones para quien esté evaluándolo:
– FinOps: dbt State es la palanca más interesante para reducir coste, pero implica una dependencia de un servicio de dbt Labs. Valorad la facturación de ambos lados.
– Calidad y gobierno: source freshness visible en el DAG y consultable por SQL facilita mucho llevar los acuerdos de servicio de datos a algo medible.
– Organización: el soporte visual para referencias entre proyectos hace viable, de verdad, dividir un monolito dbt por dominios sin perder la trazabilidad.
– **Operación**: el re-run desde Query History y el entorno en el historial reducen fricción en el día a día de soporte.
¿Sustituye esto a dbt Platform o a un orquestador externo en todos los casos? No necesariamente. Pero la pregunta ya no es «¿está maduro?», sino «¿qué encaja mejor con mi arquitectura y mi modelo operativo?». Y esa es una conversación mucho más interesante.
Podéis consultar la nota oficial completa en la documentación de Snowflake.
¿Estáis ya usando dbt Projects on Snowflake en producción? Me encantará leer vuestra experiencia en los comentarios.
Foto de portada gracias a Anna Tarazevich: https://www.pexels.com/es-es/foto/actualizar-texto-de-letras-sobre-fondo-negro-5697254/
