ETL vs ELT: qué es cada uno y cuál necesitas de verdad

ETL es el proceso que mueve datos de donde se generan a donde se analizan: extract (extraer de las fuentes), transform (transformar al formato que necesita el análisis) y load (cargar en el destino). ELT es exactamente lo mismo con las dos últimas letras cambiadas de orden: se carga primero el dato en bruto y se transforma después, ya dentro del almacén. Suena a detalle de fontanería interna, y durante quince años lo fue. Hoy no: ese cambio de orden decide quién puede tocar la lógica de negocio, cuánto cuesta el almacén a fin de mes y qué pasa cuando alguien pregunta «¿por qué este número no cuadra?».

Esta guía va de elegir con criterio, no de abrazar la moda. Verás qué es ETL, qué cambia con ELT, cuándo conviene cada uno y qué se rompe si eliges mal. Sin diagramas de arquitectura imposibles: una empresa mediana con un ERP, un CRM, una tienda online y tres hojas de cálculo críticas tiene suficiente complejidad.

¿Qué es ETL y por qué nació así?

ETL es el patrón clásico del almacén de datos. Un proceso programado —normalmente de noche— se conecta a cada fuente, saca los registros nuevos, los limpia y los reorganiza en un servidor intermedio, y solo entonces escribe el resultado en el destino. Al almacén llega el dato ya masticado: tablas con el formato definitivo, columnas con nombres entendibles, claves que casan.

Nació así por una razón muy prosaica: el almacén era caro y lento. En los noventa y los dos mil, la capacidad de cálculo de la base de datos de destino era el recurso escaso. Hacer la transformación fuera, en una máquina dedicada, era la única forma sensata de no colapsarlo. La consecuencia de diseño es que la transformación vive en una herramienta aparte, con su propio lenguaje, y la mantiene un perfil técnico especializado.

Un ETL típico en una empresa mediana hoy:

• Cada noche a las 02:00 se lee la tabla de facturas del ERP que cambiaron en las últimas 24 horas.
• Se normalizan los NIF, se descartan las facturas anuladas, se convierte la moneda y se cruza con el maestro de clientes.
• Se escribe una tabla `ventas_diarias` limpia en el almacén, lista para el cuadro de mando.
• Si algo falla a mitad, el proceso se para y por la mañana el cuadro de mando muestra los datos de anteayer.

¿Qué cambia en ELT?

En ELT se invierte el orden: se extrae de la fuente y se carga tal cual —o casi— en el almacén, en una zona de aterrizaje. La transformación ocurre después, dentro del propio almacén, con consultas SQL que crean tablas derivadas a partir de ese dato en bruto.

El motivo del cambio es que la restricción se dio la vuelta. Los almacenes modernos en la nube separan el almacenamiento del cálculo, escalan en segundos y se facturan por uso. Guardar el dato en bruto ya no es caro; transformarlo dentro del almacén ya no es un problema de capacidad. Si el recurso escaso ya no es la máquina, no tiene sentido mantener una pieza de software intermedia solo para hacer lo que el destino hace mejor.

Las consecuencias prácticas, que importan más que la teoría:

• Guardas el dato original. Si dentro de seis meses descubres que la regla de «cliente activo» estaba mal, rehaces la transformación sobre el histórico. En ETL, ese histórico en bruto no existe: solo tienes el resultado de la regla mala.
• La transformación se escribe en SQL. Deja de ser propiedad exclusiva de un especialista en la herramienta y pasa a estar al alcance de cualquier analista decente.
• La lógica vive en el control de versiones. Archivos de texto, revisados y versionados como código, en lugar de cajas y flechas dentro de una interfaz gráfica.
• Pagas por calcular. Cada vez que alguien reconstruye un modelo, el contador corre. Esto se vuelve relevante más rápido de lo que la gente espera.

ETL vs ELT: comparativa honesta

| | ETL | ELT | |---|---|---| | Dónde se transforma | En una herramienta intermedia | Dentro del almacén | | Qué llega al destino | Dato ya limpio y modelado | Dato en bruto + capas derivadas | | Coste dominante | Licencias y servidor del ETL | Cómputo y almacenamiento del almacén | | Quién mantiene la lógica | Perfil especializado en la herramienta | Analistas con SQL | | Rehacer el histórico | Difícil: no guardas el original | Directo: reprocesas la zona en bruto | | Dato personal | Se puede filtrar antes de cargar | Entra al almacén y hay que gobernarlo allí | | Fuentes raras o muy sucias | Mejor: transformas donde quieras | Peor: SQL no lo arregla todo | | Tiempo hasta el primer cuadro de mando | Semanas | Días |

