ETL vs ELT: cómo elegir herramienta de datos

Cuando una empresa empieza a construir su plataforma de datos, uno de los primeros debates es siempre el mismo: ¿ETL o ELT? ¿Fivetran o Airbyte? ¿dbt o algo más? La respuesta no está en un benchmark ni en una comparativa de producto. Está en entender qué hace exactamente cada patrón, cuándo uno es superior al otro y cuál encaja con el equipo y el stack que ya tienes.

Esta guía fusiona los tres ángulos del debate: el patrón de integración (ETL vs ELT), las herramientas de movimiento de datos (Fivetran, Airbyte, Azure Data Factory, AWS Glue, Mage) y las herramientas de transformación (dbt). El objetivo es que al terminar tengas criterios claros, no solo definiciones. Si quieres ver cómo encaja esto en una arquitectura completa, el post sobre arquitectura Medallion de datos da el contexto de destino.

¿Por qué el debate ETL vs ELT importa ahora?

Durante décadas, ETL fue el único patrón posible. Los sistemas destino (Oracle, SQL Server, DB2) no tenían capacidad de cómputo para transformar grandes volúmenes de datos de forma eficiente: la transformación debía ocurrir fuera, en un servidor ETL especializado, antes de que los datos llegaran al warehouse. Ese era el mundo para el que se diseñaron herramientas como Informatica PowerCenter o IBM DataStage.

El cloud cambió las reglas del juego. BigQuery, Snowflake y Redshift son warehouses que facturan cómputo por uso y escalan horizontalmente sin configuración manual. Transformar dentro del propio warehouse pasó a ser más barato, más rápido y más fácil de mantener que operar un servidor ETL intermedio. ELT no es una moda: es una consecuencia directa de cómo funcionan los warehouses modernos.

El debate importa ahora porque la proliferación de herramientas ha creado confusión. Hay organizaciones que compran una herramienta ETL pesada cuando ELT + dbt sería diez veces más sencillo. Y hay otras que adoptan ELT sin un warehouse adecuado, lo que convierte cada consulta de transformación en un problema de costes. Entender el patrón antes de elegir la herramienta ahorra errores caros.

¿Cómo funciona ETL y cuándo sigue siendo la opción correcta?

ETL son las siglas de Extract, Transform, Load. El flujo es estrictamente secuencial: primero se extraen los datos del sistema origen, luego se transforman fuera del destino (limpieza, normalización, enriquecimiento, aplicación de reglas de negocio) y por último se cargan ya procesados en el sistema destino. Solo llegan al warehouse datos listos para usar.

Cuándo ETL sigue siendo la elección correcta

• El destino no es un warehouse cloud con capacidad de cómputo elástica, sino una base de datos transaccional o un sistema legacy con recursos limitados.
• Los datos contienen información sensible que no puede aterrizar en bruto en el destino por restricciones regulatorias o de seguridad: anonimización o enmascaramiento obligatorio antes de la carga.
• Las transformaciones son complejas y requieren lógica que SQL no puede expresar con eficiencia: procesado de texto, modelos de ML aplicados en el pipeline, llamadas a APIs externas durante la transformación.
• El volumen de datos cargado es pequeño en comparación con el volumen total extraído: se filtra y reduce radicalmente antes de cargar, con lo que cargar datos crudos al destino sería ineficiente.

En la práctica, ETL puro sigue siendo frecuente en integraciones con ERPs legacy (SAP on-premise, AS/400, sistemas propietarios de sector), en empresas con normativa de privacidad estricta (datos sanitarios bajo RGPD, datos financieros bajo PCI) y en pipelines de datos maestros donde la limpieza es compleja y costosa de hacer en SQL. No es un patrón obsoleto: es el correcto para ciertos contextos.

¿Cómo funciona ELT y por qué domina en cloud?

ELT invierte el orden de las operaciones: Extract, Load, Transform. Los datos se extraen del origen y se cargan tal cual en el warehouse (normalmente en una capa raw o staging). La transformación ocurre después, dentro del warehouse, con SQL. La herramienta de integración solo hace EL; la T la delega al warehouse y, habitualmente, a dbt.

Por qué ELT domina en stacks cloud modernos

