ETL vs ELT en 2025: ¿cuál domina el mercado cloud?

Durante más de dos décadas trabajando en proyectos de datos, he visto cómo el paradigma ETL —que durante años fue la única opción válida— ha cedido terreno de forma drástica frente al ELT en entornos cloud. No es una cuestión de moda: es un cambio estructural impulsado por la capacidad de cómputo casi ilimitada de plataformas como BigQuery, Snowflake o Redshift.

Qué es ETL y cómo funciona

ETL (Extract, Transform, Load) es el proceso clásico de integración de datos. Los datos se extraen de los sistemas fuente, se transforman en un servidor intermedio y después se cargan ya procesados en el Data Warehouse. La transformación ocurre antes de llegar al repositorio central.

FUENTES           SERVIDOR ETL             DESTINO
[CRM]    --+
[ERP]    --+-> [EXTRACT] -> [TRANSFORM] -> [LOAD] -> [DWH]
[Web]    --+
[APIs]        (limpieza, joins,           (datos ya
               reglas de negocio)          transformados)

El servidor ETL actúa como intermediario. Toda la lógica de transformación —limpieza, normalización, cálculos derivados, joins entre tablas de distintas fuentes— se ejecuta en ese motor. Esto requiere recursos de cómputo propios y suele ser el cuello de botella en volúmenes grandes.

Qué es ELT y por qué el cloud lo cambió todo

ELT (Extract, Load, Transform) invierte el orden: los datos se cargan en bruto directamente en el Data Warehouse cloud y las transformaciones se ejecutan dentro del propio DWH usando la potencia de cómputo nativo del cloud.

FUENTES           DESTINO CLOUD                TRANSFORMACION
[CRM]    --+
[ERP]    --+-> [EXTRACT] -> [LOAD RAW] -> [TRANSFORM SQL] -> [MARTS]
[Web]    --+
[APIs]        (datos en bruto,              (SQL sobre BigQuery /
               sin procesar)                Snowflake / Redshift)

Plataformas como Google BigQuery, Snowflake o Amazon Redshift ejecutan transformaciones SQL complejas sobre terabytes en segundos usando arquitectura MPP (Massively Parallel Processing). El coste marginal de transformar in-situ es tan bajo que ya no tiene sentido pagar por un servidor ETL dedicado.

Herramientas ETL clásicas

Informatica PowerCenter / IDMC

El estándar de facto durante 20 años en entornos enterprise. Ofrece entorno visual potente, excelente soporte 24/7, conectores para cualquier sistema imaginable y capacidades avanzadas de calidad de dato. Su principal desventaja: el precio. Una licencia enterprise puede superar los 200.000 €/año. Su nueva versión cloud IDMC ha modernizado el portfolio pero mantiene el modelo de precios premium.

Microsoft SSIS

Integrado en el ecosistema Microsoft, es la elección natural para empresas con SQL Server. La herramienta visual de diseño de paquetes es familiar para equipos de DBA. Sus limitaciones aparecen en escalabilidad horizontal y entornos no-Microsoft. Con Azure Data Factory, Microsoft ha pivotado hacia un modelo más cercano al ELT moderno.

Talend

Open source con versión enterprise. Buen equilibrio precio/funcionalidad. Genera código Java ejecutable, lo que puede ser una ventaja (portabilidad) o desventaja (complejidad de depuración). Adquirido por Qlik en 2023, el roadmap tiene cierta incertidumbre.

Herramientas ELT modernas

dbt (data build tool)

Se ha convertido en el estándar de transformación ELT. dbt no mueve datos: ejecuta SQL dentro del DWH y añade gestión de dependencias, tests automáticos, documentación y linaje de datos. Compatible con BigQuery, Snowflake, Redshift, Databricks y más. Su enfoque SQL-first lo hace accesible a cualquier analista.

Fivetran

Conector gestionado para la fase de ingesta (Extract + Load). Más de 300 conectores predefinidos y mantenidos automáticamente. Precio por fila procesada puede ser alto en volúmenes grandes, pero el ahorro en mantenimiento justifica el coste en la mayoría de proyectos medianos.

Airbyte

Alternativa open source a Fivetran. Más de 350 conectores, disponible self-hosted o como Airbyte Cloud. Ideal para equipos que quieren control total sobre la infraestructura. Los conectores personalizados son fáciles de construir gracias al SDK en Python.

Comparativa ETL vs ELT

Cuándo todavía tiene sentido el ETL clásico

El ETL clásico no desaparece, pero queda relegado a nichos específicos:

• Regulación estricta (GDPR, PCI-DSS, HIPAA): cuando los datos PII no pueden almacenarse en bruto antes de ser anonimizados. ETL garantiza que el dato sensible nunca toca el DWH sin transformar.
• Sistemas legacy on-premise: si tu DWH es SQL Server 2012 o un Teradata antiguo, no tienes la capacidad de cómputo para ejecutar transformaciones pesadas in-situ.
• Calidad de dato crítica pre-carga: en banca o seguros puede ser obligatorio rechazar registros inválidos antes de que lleguen al repositorio central.
• Transformaciones no-SQL complejas: cuando la lógica requiere Python, Java o procesamiento imperativo que no se puede expresar limpiamente en SQL.

Casos de uso reales

Caso 1: Retailer con 50M de transacciones diarias

Un cliente del sector retail pasaba 4 horas cada noche ejecutando jobs SSIS para transformar logs de ventas antes de cargarlos en SQL Server DWH. Tras migrar a Airbyte + BigQuery + dbt, el proceso completo tardó 18 minutos. El coste mensual de infraestructura bajó un 60% y el equipo pasó de mantener 200 paquetes SSIS a 40 modelos dbt versionados en Git.

Caso 2: Banco con datos de tarjetas (PCI-DSS)

Una entidad bancaria mantiene Informatica PowerCenter para la ingesta de transacciones. Los datos PAN se tokenizan en el servidor Informatica antes de llegar al DWH. Este es un caso donde el ETL sigue siendo la arquitectura correcta: PCI-DSS exige minimizar los datos de tarjetas lo antes posible en el flujo.

Conclusión

En 2025, si estás construyendo un nuevo proyecto de datos sobre cualquier DWH cloud, ELT es el enfoque por defecto. La combinación Fivetran/Airbyte (ingesta) + dbt (transformación) + BigQuery/Snowflake (compute) es el stack más adoptado por los mejores equipos de datos del mundo. El ETL clásico sobrevive en nichos muy específicos de cumplimiento regulatorio y sistemas legacy.