dbt Core v2.0 alpha.3 acaba de salir. El 29 de junio de 2026, dbt Labs liberó la tercera alpha de su reescritura completa del motor — y por primera vez el mismo runtime Rust que impulsa dbt Fusion (el engine que venden en dbt Cloud) quedó disponible para cualquiera, bajo licencia Apache 2.0. Si trabajas con pipelines de datos o estás aprendiendo Data Engineering, esto te cambia el panorama.
No es una actualización incremental. dbt v1.x estaba construido sobre Python, lo que funcionaba bien para proyectos pequeños y medianos, pero en repos grandes de 400-500 modelos el tiempo de compilación se volvía un problema serio. La promesa del motor Rust: el mismo parsing que tardaba minutos corre ahora en segundos, incluso en los proyectos más pesados. Eso es lo que entra en open source esta semana.
Qué pasó exactamente el 29 de junio
La primera alpha de dbt Core v2.0 salió el 1 de junio. Alpha.3 — la de esta semana — incluye soporte más estable para los adaptadores principales (BigQuery, Redshift, Snowflake, Databricks) y corrige los problemas de estabilidad que hicieron que las dos anteriores fueran poco usables en proyectos reales. No está lista para producción, pero ya se puede testear sin que se rompa a cada rato.
El punto central: el runtime Rust que antes era exclusivo de dbt Cloud ahora es open source. dbt Labs lo dice sin rodeos en su blog — el objetivo es cerrar la brecha entre los dos productos. Los usuarios de la versión gratuita ya no son ciudadanos de segunda. El mismo motor que usan las empresas que pagan dbt Cloud ahora está disponible para tu laptop o tu CI/CD local.
Por qué el motor Python era el cuello de botella
Si alguna vez corriste dbt parse en un repo con 400 modelos y te fuiste a buscar un café mientras esperaba, entiendes el problema. Python tiene el GIL — Global Interpreter Lock — que impide verdadera paralelización del parsing. En proyectos grandes, el tiempo de compilación escala mal: 100 modelos son tolerables, 500 ya duelen, 1000 se vuelven un bloqueante real para el flujo de trabajo.
El motor Rust resuelve eso desde la base. En los benchmarks que publicó dbt Labs, proyectos que antes tardaban 3-4 minutos en parsear corren en 20-30 segundos. El impacto es más notorio cuanto más grande es el repo — si tienes 50 modelos, la diferencia es menor; si tienes 500, cambia el día a día de todo el equipo de datos.
Las tres novedades de v2.0 que más cambian el día a día
- ▸Motor Rust en open source: el mismo parsing acelerado de dbt Fusion, disponible ahora para todos bajo Apache 2.0. Sin licencia de pago, sin restricciones. El rendering de modelos, la resolución de dependencias y la generación de artefactos corren sobre el mismo engine que dbt Cloud usa en producción.
- ▸Artifacts en Parquet: el famoso manifest.json — que en repos grandes puede pesar 200-500 MB — tiene ahora alternativa en formato Parquet. Puedes consultarlo directamente con DuckDB sin parsear JSON gigante. Esto simplifica el lineage, el debugging y cualquier herramienta que lea el grafo del proyecto.
- ▸dbt Lint en beta: un linter SQL nativo integrado al CLI que corre aproximadamente 50 veces más rápido que SQLFluff. Sin dependencias externas, sin configuración extra. Funciona sobre el motor Fusion y soporta ya los patrones más comunes: nombres de columnas, aliases, convenciones de CTEs y formato de modelos.
El que más me llama la atención es dbt Lint. SQLFluff siempre fue el estándar para linting de SQL en proyectos dbt, pero siempre fue lento — especialmente en CI/CD, donde correrlo sobre todo el repo podía añadir 3-5 minutos a cada pipeline. Un linter nativo que corra en segundos, sin dependencias adicionales, es algo que los equipos de datos pedían desde hace años. Lo que nadie dice todavía: la versión beta tiene cobertura de reglas más limitada que SQLFluff maduro, así que si tienes reglas customizadas muy específicas, la migración va a requerir trabajo.
El contexto más amplio: dbt como plataforma de datos
Este lanzamiento hay que leerlo en el contexto de la fusión de dbt Labs con Fivetran, confirmada a inicios de 2026. Con dbt Cloud como parte del stack de Fivetran, el portfolio se convierte en un pipeline completo: ingesta (Fivetran), transformación semántica (dbt), análisis (Semantic Layer). v2.0 consolida la base técnica de esa integración. Para los equipos de datos, eso tiene implicaciones concretas: en el mediano plazo, es probable que las herramientas de Fivetran y dbt Cloud se integren todavía más profundamente.
Hay otra apuesta silenciosa en este lanzamiento: el Semantic Layer de dbt. Con la proliferación de agentes de IA que consultan datos empresariales, el Semantic Layer pasa de ser una feature interesante a ser infraestructura crítica. Si tienes un agente de IA que consulta el revenue mensual de tu empresa, necesitas que la definición de revenue mensual esté en un lugar canónico — no distribuida en 15 queries distintos escritos por 15 personas distintas. v2.0 mejora la performance del motor que sirve esas métricas semánticas.
¿Migrar ya? La respuesta honesta
En producción: no. Alpha.3 tiene breaking changes documentados respecto a v1.x, especialmente en la API de plugins y en algunos comportamientos de ref() y source(). dbt Labs lo dice explícito en la guía de migración: no es para workloads productivos. Hay adaptadores que todavía están en proceso de soporte completo.
- ▸Si tienes entorno de sandbox o desarrollo aislado: sí, vale testear. pip install 'dbt-core==2.0.0a3' en un virtualenv separado y corre tu proyecto en modo lectura para ver qué ajustes necesitarías.
- ▸Para CI/CD en staging: posible con cuidado si el proyecto es pequeño (menos de 100 modelos) y no tienes plugins customizados. En repos grandes, todavía hay inconsistencias.
- ▸Para producción: espera el Release Candidate. dbt Labs apunta a Q3 2026 para el GA estable. Cuando llegue, las empresas van a migrar rápido — el beneficio de rendimiento es real.
Lo que sí tiene sentido hacer ahora: leer la guía oficial de migración v1 a v2 en docs.getdbt.com y anotar cuántos cambios necesita tu proyecto. Cuando llegue el RC, ya estarás adelantado. Si además tienes una buena cobertura de tests en tus transformaciones, el proceso va a ser mucho más tranquilo.
Por qué esto importa para tu carrera como Data Engineer
dbt v2.0 no es solo un cambio técnico — es una señal de hacia dónde va el stack de Data Engineering. La convergencia de Core y Fusion significa que el estándar de la industria se está unificando. Los proyectos que hoy usan dbt v1.x van a migrar en los próximos 12-18 meses. Los Data Engineers que ya manejen el stack moderno — dbt v2, Databricks o BigQuery como plataforma de cómputo, orquestadores como Airflow o Prefect — son los perfiles que van a recibir las ofertas más interesantes del mercado.
En Perú y LATAM, ya lo estamos viendo en los requisitos de los roles remotos para empresas de EE.UU. y Europa. El perfil que piden combina SQL avanzado, dbt, una plataforma cloud, y entender cómo armar pipelines confiables a escala. No es algo que se aprende en un fin de semana — es un stack que lleva meses dominar bien, y empezar ahora con la dirección correcta marca una diferencia real en 12 meses.
Cómo formarte para trabajar con el stack moderno
En DataPath, el Bootcamp de Data Engineer está diseñado exactamente para este stack: cubre dbt, Spark, Databricks y arquitectura de datos con proyectos reales de industria. Si ya tienes la base de SQL y Python, el curso de Databricks Data Engineer es la forma más directa de entrar al stack que el mercado pide hoy — Databricks fue uno de los primeros adaptadores en soportar dbt Fusion, y la integración entre los dos sigue mejorando.
Para la parte de procesamiento a escala, el curso de Apache Spark cierra el triángulo: dbt para transformaciones semánticas, Spark para procesamiento masivo de datos, Databricks como plataforma unificada que conecta los dos. Este stack de tres capas es lo que más aparece en los repos de producción de las empresas de datos más maduras de LATAM.
El motor se modernizó. Toca que el Data Engineer también lo haga
dbt Core v2.0 no es una fecha en el calendario — es un cambio de paradigma. Cuando en Q3 salga el GA estable, las empresas van a empezar a pedir que sus Data Engineers conozcan v2.0. Puedes estar adelantado o correr después. El Bootcamp Data Engineer de DataPath o el curso de Databricks son el punto de entrada más sólido que tenemos para ese stack. Empieza a construir la base ahora, antes de que la demanda supere por mucho a la oferta.