La razón principal es la economía del cómputo cloud. Snowflake, BigQuery o Redshift pueden ejecutar transformaciones SQL sobre cientos de millones de filas en segundos, con costes por transformación bajos gracias a la facturación por uso. No tiene sentido operar un servidor ETL intermedio cuando el warehouse ya tiene la capacidad necesaria. El coste operativo se reduce y la arquitectura se simplifica.

ELT tiene además ventajas de auditoría: los datos crudos siempre están disponibles en la capa raw. Si una transformación era incorrecta, se puede corregir y re-ejecutar sin tener que volver a extraer del origen. Esto es especialmente valioso cuando los sistemas origen son difíciles de acceder o tienen ventanas de disponibilidad limitadas.

Limitaciones del patrón ELT

• Si el warehouse no tiene capacidad de cómputo elástica, transformar dentro cuesta más que hacerlo fuera.
• Los datos sensibles llegan en bruto al destino: hay que aplicar controles de acceso a la capa raw desde el primer día.
• Requiere un equipo con conocimientos sólidos de SQL y modelado de datos para gestionar correctamente las capas de transformación.
• Si no se usa dbt u otra herramienta de gestión de transformaciones, el código SQL se vuelve inmantenible rápidamente.

Comparativa práctica ETL vs ELT: las 8 dimensiones que importan

Las herramientas de integración: Fivetran, Airbyte, dbt, Azure Data Factory, AWS Glue y Mage

El mercado de herramientas de integración es amplio y confuso. Algunos productos hacen EL (movimiento de datos), otros hacen T (transformación), y otros intentan hacer las tres fases. Mezclar categorías al compararlas lleva a decisiones malas. La tabla siguiente agrupa las herramientas por su función real en el pipeline.

¿Por qué Fivetran (o Airbyte) + dbt es el stack dominante?

El stack que más se repite en empresas con plataforma de datos moderna es la combinación de una herramienta EL gestionada con dbt para la transformación. El razonamiento es simple: separar las responsabilidades. La herramienta EL (Fivetran o Airbyte) se encarga de mantener los datos sincronizados y actualizados desde los orígenes; dbt se encarga de modelarlos, documentarlos y testearlos dentro del warehouse.

Esta separación de responsabilidades tiene ventajas operativas claras. Los ingenieros de datos trabajan con SQL estándar y versionan sus transformaciones en Git, igual que cualquier código de software. dbt añade tests automáticos (unicidad, no nulos, integridad referencial), documentación autogenerada y linaje de columna a columna. El resultado es un warehouse donde sabes qué viene de dónde y puedes confiar en los datos.

Cuándo este patrón no es suficiente

Fivetran + dbt no cubre todo. Si tus pipelines incluyen lógica Python compleja (ML, procesado de texto, llamadas a APIs durante la transformación), necesitas un orquestador como Airflow, Prefect o Mage que pueda ejecutar tanto los modelos dbt como los scripts Python. Si tus fuentes son principalmente on-premise o sistemas propietarios sin conector disponible, Airbyte self-hosted con conectores personalizados o Azure Data Factory puede ser más apropiado.

El cloud de destino también influye en la elección. Si tu stack es Azure con Fabric o Synapse, Azure Data Factory encaja de forma natural con las herramientas de Microsoft. Si estás en AWS con Redshift, AWS Glue tiene ventajas de integración nativa. Para stacks multi-cloud o cloud-agnostic, Fivetran y dbt son la combinación más neutral. Puedes ver cómo encaja el cloud en este análisis de AWS, Azure y GCP para datos.

Árbol de decisión: cómo elegir tu herramienta de integración de datos

Las preguntas siguientes te guían hacia la combinación correcta para tu situación. Respóndelas en orden: cada respuesta elimina opciones antes de llegar a la siguiente.

