ETL vs ELT: por que importa la diferencia en 2025

La pregunta que parece resuelta pero no lo esta

Si preguntas a cualquier data engineer en 2025 “ETL o ELT?”, la respuesta mayoritaria sera “ELT, obviamente.” El cloud data warehouse ha ganado. dbt ha ganado. La era de los motores ETL monoliticos tipo Informatica y SSIS ha terminado.

Excepto que no. Al menos no para todo el mundo.

El 60% de las empresas medianas con las que trabajamos siguen ejecutando pipelines ETL clasicos. No porque sean tecnofobas, sino porque sus datos tienen caracteristicas que el patron ELT puro no resuelve bien, o porque el coste de migracion no se justifica para su escala. Y muchas empresas que adoptaron ELT “porque es lo moderno” estan descubriendo que su factura de Snowflake o BigQuery es significativamente mayor de lo esperado.

La realidad, como siempre, es mas matizada que la narrativa dominante.

Los patrones, sin jerga

ETL (Extract, Transform, Load) extrae datos de las fuentes, los transforma en un servidor intermedio (el motor ETL) y carga el resultado ya transformado en el destino. El procesamiento pesado ocurre fuera del data warehouse. Las herramientas clasicas: Informatica PowerCenter, SSIS, Talend, Pentaho.

ELT (Extract, Load, Transform) extrae datos de las fuentes, los carga en crudo en el data warehouse, y ejecuta las transformaciones dentro del propio warehouse usando su capacidad de computo. Las herramientas del ecosistema moderno: Fivetran o Airbyte para extract-load, dbt para las transformaciones SQL.

La diferencia parece menor (solo se invierte el orden de dos letras) pero tiene implicaciones profundas en costes, arquitectura, skills necesarios y operaciones.

Que cambio: el cloud data warehouse

El patron ELT era inviable hace 10 anos porque los data warehouses on-premise (Oracle, Teradata) tenian capacidad de computo limitada y cara. Cargar datos en crudo y transformar dentro del warehouse habria saturado el sistema.

Tres productos cambiaron la ecuacion:

BigQuery (Google, 2012) introdujo la separacion de storage y computo y el modelo de pago por query. Almacenar petabytes de datos cuesta centimos; procesarlos cuesta por la cantidad de datos escaneados.

Snowflake (2014) llevo la separacion storage-computo mas lejos con warehouses elasticos que escalan independientemente. Necesitas mas potencia de transformacion? Subes el warehouse durante la ejecucion y lo bajas despues.

Redshift (Amazon, 2013) democratizo el data warehouse en la nube, aunque su modelo de clusters fijos se parece mas al on-premise que a BigQuery o Snowflake.

Con computo elastico y barato, ejecutar transformaciones pesadas dentro del warehouse dejo de ser un problema tecnico. Lo que antes requeria un servidor ETL dedicado ahora se ejecuta como SQL en Snowflake. Y SQL es un lenguaje que muchas mas personas dominan que Java o Python, lo que democratizo el acceso al data engineering.

ELT: las ventajas reales

Simplicidad arquitectonica. En lugar de tres sistemas (fuente, motor ETL, warehouse), tienes dos: fuente y warehouse. El motor de transformacion es el propio warehouse. Menos sistemas, menos puntos de fallo, menos infraestructura que gestionar.

Velocidad de iteracion. Cambiar una transformacion en dbt es editar una query SQL, ejecutar dbt run y ver resultados en minutos. Cambiar una transformacion en Informatica requiere abrir un entorno de desarrollo propietario, modificar un mapping visual, publicar, desplegar y ejecutar. La diferencia en feedback loop es de ordenes de magnitud.

Version control nativo. Los modelos de dbt son ficheros SQL en un repositorio Git. Puedes hacer code review de una transformacion de datos con el mismo flujo que usas para codigo de aplicacion. Los ETL clasicos almacenan su logica en metadatos binarios dentro de un servidor propietario.

Testing integrado. dbt permite definir tests de calidad directamente sobre los modelos: unicidad, no nulidad, integridad referencial, reglas de negocio custom. Los tests se ejecutan como parte del pipeline. En gobierno del dato, esta capacidad es transformadora.

Linaje automatico. dbt genera un grafo de dependencias entre todos los modelos automaticamente. Puedes ver que tablas alimentan un dashboard con un solo comando. En ETL clasico, reconstruir el linaje requiere herramientas externas o documentacion manual.

ETL: cuando sigue siendo la respuesta correcta

El discurso “ELT para todo” ignora escenarios reales donde ETL clasico sigue siendo superior:

Datos sensibles que no deben cargarse en crudo. Si tienes datos con PII (informacion personal identificable) que debe anonimizarse o pseudonimizarse antes de entrar en el warehouse, necesitas transformar antes de cargar. Cargar datos con DNIs, numeros de cuenta o historiales medicos en un staging area del warehouse para luego transformarlos es un riesgo de compliance. La anonimizacion debe ocurrir antes de que el dato toque el warehouse.

Fuentes con formatos complejos. XML anidado, ficheros con encoding mixto, datos semi-estructurados con esquemas inconsistentes, ficheros de mainframe con longitud fija. Intentar cargar esto en crudo en BigQuery o Snowflake y transformar con SQL es una pesadilla. Un motor ETL con capacidades de parseo avanzado (o un script Python con pandas) resuelve el problema antes de que el dato llegue al warehouse.

