ETL vs ELT: qué patrón elegir en 2026

La discusión ETL vs ELT se ha vuelto religiosa en los últimos años. Twitter de datos, conferencias, vendedores de plataforma — todos te explican por qué su patrón es el bueno y el otro está muerto. La realidad práctica a escala mid-market es más aburrida: ambos patrones son útiles, hacen falta los dos en momentos distintos del ciclo de vida del negocio, y elegir el equivocado para tu fase te cuesta meses de runway y una factura cloud sorprendentemente alta.

Esto es lo que aplicamos cuando arrancamos una arquitectura de datos desde cero para una empresa entre 50 y 500 empleados.

Las definiciones, en una frase cada una

ETL (Extract, Transform, Load): extraes los datos del origen, los transformas en un proceso intermedio y cargas el resultado limpio en el destino. El destino ve datos ya listos para consumo.

ELT (Extract, Load, Transform): extraes los datos del origen, los cargas crudos en el destino (típicamente un warehouse cloud) y haces la transformación dentro del warehouse usando SQL. El destino guarda crudo + transformado, y la transformación se ejecuta cuando hace falta.

La diferencia operativa real, no la teórica: en ETL el cuello de botella es la máquina que hace la transformación. En ELT el cuello de botella es el warehouse, que escala mejor — pero también factura mejor.

La comparativa que importa

Esta tabla suena obvia. Lo que vemos en proyectos reales es que las empresas eligen ELT por moda — porque "warehouse moderno" es lo que se lleva — sin pasar por la pregunta de coste y carga operativa. Y la factura cloud llega a fin de mes con sorpresa.

Cuándo ETL clásico todavía es la respuesta correcta

Tres situaciones donde ETL clásico es la opción de menor coste y menor riesgo:

1. Tu volumen mensual es contenido y estable. Si lo que mueves cada mes cabe en gigabytes y no en terabytes, montar un warehouse cloud completo es overkill. Un servicio sobre Azure Functions o AWS Lambda ejecutándose cada noche resuelve la vida sin coste recurrente significativo.

2. Tienes pocas fuentes y son estables. Si tu información de negocio vive en tu ERP (Business Central, Dynamics, Sage X3) más uno o dos sistemas más, y esos no cambian de esquema cada semana, montar ETL directo contra esas APIs es lo más rápido. El día que aparezca la quinta fuente, te planteas migrar.

3. Hay datos que no pueden salir de tu infraestructura. Datos financieros sensibles, información sujeta a compliance, sector regulado. ETL local (transformación dentro de tu VPC, solo el resultado anonimizado va al sitio donde se consulta) sigue siendo la opción más sencilla para cumplir.

Cuándo ELT moderno es la respuesta default

Tres situaciones donde ELT supera a ETL casi siempre:

1. Tienes 5+ fuentes y crecen. Cada fuente nueva en ETL es un script nuevo que mantener. En ELT con conectores estándar, una fuente nueva es una configuración que aplicas y olvidas.

2. El equipo de negocio pide preguntas nuevas cada semana. ELT te deja responder mañana lo que te preguntaron hoy, porque la data cruda ya está cargada y solo tienes que escribir SQL nuevo. ETL te obliga a planificar antes la transformación.

3. Tienes analistas que escriben SQL. ELT hace SQL la lengua del equipo — los analistas pueden contribuir transformaciones, no solo dashboards. Esto multiplica la productividad sin contratar a nadie nuevo.

La trampa del "moderno"

ELT mal montado cuesta más que ETL bien hecho. Los tres errores que vemos repetirse:

Cargar todo al warehouse por defecto. Cargar tablas que nadie va a consultar te cuesta dinero en almacenamiento y, peor, ralentiza las queries que sí importan. Decide qué fuentes valen la pena cargar antes de conectar el primer conector. La selectividad al principio se traduce en factura razonable a los 6 meses.

Hacer transformaciones sin tests automáticos. Sin tests en cada modelo es una bomba de tiempo. Los datos se desincronizan silenciosamente y el dashboard miente. Cuando alguien lo descubre, ya nadie confía en los números. Cada modelo necesita al menos dos tests: uniqueness en la clave primaria y not_null en las columnas que muestras al usuario final.

No medir coste de queries. Cada warehouse cloud cobra diferente — algunos por TB escaneado, otros por hora de cluster, otros por warehouse-segundo. Un dashboard mal escrito puede multiplicar tu factura por cinco sin que nadie se entere hasta el corte de mes. Monitoriza coste por equipo y por consulta las primeras 6 semanas y pon alertas.

Cómo elegir según fase

La elección entre ETL y ELT no es técnica — es de fase de negocio. Tres señales que indican un cambio de fase:

• Pasas de 3 fuentes de datos a 7+ en un trimestre. Es hora de pensar en ELT.
• El equipo dedica más tiempo a mantener pipelines que a construir nuevos casos de uso. Es hora de pensar en ELT.
• Tu factura del warehouse crece más rápido que tu volumen de datos. Es hora de revisar si estás en el ELT correcto o pagando por excesos arquitectónicos.

El stack concreto varía según el cliente: ecosistema Microsoft, ecosistema AWS, o multi-cloud con independencia de proveedor. Lo importante no es la marca — es si tu fase justifica un warehouse cloud completo o todavía no.

El siguiente paso si no sabes en qué fase estás

La elección entre ETL y ELT no es técnica — es de fase de negocio. Y la respuesta cambia cada 12-18 meses a medida que crece la empresa.

El Diagnóstico Flash son 30-45 minutos por videollamada en los que mapeamos tus fuentes de datos, calculamos volumen real y te decimos en qué fase estás y cuál es la arquitectura mínima que te aguanta los próximos 12 meses. Sin venderte el stack más caro, sin venderte el más de moda. Es gratis y sin compromiso.

Reserva un Diagnóstico Flash →