Dos lecturas que conviene no perder de vista. La primera: ELT gana en flexibilidad y velocidad, y pierde en control del dato que entra. La segunda: esto no es blanco o negro. Casi todo lo que funciona en producción es ETL ligero en la extracción —un poco de normalización y filtrado al salir de la fuente— y ELT para el resto.

¿Cuándo conviene ETL y cuándo ELT?

Elige ELT si te reconoces en esto: tu destino es un almacén en la nube, tus fuentes son sistemas con API razonable (ERP, CRM, tienda, publicidad), quieres que varias personas puedan construir métricas sin cuello de botella y prevés que las definiciones de negocio van a cambiar. Es el caso de la mayoría de proyectos que arrancan hoy de cero.

Elige ETL si pesa alguna de estas:

• Dato personal sensible. Si la fuente trae historiales clínicos, datos de nómina o cualquier categoría especial, filtrar o seudonimizar antes de cargar es una decisión de diseño que te ahorra discusiones. Lo que nunca entra al almacén no hay que protegerlo dentro de él. Lo contamos en detalle en anonimización de datos.
• El destino es caro de calcular o rígido. Si el almacén es una base de datos clásica en tu propio centro de datos, transformar dentro es exactamente el problema que ETL vino a resolver.
• Fuentes que no son tablas. Ficheros de posición fija de un sistema de los noventa, XML con cinco niveles de anidamiento, PDF. SQL no es la herramienta. Transforma fuera y carga el resultado.
• Volumen enorme con uso estrecho. Si ingieres cien veces más dato del que vas a consultar, cargarlo todo en bruto es pagar almacén por basura. Filtra antes.

La pregunta útil no es «¿ETL o ELT?», sino «¿dónde quiero que viva la definición de cliente activo, y quién tiene que poder cambiarla sin abrir un ticket?».

¿Qué cambia en coste de verdad?

Aquí es donde las comparativas de internet mienten por omisión. No se trata de comparar el precio de dos licencias.

En ETL, el coste es previsible y en buena parte fijo: licencia de la herramienta, servidor donde corre, y —la partida grande— las horas de la persona que sabe mantenerla. Esa persona es un cuello de botella: cada cambio de métrica pasa por su cola. El coste real no está en la factura, está en las tres semanas que tarda en estar disponible una métrica nueva.

En ELT, el coste es variable y se dispara por descuido. Patrones que hemos visto romper presupuestos:

• Reconstruir todas las tablas derivadas cada hora cuando el dato de origen se actualiza una vez al día.
• Reprocesar el histórico completo en cada ejecución en lugar de solo lo que cambió.
• Un cuadro de mando sin caché que lanza una consulta pesada cada vez que alguien lo abre.
• Cargar tablas enteras de sistemas que nadie consulta, «por si acaso».

Ninguno es culpa del modelo ELT: son decisiones de implementación. Pero el modelo las hace fáciles de cometer y tardías de detectar, porque la factura llega a fin de mes. Pon un aviso de gasto el primer día, no el tercer mes.

¿Quién puede tocar la transformación?

Este es el argumento decisivo y el que menos se discute en los comités donde se elige herramienta.

En ETL, la lógica de negocio está dentro de un producto. Para saber por qué el margen se calcula así hay que abrir la herramienta, encontrar el flujo y leer la caja correcta. Quien no tiene licencia ni formación, no puede. En la práctica eso significa que una persona entiende cómo se calculan los números de la empresa. Si se va, se va con ella.

En ELT con la transformación en SQL versionado, la lógica es texto plano que cualquiera puede leer, buscar y comentar. Un control de cambios con revisión de otra persona deja de ser una aspiración y pasa a ser el procedimiento por defecto. Eso es gobierno del dato de verdad: no un documento, un sitio donde está la definición y un historial de quién la cambió y por qué.

La contrapartida es honesta: si cualquiera puede crear tablas, en seis meses tienes cuarenta versiones de «ventas». Necesitas convención de nombres, una capa final clara de la que bebe el cuadro de mando y alguien que diga que no. Nada de eso es una herramienta: es calidad de datos y disciplina.