Volumen extremo con transformaciones simples. Si procesas 500 millones de registros al dia pero la transformacion es trivial (renombrar campos, convertir tipos, filtrar registros invalidos), ejecutar esa transformacion dentro de Snowflake genera un coste de computo significativo. Un pipeline Spark que transforme y cargue directamente puede ser 5-10x mas barato para ese patron especifico.

Integraciones operacionales. Si los datos transformados no van a un warehouse sino a un sistema operacional (un CRM, un ERP, una API), el patron ELT no aplica. Necesitas ETL o una herramienta de integracion (MuleSoft, Workato, n8n) que extraiga, transforme y cargue en el destino operacional.

Presupuesto limitado con volumen bajo. Si tienes 5 fuentes de datos, un par de millones de registros y un equipo de 2 personas, un pipeline Python con Airflow puede ser mas coste-efectivo que Fivetran + Snowflake + dbt. Las herramientas del modern data stack tienen costes minimos que no siempre se justifican para volumenes pequenos.

El coste real: la conversacion que nadie tiene

El modern data stack (Fivetran + Snowflake + dbt Cloud) es elegante, productivo y potencialmente caro. Desglose tipico mensual para una empresa mediana:

Componente	Rango mensual
Snowflake (storage + compute)	500-5.000 EUR
Fivetran (extract-load)	500-3.000 EUR
dbt Cloud	100-500 EUR
Total	1.100-8.500 EUR

Comparado con un servidor Linux con Airflow, Python y PostgreSQL como warehouse:

Componente	Rango mensual
Servidor (4 CPU, 16 GB RAM)	50-100 EUR
PostgreSQL managed	50-200 EUR
Total	100-300 EUR

La diferencia es de un orden de magnitud. Obviamente el segundo stack tiene limitaciones de escala que el primero no tiene, y requiere mas expertise de ingenieria para mantener. Pero para una empresa que procesa 10 millones de registros al dia (que es mucho para la mayoria de las pymes), PostgreSQL con partitioning y buenos indices puede ser suficiente.

El error comun es adoptar el modern data stack “porque es lo que usan las scale-ups” sin calcular si el volumen y la complejidad lo justifican. Un equipo de 50 personas no necesita la infraestructura de datos de Spotify.

La ruta de migracion: ETL a ELT

Si decides migrar de ETL clasico a ELT, estos son los pasos que hemos validado en proyectos reales:

Fase 1: Inventario y priorizacion. Documenta todos los pipelines ETL existentes: fuentes, transformaciones, destinos, frecuencia, SLA. Prioriza la migracion por impacto (los pipelines que alimentan decisiones criticas de negocio primero) y complejidad (los mas simples primero para generar momentum).

Fase 2: Extract-Load en paralelo. Configura Fivetran, Airbyte o un extractor custom para cargar las fuentes en crudo en el nuevo warehouse. Ejecuta en paralelo con el ETL existente durante 2-4 semanas para validar que los datos crudos son correctos y completos.

Fase 3: Reescribir transformaciones en dbt. Convierte los mappings ETL en modelos dbt (SQL). Esto no es una traduccion automatica; es una reescritura. Aprovecha para limpiar logica que se acumulo durante anos: CTEs en lugar de tablas temporales encadenadas, nomenclatura consistente, documentacion inline.

Fase 4: Validacion cruzada. Ejecuta el pipeline nuevo y el viejo en paralelo. Compara resultados. Las diferencias revelan bugs (a veces en el pipeline nuevo, a veces en el viejo que nadie habia detectado).

Fase 5: Corte. Cuando los resultados son equivalentes durante 2 semanas consecutivas, apaga el ETL viejo. Mantiene el acceso al servidor viejo durante 30 dias por si acaso.

Tiempo tipico: 2-6 meses para una migracion de 20-50 pipelines, dependiendo de la complejidad de las transformaciones y la disponibilidad del equipo.

El patron hibrido: la respuesta pragmatica

La mayoria de las organizaciones que asesoramos acaban con un patron hibrido:

• ELT para datos estructurados de aplicaciones SaaS (CRM, ERP, herramientas de marketing) que se cargan en el warehouse y se transforman con dbt.
• ETL para datos sensibles que requieren anonimizacion pre-carga, formatos complejos que necesitan parseo, e integraciones operacionales que no pasan por el warehouse.

No es purista, pero funciona. Y en ingenieria de datos, “funciona” es mas valioso que “es elegante.”

Que preguntar antes de elegir

Antes de decidir entre ETL y ELT (o hibrido), responde estas cinco preguntas:

1. Que volumen de datos procesas al dia? Por debajo de 10 millones de registros, cualquier patron funciona. Por encima de 100 millones, el coste de computo en el warehouse importa.
2. Tus datos tienen PII que debe anonimizarse? Si es que si, necesitas transformacion pre-carga para esos datos.
3. Tu equipo sabe SQL? Si la mayoria del equipo domina SQL, ELT con dbt es el camino natural. Si el equipo es mas fuerte en Python/Java, ETL con Spark o Airflow puede ser mas productivo.
4. Cual es tu presupuesto mensual para infraestructura de datos? Si es inferior a 500 EUR/mes, el modern data stack probablemente no se justifica.
5. Los datos transformados van a un warehouse o a un sistema operacional? Si el destino es un sistema operacional, ELT no aplica.

Si tu destino es un data warehouse o un data lake, la eleccion del patron de carga influye directamente en la arquitectura. Las respuestas definen el patron. No la moda, no el blog de Snowflake, no lo que usa tu vecino. Tus datos, tu equipo, tu presupuesto.