ETL vs ELT: por qué importa la diferencia en 2025
La pregunta que parece resuelta pero no lo está
Si preguntas a cualquier data engineer en 2025 “ETL o ELT?”, la respuesta mayoritaria será “ELT, obviamente.” El cloud data warehouse ha ganado. dbt ha ganado. La era de los motores ETL monolíticos tipo Informática 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 clásicos. No porque sean tecnofobas, sino porque sus datos tienen características que el patrón ELT puro no resuelve bien, o porque el coste de migración no se justifica para su escala. Y muchas empresas que adoptaron ELT “porque es lo moderno” están descubriendo que su factura de Snowflake o BigQuery es significativamente mayor de lo esperado.
La realidad, como siempre, es más 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 clásicas: Informática 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 cómputo. 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.
Qué cambio: el cloud data warehouse
El patrón ELT era inviable hace 10 años porque los data warehouses on-premise (Oracle, Teradata) tenían capacidad de cómputo limitada y cara. Cargar datos en crudo y transformar dentro del warehouse habría saturado el sistema.
Tres productos cambiaron la ecuación:
BigQuery (Google, 2012) introdujo la separación de storage y cómputo y el modelo de pago por query. Almacenar petabytes de datos cuesta céntimos; procesarlos cuesta por la cantidad de datos escaneados.
Snowflake (2014) llevó la separación storage-cómputo más lejos con warehouses elásticos que escalan independientemente. Necesitas más potencia de transformación? Subes el warehouse durante la ejecución y lo bajas después.
Redshift (Amazon, 2013) democratizó el data warehouse en la nube, aunque su modelo de clusters fijos se parece más al on-premise que a BigQuery o Snowflake.
Con cómputo elástico y barato, ejecutar transformaciones pesadas dentro del warehouse dejó de ser un problema técnico. Lo que antes requería un servidor ETL dedicado ahora se ejecuta como SQL en Snowflake. Y SQL es un lenguaje que muchas más personas dominan que Java o Python, lo que democratizó el acceso al data engineering.
ELT: las ventajas reales
Simplicidad arquitectónica. En lugar de tres sistemas (fuente, motor ETL, warehouse), tienes dos: fuente y warehouse. El motor de transformación es el propio warehouse. Menos sistemas, menos puntos de fallo, menos infraestructura que gestionar.
Velocidad de iteración. Cambiar una transformación en dbt es editar una query SQL, ejecutar dbt run y ver resultados en minutos. Cambiar una transformación en Informática requiere abrir un entorno de desarrollo propietario, modificar un mapping visual, publicar, desplegar y ejecutar. La diferencia en feedback loop es de órdenes de magnitud.
Version control nativo. Los modelos de dbt son ficheros SQL en un repositorio Git. Puedes hacer code review de una transformación de datos con el mismo flujo que usas para código de aplicación. Los ETL clásicos almacenan su lógica 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 automático. dbt genera un grafo de dependencias entre todos los modelos automáticamente. Puedes ver qué tablas alimentan un dashboard con un solo comando. En ETL clásico, reconstruir el linaje requiere herramientas externas o documentación manual.
ETL: cuándo sigue siendo la respuesta correcta
El discurso “ELT para todo” ignora escenarios reales donde ETL clásico sigue siendo superior:
Datos sensibles que no deben cargarse en crudo. Si tienes datos con PII (información personal identificable) que debe anonimizarse o pseudonimizarse antes de entrar en el warehouse, necesitas transformar antes de cargar. Cargar datos con DNIs, números de cuenta o historiales médicos en un staging área del warehouse para luego transformarlos es un riesgo de compliance. La anonimización 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 día pero la transformación es trivial (renombrar campos, convertir tipos, filtrar registros inválidos), ejecutar esa transformación dentro de Snowflake genera un coste de cómputo significativo. Un pipeline Spark que transforme y cargue directamente puede ser 5-10x más barato para ese patrón específico.
Integraciones operacionales. Si los datos transformados no van a un warehouse sino a un sistema operacional (un CRM, un ERP, una API), el patrón ELT no aplica. Necesitas ETL o una herramienta de integración (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 más coste-efectivo que Fivetran + Snowflake + dbt. Las herramientas del modern data stack tienen costes mínimos que no siempre se justifican para volúmenes pequeños.
El coste real: la conversación que nadie tiene
El modern data stack (Fivetran + Snowflake + dbt Cloud) es elegante, productivo y potencialmente caro. Desglose típico 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 más expertise de ingeniería para mantener. Pero para una empresa que procesa 10 millones de registros al día (que es mucho para la mayoría de las pymes), PostgreSQL con partitioning y buenos índices puede ser suficiente.
El error común 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 migración: ETL a ELT
Si decides migrar de ETL clásico a ELT, estos son los pasos que hemos validado en proyectos reales:
Fase 1: Inventario y priorización. Documenta todos los pipelines ETL existentes: fuentes, transformaciones, destinos, frecuencia, SLA. Prioriza la migración por impacto (los pipelines que alimentan decisiones críticas de negocio primero) y complejidad (los más 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 traducción automática; es una reescritura. Aprovecha para limpiar lógica que se acumuló durante años: CTEs en lugar de tablas temporales encadenadas, nomenclatura consistente, documentación inline.
Fase 4: Validación 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 había 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 días por si acaso.
Tiempo típico: 2-6 meses para una migración de 20-50 pipelines, dependiendo de la complejidad de las transformaciones y la disponibilidad del equipo.
El patrón híbrido: la respuesta pragmática
La mayoría de las organizaciones que asesoramos acaban con un patrón híbrido:
- 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 anonimización pre-carga, formatos complejos que necesitan parseo, e integraciones operacionales que no pasan por el warehouse.
No es purista, pero funciona. Y en ingeniería de datos, “funciona” es más valioso que “es elegante.”
Qué preguntar antes de elegir
Antes de decidir entre ETL y ELT (o híbrido), responde estas cinco preguntas:
- Qué volumen de datos procesas al día? Por debajo de 10 millones de registros, cualquier patrón funciona. Por encima de 100 millones, el coste de cómputo en el warehouse importa.
- Tus datos tienen PII que debe anonimizarse? Si es que sí, necesitas transformación pre-carga para esos datos.
- Tu equipo sabe SQL? Si la mayoría del equipo domina SQL, ELT con dbt es el camino natural. Si el equipo es más fuerte en Python/Java, ETL con Spark o Airflow puede ser más productivo.
- Cuál es tu presupuesto mensual para infraestructura de datos? Si es inferior a 500 EUR/mes, el modern data stack probablemente no se justifica.
- 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 elección del patrón de carga influye directamente en la arquitectura. Las respuestas definen el patrón. No la moda, no el blog de Snowflake, no lo que usa tu vecino. Tus datos, tu equipo, tu presupuesto.