1. 1¿Tu destino principal es un warehouse cloud (BigQuery, Snowflake, Redshift, Databricks)? Si sí, ELT es el patrón natural. Si no (BBDD on-premise, SQL Server, sistema legacy), evalúa ETL con Azure Data Factory o una herramienta especializada.
2. 2¿Tus fuentes son principalmente SaaS comerciales (Salesforce, HubSpot, Google Ads, Stripe, Shopify)? Si sí, Fivetran es la opción con menor fricción: tiene los conectores más maduros y mínimo mantenimiento. Si no (fuentes internas, APIs propias, bases de datos on-premise), evalúa Airbyte self-hosted o conectores personalizados.
3. 3¿Tienes un equipo técnico dedicado (un ingeniero de datos o más) dispuesto a mantener infraestructura? Si sí, Airbyte self-hosted es viable y ahorra costes a volumen alto. Si no, los servicios gestionados (Fivetran, Airbyte Cloud) reducen la carga operativa.
4. 4¿Tus transformaciones son SQL estándar o requieren lógica Python? Si SQL, dbt cubre el 90% de los casos con testing y documentación incluidos. Si Python, necesitas un orquestador (Airflow, Prefect, Mage) que ejecute tanto dbt como scripts personalizados.
5. 5¿Tu stack corporativo es Microsoft (Azure, Office 365, Fabric)? Si sí, Azure Data Factory con integración a Fabric/Synapse puede simplificar la gestión de permisos y la gobernanza. Si no, la combinación Fivetran/Airbyte + dbt es más neutral y portable.
6. 6¿El volumen de datos es alto (cientos de millones de filas por sincronización)? Si sí, revisa el modelo de precios de Fivetran (MAR puede escalar de forma problemática) y compara con Airbyte Cloud o self-hosted. El coste de transformación en el warehouse también debe estar en el cálculo.
7. 7¿Hay datos sensibles que no pueden aterrizar en bruto en el destino? Si sí, necesitas una capa de transformación y enmascaramiento antes de la carga, lo que orienta hacia ETL o hacia ELT con controles de acceso estrictos en la capa raw desde el primer día.

¿Qué errores evitar al diseñar pipelines de integración?

La mayoría de los problemas en producción no vienen de elegir mal entre ETL y ELT. Vienen de ignorar aspectos operativos que solo se hacen visibles semanas después del lanzamiento. Estos son los errores más habituales que vemos en proyectos de integración.

1. No diseñar la capa raw desde el principio

El error más frecuente en ELT es cargar los datos directamente en tablas transformadas, sin conservar la capa raw. Cuando hay un error en una transformación (y los habrá), no puedes recalcularla sin volver a extraer del origen. La capa raw es el seguro del pipeline: siempre debe existir, aunque nadie la consulte directamente.

2. Ignorar la gestión de cambios de esquema en el origen

Los sistemas origen cambian: el equipo de CRM añade un campo, el ERP actualiza una tabla, la API de un proveedor versiona su respuesta. Si el pipeline no tiene un mecanismo para detectar y propagar estos cambios de esquema, las transformaciones aguas abajo empiezan a fallar silenciosamente. Fivetran y Airbyte gestionan los cambios de esquema de forma automática; en pipelines caseros, esto suele ser un punto ciego.

3. No monitorizar la frescura de los datos

Un pipeline puede ejecutarse sin errores pero producir datos obsoletos. Si el job ETL/ELT falla silenciosamente o se retrasa, los usuarios trabajan con datos de hace 48 horas sin saberlo. La observabilidad del pipeline debe incluir alertas de frescura (freshness alerts): dbt tiene esta funcionalidad integrada como fuente_frescura configurada en el YAML del proyecto.

4. Transformar en el pipeline lo que debería estar en dbt

Es tentador añadir lógica de negocio dentro del pipeline de movimiento de datos (en el conector de Fivetran, en el job de AWS Glue, en el flujo de ADF). El problema es que esa lógica queda invisible, sin tests y sin documentación. Cualquier transformación que afecte a la semántica de negocio debe vivir en dbt, donde puede versionarse, testearse y auditarse.

5. Subestimar el coste de mantenimiento de conectores propios

Construir un conector propio para extraer datos de un sistema interno puede parecer sencillo al principio. En producción, ese conector necesita actualizarse cuando la API del origen cambia, gestionarse cuando falla, monitorizarse y documentarse. Un conector propio bien hecho equivale a mantener un producto de software pequeño. Si el volumen lo justifica, mejor reutilizar Airbyte con un conector personalizado que tener scripts ad-hoc en producción.

La data observability es la disciplina que cubre estos puntos ciegos: monitorización de frescura, volumen, distribución y linaje de los datos en cada etapa del pipeline. Si quieres profundizar en este tema, el post sobre data observability para empresas entra en detalle en las herramientas y los patrones concretos.