¿Cómo montar el primero sin equiparte de más?

Un orden que funciona en empresa mediana, de menos a más compromiso:

1. Elige una pregunta de negocio, no un sistema. «Margen por cliente y mes» obliga a traer ventas, costes y el maestro de clientes. «Vamos a integrar el ERP» no acaba nunca. 2. Inventaria las fuentes de esa pregunta. Para cada una: cómo se extrae, con qué frecuencia cambia, qué campos necesitas y si lleva dato personal. Esta tabla decide tu arquitectura mejor que cualquier comparativa. 3. Carga en bruto, con marca de tiempo. Una tabla por fuente, los campos tal cual, más la fecha de carga. No limpies todavía. 4. Transforma en capas. Bruto → limpio (tipos, duplicados, claves) → negocio (las métricas con nombre y dueño). Tres capas, no siete. 5. Define un indicador de frescura. «Este cuadro de mando se actualizó a las 06:12» visible en la propia pantalla. La mitad de las crisis de confianza en los datos son en realidad crisis de frescura mal comunicada. 6. Pon control de coste antes de ampliar. Un aviso y una revisión mensual de las consultas más caras. Diez minutos al mes. 7. Solo entonces añade la segunda pregunta. Si la primera no se usa, la segunda tampoco se usará.

Si al terminar el paso 4 ves que una de las fuentes exige acrobacias que SQL no da, esa fuente concreta se extrae con transformación previa. Mezclar está bien. Lo que no está bien es mezclar sin haberlo decidido.

Errores que cuestan meses

• Elegir herramienta antes que pregunta. Se compra la plataforma y luego se busca qué cargar. Siempre sale caro.
• Transformar en la carga «para ahorrar espacio». Guardar el bruto cuesta céntimos. Perderlo cuesta reconstruir seis meses de histórico que ya no está en la fuente porque el ERP solo conserva dos años.
• Replicar el modelo del ERP en el almacén. El ERP está diseñado para operar, no para analizar. Copiarlo tabla a tabla te deja con el mismo laberinto, solo que más lejos.
• No registrar qué se cargó y cuándo. Sin registro de ejecuciones, el día que faltan datos la investigación empieza desde cero.
• Meter dato personal en el almacén sin decidirlo. Entra en el primer volcado «para probar» y tres años después sigue ahí, replicado en cuatro entornos.

Preguntas frecuentes

¿ELT ha dejado obsoleto a ETL?

No. ELT es el valor por defecto razonable para proyectos nuevos sobre almacén en la nube, pero ETL sigue siendo la opción correcta cuando hay que filtrar dato sensible antes de cargarlo, cuando las fuentes no son tabulares o cuando el destino cobra caro cada cálculo. La mayoría de arquitecturas reales combinan los dos.

¿Necesito un almacén de datos para hacer ELT?

Sí, o algo que haga su papel: un sistema que separe almacenamiento de cálculo y aguante consultas pesadas sin afectar a la operación. Si tu única base de datos es la del ERP, transformar dentro de ella es mala idea. Antes de montar nada, conviene valorar si realmente hace falta: lo tratamos en data warehouse para pymes.

¿Cuánto tarda en estar listo el primer caso?

Con fuentes accesibles por API y una sola pregunta de negocio acotada, entre tres y seis semanas hasta un cuadro de mando en el que la dirección confía. Lo que alarga el plazo casi nunca es la tecnología: son los accesos a los sistemas y ponerse de acuerdo en qué significa cada métrica.

¿Quién debería mantener esto, mi equipo o un proveedor?

El patrón que mejor envejece es que un proveedor monte la base y deje la lógica en SQL versionado dentro de vuestro repositorio, y que alguien interno —normalmente un analista, no un programador— asuma los cambios del día a día. Si la lógica se queda dentro de una herramienta del proveedor, dependes de él para cada métrica nueva.

---

Si estás decidiendo esto ahora y no tienes claro qué fuentes aguantarán el modelo que quieres montar, el orden sensato es mirar primero lo que ya tienes: qué sistemas hay, qué dato sale de cada uno y qué se rompe hoy. Eso es exactamente lo que hacemos en la auditoría, y sale de ahí con un mapa de fuentes y una recomendación de arquitectura concreta, no un catálogo de productos. Si ya lo tienes claro y lo que quieres es contrastarlo con alguien que haya montado unos cuantos, hablemos.