¿Qué es dbt y por qué es el estándar de facto para transformar datos en 2026?
data build tool: framework open source que aplica buenas prácticas de software (git, tests, modularidad, documentación) a la transformación de datos en el warehouse mediante SQL.
Actualizado mayo 2026
dbt: SQL versionado con tests, documentación y lineage en el warehouse.
dbt (data build tool) es un framework open-source que permite transformar datos en un data warehouse con disciplina de ingeniería de software: SQL versionado en git, tests automatizados, documentación generada, lineage visual y deploys controlados. Convierte la transformación de datos de "scripts SQL sueltos" en "código mantenible por un equipo".
En el paradigma ELT moderno, dbt cubre la "T": una vez los datos brutos están en el warehouse (cargados por Fivetran, Airbyte o conectores nativos), dbt ejecuta una cadena de modelos SQL que limpian, normalizan, enriquecen y agregan los datos hasta dejar tablas listas para BI o ML. Todo dentro del warehouse, sin mover datos.
Tiene dos versiones: dbt Core (CLI open-source, gratis) y dbt Cloud (SaaS de dbt Labs con scheduler, IDE web, semantic layer, alertas; con planes desde gratis hasta enterprise). Para pymes B2B, dbt Core con scheduler propio (Airflow, GitHub Actions, cron) cubre el 80% de casos; dbt Cloud aporta UX y soporte cuando el equipo crece.
Es estándar de facto en 2026: Snowflake, BigQuery, Redshift, Databricks, Postgres y MotherDuck lo soportan nativamente. Convive con data warehouse moderno, con data mesh y con MLOps en la fase de feature engineering.
Las piezas que conviene entender de dbt
Lo que hay dentro de un proyecto dbt típico.
Modelos (.sql)
Cada modelo es un archivo SQL que se materializa en el warehouse como tabla o vista. Se referencian unos a otros con la función ref() — dbt resuelve dependencias y orden de ejecución automáticamente.
Sources
Definición de tablas de origen (raw) ingestadas por Fivetran/Airbyte. Permiten documentar fuentes, hacer tests de frescura (freshness) y desacoplar nombres físicos de los modelos.
Tests
Pruebas declarativas en YAML: not_null, unique, accepted_values, relationships. Tests custom con SQL. Se ejecutan en cada build y rompen el pipeline si fallan. La red de seguridad básica de calidad.
Materializations
Cómo se persiste un modelo: view (vista, no consume almacenamiento), table (tabla completa), incremental (solo nuevos registros), ephemeral (CTE inline), snapshot (SCD Type 2).
Macros (Jinja)
Reutilización de lógica SQL parametrizada con Jinja. Equivalente a funciones en código. Permiten DRY entre modelos. Macros de comunidad en dbt-utils, dbt-expectations.
Docs y lineage
Generación automática de documentación HTML con definiciones de columnas, descripciones y grafo de dependencias visual. Cualquier persona del equipo puede entender de dónde viene cada dato.
Flujo de trabajo dbt típico
De cambio en git a tabla actualizada en producción.
Pull Request en git
Analista o ingeniero crea/modifica un modelo .sql + tests YAML. PR en GitHub/GitLab. Revisión por par.
CI en rama (Slim CI)
GitHub Actions ejecuta dbt build solo en modelos cambiados (state:modified+). Tests sobre datos reales en schema temporal. Si rojo, se bloquea merge.
Merge a main
Tras review + CI verde, merge a main. dbt Cloud o scheduler (Airflow, Dagster, GitHub Actions) detecta el merge y dispara build de producción.
Build incremental en warehouse
dbt resuelve el DAG de dependencias, ejecuta SQL en el orden correcto, materializa modelos (vista/tabla/incremental/snapshot), ejecuta tests post-build.
Alertas y observabilidad
Tests fallidos o frescura rota disparan alerta a Slack. dbt Cloud expone exposures (qué dashboards consumen qué modelos). Lineage actualizado disponible.
Qué incluye cada uno y cuándo dar el salto
Decisión habitual en pymes con data team que empieza a crecer.
dbt Core (gratis)
CLI open-source. Ejecutas dbt run localmente o en CI. Sin scheduler propio: hay que orquestar con Airflow, GitHub Actions, Dagster o cron. Soporte de comunidad. Suficiente para 80% de pymes.
dbt Cloud (SaaS)
IDE web, scheduler integrado, alertas, semantic layer, soporte enterprise. Plan Developer gratis (1 usuario). Team y Enterprise de pago. Acelera onboarding del equipo.
Stack open-source completo
dbt Core + Airflow/Dagster + Atlan/DataHub (catálogo) + Elementary/Soda (observabilidad). Mayor inversión inicial pero sin lock-in y mejor precio a escala. Recomendado para equipos data engineering medianos.
Cuándo migrar a dbt Cloud
Cuando tienes 5+ analistas usando dbt, quieres semantic layer unificado, necesitas SLA de soporte o quieres reducir mantenimiento de orquestación. Pyme estándar suele empezar con Core y saltar a Cloud al año.
Cinco motivos para que tu pyme use dbt
Pasas de Excel a SQL versionado
Los reportes que viven en Excel con fórmulas frágiles se convierten en modelos dbt con tests. Verdad única, replicable, auditable.
Trazabilidad total
Lineage visual desde tabla mart hasta tabla raw. Cualquier número del dashboard se puede trazar a su origen. Esencial en due diligence y auditorías.
Calidad de datos automatizada
Tests de unicidad, no nulos, valores aceptados y relaciones se ejecutan en cada build. Detectas regresiones antes que el cliente final.
Onboarding rápido
Documentación generada automáticamente + DAG visual permiten que un analista nuevo entienda el modelo de datos en horas, no semanas.
Escala con el equipo
Pasar de 1 ingeniero a 10 analistas SQL sin caos. PRs revisados, tests obligatorios, branching strategy. Disciplina de software aplicada a datos.
dbt en el ecosistema de datos moderno.
dbt cubre la "T" del flujo ELT. Antes va la ingesta: Fivetran, Airbyte o conectores nativos cargan datos brutos al warehouse. Después van BI (Looker, Metabase, Power BI, Tableau) y reverse ETL (Census, Hightouch) que activan datos de vuelta a sistemas operativos.
Funciona nativamente con Snowflake, BigQuery, Redshift, Databricks, Postgres, DuckDB y muchos más. Cada warehouse tiene su adapter dbt mantenido por dbt Labs o comunidad.
Para arquitecturas data mesh, dbt encaja con dominios: cada equipo mantiene sus propios modelos dbt en su proyecto, con contratos de datos (data contracts) entre dominios. Para MLOps, dbt suele encargarse de feature engineering antes de pasar al feature store.
En Magnetia diseñamos stacks dbt para pymes españolas: arranque con dbt Core + GitHub Actions + warehouse cloud + dashboards Metabase. Combinable con automatización IA cuando los modelos dbt alimentan sistemas RAG. Ver comparativa dbt, Fivetran, Airbyte.
Dudas que nos hacéis llegar
¿Tus reportes viven en Excel con fórmulas frágiles?
Diseñamos stack dbt + warehouse + BI adecuado a tu pyme. Migración progresiva desde tu situación actual. Sin big-bang, sin riesgos innecesarios.