Patrones ETL vs ELT: cuándo transformar en origen o en destino

📘 Guía de Arquitectura de Datos · Parte III: Integración de datos y ETL/ELT · Capítulo 20

Hay debates tecnológicos que se resuelven con un benchmark y debates que se resuelven con una factura. El de ETL contra ELT pertenece a la segunda categoría, aunque durante años se haya vendido como si fuera de la primera. Cambiar de orden dos letras —transformar antes de cargar o cargar antes de transformar— parece un matiz semántico, casi una broma de ingenieros. Y sin embargo esa permutación determina dónde vive la lógica de negocio de una empresa, quién puede modificarla, cuánto cuesta cada ejecución, cuántos minutos u horas tarda un dato en ser utilizable y, cada vez más, si la organización cumple o incumple el RGPD sin saberlo.

Este capítulo de la Guía de Arquitectura de Datos desmonta el falso dilema generacional —«ETL es legacy, ELT es moderno»— y lo sustituye por un marco de decisión basado en coste, latencia y gobernanza, las tres variables que de verdad mueven la aguja cuando se diseña la capa de integración. Tras los fundamentos de integración de datos del capítulo anterior —eventos frente a batch, mensajería, colas y CDC—, toca responder a la pregunta que todo arquitecto se hace al diseñar un pipeline: ¿dónde transformo?

ETL y ELT: dos siglas casi idénticas, dos filosofías opuestas

Conviene empezar por definiciones autocontenidas, porque buena parte de la confusión del mercado nace de usar las siglas con ligereza.

ETL (Extract, Transform, Load) es el patrón de integración en el que los datos se extraen de los sistemas origen, se transforman en un motor intermedio dedicado y se cargan ya depurados, conformados y modelados en el destino analítico. El motor intermedio puede ser un servidor de una herramienta clásica —Informatica PowerCenter, IBM DataStage, Talend, SSIS, Pentaho—, un clúster de Spark o un conjunto de procesos a medida. Lo esencial es que el destino solo recibe datos «terminados»: cuando una fila aterriza en el data warehouse, ya ha sido limpiada, estandarizada, enriquecida y validada. El área de staging existe, pero es un espacio técnico, transitorio y normalmente invisible para el consumidor.

ELT (Extract, Load, Transform) es el patrón en el que los datos se extraen y se cargan en crudo —o casi en crudo— en el destino, y la transformación se ejecuta después, dentro del propio almacén, aprovechando su motor de procesamiento. El destino suele ser un data warehouse cloud (Snowflake, BigQuery, Redshift, Synapse/Fabric) o un lakehouse (Databricks, Iceberg sobre objeto). La transformación se expresa casi siempre en SQL gestionado como código —con dbt como herramienta canónica—, y el dato crudo se conserva como capa permanente (la zona raw o bronze de una arquitectura por capas), lo que permite re-transformar el histórico cuando cambia la lógica de negocio sin volver a extraer nada del origen.

La diferencia operativa más profunda no está en el orden de las letras sino en tres consecuencias que se derivan de él. Primera: quién pone el cómputo. En ETL la transformación consume recursos de una infraestructura dedicada que hay que dimensionar, licenciar y operar; en ELT consume créditos, slots o DBUs del almacén de destino, con un modelo de pago por uso. Segunda: qué se persiste. ETL descarta el dato intermedio; ELT conserva el crudo para siempre, con todo lo bueno (reprocesado, auditoría, casos de uso futuros) y todo lo malo (coste, superficie de exposición de datos sensibles) que eso implica. Tercera: quién puede tocar la lógica. La transformación ETL vive en herramientas especializadas dominadas por un equipo de integración; la transformación ELT vive en SQL versionado en Git, accesible a cualquier perfil analítico con conocimientos de ingeniería básicos —el famoso analytics engineer—.

Una aclaración de consultoría que evita muchos malentendidos en comités de arquitectura: ETL/ELT y batch/streaming son ejes distintos. Se puede hacer ETL en micro-batch y ELT alimentado por streaming; el patrón responde a dónde se transforma, no a cada cuánto se mueve el dato. Quien quiera repasar el eje temporal —eventos, colas, CDC— tiene el capítulo anterior dedicado íntegramente a ello.

Por qué ETL dominó durante tres décadas y por qué ELT ha conquistado el data stack moderno

Para entender cuándo conviene cada patrón hay que entender por qué existe cada uno, porque ninguno nació de un capricho: cada patrón es la respuesta racional a la economía del hardware de su época.

En los años noventa y dos mil, cuando Kimball e Inmon escribían los manuales que todavía hoy estructuran el data warehousing, el almacenamiento y el cómputo del warehouse eran carísimos y venían soldados en la misma máquina. Un appliance de Teradata o una instancia de Oracle para análisis se compraban por adelantado, se amortizaban en años y tenían una capacidad finita que había que proteger. En ese mundo, cargar datos crudos en el warehouse era un despilfarro indefendible: cada gigabyte ocupado por datos sin depurar era un gigabyte que no estaba disponible para el dato útil, y cada ciclo de CPU gastado en limpiar ficheros era un ciclo robado a las consultas de negocio. La conclusión era obvia: se transformaba fuera, en servidores baratos de propósito general, y al warehouse solo entraba lo imprescindible, perfectamente modelado. Sobre esa lógica se construyó toda una industria de herramientas ETL —PowerCenter, DataStage, SSIS, Pentaho, Talend— y toda una disciplina profesional.

El terremoto llegó entre 2012 y 2016 con tres ondas sucesivas. Primero, los data warehouses cloud (Redshift en 2012, el despegue de BigQuery, Snowflake en 2014) rompieron el acoplamiento físico: el almacenamiento pasó a costar céntimos por gigabyte y mes sobre object storage, y el cómputo pasó a alquilarse por segundos, escalando de cero a cientos de nodos bajo demanda. Segundo, esos motores MPP demostraron que transformaban datos con SQL más rápido y más barato que la mayoría de los servidores ETL intermedios: ¿qué sentido tenía sacar los datos a una máquina pequeña para procesarlos, si el destino era un superordenador elástico? Tercero, en 2016 apareció dbt y profesionalizó la transformación dentro del almacén: SQL modular, versionado en Git, con tests, documentación y linaje generados automáticamente. La combinación de un extractor gestionado (Fivetran, Airbyte, Stitch), un warehouse elástico y dbt cristalizó en lo que el mercado bautizó como modern data stack, y el ELT pasó de ser una rareza a ser el patrón por defecto de cualquier proyecto analítico nuevo.

Pero la historia no termina ahí, y aquí es donde el análisis de Dataprix se separa del relato de los vendedores. Hacia 2022-2024, las organizaciones que habían abrazado el ELT sin reservas empezaron a descubrir las facturas de cómputo descontroladas —el célebre bill shock de créditos de warehouse—, los data swamps de tablas crudas sin catalogar y un problema regulatorio serio: replicar datos personales en crudo dentro de la plataforma analítica multiplica la superficie de exposición justo cuando el RGPD y sus equivalentes exigen lo contrario. El péndulo no ha vuelto al ETL clásico, pero sí a un punto intermedio pragmático: el patrón EtLT —con una «t» minúscula de transformación ligera en vuelo— que veremos más adelante. En nuestra valoración, esta es hoy la posición de equilibrio para la mayoría de las medianas y grandes empresas europeas.

Coste: la economía de la transformación, o dónde duele la factura

La primera variable del marco de decisión es la económica, y es menos intuitiva de lo que parece porque ETL y ELT no tienen costes distintos: tienen estructuras de coste distintas. Comparar el precio de una licencia de Informatica con el de los créditos de Snowflake es comparar peras con kilovatios.

El coste del ETL clásico es mayoritariamente fijo y anticipado: licencias o suscripciones de la herramienta, infraestructura del motor de transformación —dimensionada para el pico, no para la media—, y sobre todo el coste de ingeniería de un equipo especializado que diseña, desarrolla y mantiene los flujos. A cambio, la ejecución marginal es barata y predecible: una vez construido, el job nocturno cuesta prácticamente lo mismo cada noche, y la transformación se ejecuta una sola vez por dato. Es un modelo que recuerda al CAPEX: caro de entrar, estable de operar, y financieramente cómodo para organizaciones que presupuestan a año vista.

El coste del ELT es mayoritariamente variable y diferido: la extracción y carga suelen pagarse por volumen (filas activas mensuales en Fivetran, por ejemplo), y la transformación se paga cada vez que se ejecuta, en créditos, slots o DBUs del almacén. Eso significa que decisiones aparentemente menores de un analista —programar un modelo con full refresh horario en vez de incremental, materializar como tabla lo que debería ser vista, consultar sistemáticamente la capa cruda en lugar de la curada— se convierten en partidas de gasto recurrente. La paradoja del ELT es que democratiza la capacidad de transformar y, con ella, la capacidad de gastar: donde antes solo un equipo de integración podía generar coste de cómputo, ahora puede hacerlo cualquier persona con acceso a SQL.

La aritmética que recomendamos llevar a cualquier comité es esta: el ELT resulta más barato cuando la relación entre lecturas y transformaciones es alta y los modelos están bien diseñados (incrementalidad, particionado, materializaciones correctas), porque se aprovecha un motor elástico ya pagado para el análisis; y el ETL conserva ventaja cuando los volúmenes son masivos, las transformaciones son pesadas y repetitivas, y la frecuencia es estable, porque ejecutar una sola vez en infraestructura amortizada gana a re-ejecutar en cómputo premium. Hay un tercer factor que casi nadie incluye en el Excel y debería: el coste del talento. Un stack ELT sobre SQL y dbt recluta en un mercado amplísimo de perfiles analíticos; un stack ETL propietario depende de especialistas escasos y caros de una herramienta concreta, con el riesgo de rotación que eso supone.

Un apunte de FinOps que desarrollaremos en el capítulo dedicado a costes: en plataformas ELT conviene instaurar desde el primer día presupuestos y alertas de consumo por equipo, etiquetado de cargas (query tagging), revisión mensual de los diez modelos más caros y una política explícita de materializaciones. Las organizaciones que lo hacen mantienen el gasto de transformación entre el 15 % y el 25 % del coste total del warehouse; las que no, descubren en la renovación anual que la transformación consume más que el propio análisis que la justifica.

Latencia y frescura: cuánto tarda el dato en ser utilizable

La segunda variable es el tiempo, y exige precisión conceptual: en integración de datos no hay una latencia, hay dos. La latencia de disponibilidad mide cuánto tarda el dato en aterrizar en la plataforma desde que se genera en el origen. La latencia de usabilidad mide cuánto tarda en estar transformado, validado y listo para que alguien tome una decisión con él. Los dos patrones reparten estas latencias de forma opuesta, y confundirlas es la causa de muchas decepciones.

En ETL, ambas latencias coinciden: el dato no existe en el destino hasta que ha pasado por toda la cadena de transformación, de modo que cuando llega, llega utilizable. El precio es que la ventana de proceso —históricamente nocturna— marca el ritmo de toda la organización: si el job de las 02:00 falla y el reproceso dura cuatro horas, el negocio abre la mañana sin datos del día anterior. En ELT, la latencia de disponibilidad se desploma —cargar en crudo es rápido y barato, y con CDC puede bajar a minutos— pero la latencia de usabilidad depende de la cadencia de las transformaciones: ese dato crudo que llegó en minutos puede tardar horas en atravesar las capas bronze, silver y gold si los modelos dbt corren cada cuatro horas. La ventaja real del ELT no es que todo sea más rápido, sino que desacopla ambas latencias y permite ajustar la frescura por caso de uso: el cuadro de mando financiero puede refrescarse a diario mientras el modelo de stock se recalcula cada quince minutos, cada uno pagando solo el cómputo que su SLA exige.

De ahí una recomendación de consultoría que ahorra discusiones estériles: antes de discutir patrones, documentar el SLA de frescura de cada dominio de datos —«ventas a D+1», «stock a 15 minutos», «riesgo intradía»— y dimensionar el pipeline para cumplirlo, ni más ni menos. Perseguir el tiempo real por defecto es uno de los errores más caros de la disciplina: cada orden de magnitud de reducción de latencia multiplica el coste y la complejidad operativa, y si el caso de uso exige verdadero tiempo real (segundos), la respuesta ya no es ni ETL ni ELT, sino una arquitectura de streaming con CDC como la que trataremos en el capítulo 23 con Debezium y la replicación log-based.

Gobernanza: la variable que decide más proyectos de lo que parece

La tercera variable es la menos glamurosa y, en Europa, la más decisiva. Porque la pregunta «¿dónde transformo?» esconde otra mucho más seria: ¿qué datos estoy dispuesto a dejar aterrizar, en crudo, en mi plataforma analítica?

El ETL clásico tiene aquí una virtud estructural que el discurso del modern data stack tiende a olvidar: al transformar antes de cargar, permite aplicar minimización, enmascarado y anonimización antes de que el dato sensible toque el destino. Es la traducción técnica directa del principio de minimización del artículo 5.1.c del RGPD: a la zona analítica solo llega lo necesario, ya pseudonimizado, y la superficie de exposición se reduce en origen. Para sectores regulados —banca, salud, administración pública— y para arquitecturas con requisitos de residencia del dato, esta propiedad no es un detalle: es a menudo el requisito que el DPO pone encima de la mesa antes de hablar de tecnología.

El ELT invierte el planteamiento: replica el dato con fidelidad total al destino, datos personales incluidos, y confía la protección a los controles del almacén —cifrado, seguridad a nivel de columna y fila, enmascarado dinámico, auditoría de accesos—. Los warehouses modernos ofrecen estas capacidades y bien configuradas son sólidas, pero el matiz jurídico-operativo es importante: la copia cruda existe, está sujeta a derechos ARSOPL (el derecho de supresión se complica notablemente cuando el dato vive en una capa raw inmutable y en sus time travels y snapshots), amplía el alcance de cualquier DPIA y convierte un eventual incidente de seguridad en un incidente con datos personales. Quien elija ELT puro con datos sensibles debe presupuestar, desde el día uno, la ingeniería de gobernanza que lo hace defendible —clasificación automática de PII en la ingesta, políticas de acceso por etiquetas, retención diferenciada de la capa cruda— y no tratarla como una mejora futura.

Sería injusto, no obstante, cerrar el balance de gobernanza en contra del ELT, porque en otra dimensión lo gana con claridad: la gobernanza de la propia lógica de transformación. En el mundo ETL clásico, la lógica vive dentro de una herramienta propietaria, en flujos gráficos cuya trazabilidad depende del rigor del equipo; el linaje es el que la herramienta quiera exportar. En el mundo ELT con dbt, la transformación es código en Git: revisable en pull requests, testeada en CI, documentada y con linaje generado automáticamente hasta el nivel de columna. Para un auditor —interno o externo—, poder responder «¿de dónde sale esta cifra?» con un grafo de dependencias versionado es un salto cualitativo respecto a bucear en un repositorio de mappings. La síntesis honesta es esta: ETL gobierna mejor el dato sensible; ELT gobierna mejor la lógica que lo transforma. Y esa tensión es exactamente la que el patrón híbrido viene a resolver.

Más allá del binario: EtLT, reverse ETL y la promesa del zero-ETL

Si este capítulo terminara con una elección binaria estaría mintiendo, porque las arquitecturas reales de 2026 rara vez son ETL o ELT puros. El mercado ha decantado varios patrones intermedios que conviene conocer por su nombre, aunque las siglas empiecen a rozar la parodia.

EtLT —extract, small transform, load, transform— es el híbrido dominante y, en nuestra valoración, el punto de llegada natural para la mayoría de las organizaciones medianas y grandes. Consiste en aplicar una transformación ligera en vuelo, durante la ingesta —enmascarado o tokenización de PII, deduplicación, conversión de formatos y tipos, filtrado de campos prohibidos— y dejar la transformación pesada de negocio para el destino, gobernada como código. La «t» minúscula resuelve el problema de gobernanza del ELT puro (el dato sensible nunca aterriza en claro) sin renunciar a sus ventajas (capa cruda re-procesable, lógica en SQL versionado, cómputo elástico). La mayoría de las herramientas de ingesta gestionadas —Fivetran, Airbyte, Estuary, los conectores de Glue o Data Factory— incorporan ya estas transformaciones en vuelo precisamente porque sus clientes europeos las exigían.

Reverse ETL es el patrón complementario que cierra el círculo: una vez calculadas las métricas y los segmentos en el warehouse, se sincronizan de vuelta hacia las herramientas operativas —el CRM, la plataforma de marketing, el sistema de soporte— donde los equipos de negocio realmente trabajan. Herramientas como Census o Hightouch popularizaron la categoría, hoy en plena consolidación (la propia Fivetran adquirió Census en 2025). Su lección arquitectónica es valiosa: el warehouse deja de ser una estación término y se convierte en el centro de distribución de datos de la compañía, lo que multiplica el valor de hacer bien la capa de transformación… y la criticidad de gobernarla.

Zero-ETL es la etiqueta más marketiniana del lote: integraciones nativas entre el sistema operacional y el analítico del mismo proveedor —Aurora hacia Redshift en AWS, las réplicas federadas de BigQuery, el espejo de bases de datos en Microsoft Fabric— que replican los datos automáticamente sin pipeline explícito. Funcionan, simplifican de verdad la ingesta dentro de un mismo ecosistema y eliminan una clase entera de mantenimiento. Pero conviene leer la letra pequeña con ojos de arquitecto: zero-ETL significa cero pipelines de extracción, no cero transformación —el dato llega crudo y todo lo discutido en este capítulo sigue aplicando aguas abajo—, y su contrapartida estratégica es un acoplamiento profundo al proveedor que conviene contrastar con los criterios anti lock-in del capítulo 4 de esta guía. Mención aparte merece la virtualización de datos (con Denodo como referente), que para ciertos casos de consulta federada evita mover el dato por completo: no sustituye al ELT analítico de gran volumen, pero lo complementa donde la copia física no se justifica.

El marco de decisión: siete preguntas antes de elegir patrón

Reunidas las tres variables, el método que proponemos para decidir es deliberadamente prosaico: siete preguntas, respondidas con honestidad y por escrito, antes de evaluar ninguna herramienta. Primera: ¿el destino tiene un motor de cómputo potente y elástico? Sin warehouse MPP o lakehouse, el ELT sencillamente no es viable; transformar dentro de un PostgreSQL operacional no es ELT, es una avería anunciada. Segunda: ¿qué sensibilidad tienen los datos? Si hay categorías especiales del artículo 9 del RGPD o datos financieros regulados, la transformación ligera previa a la carga (EtLT) o el ETL con anonimización dejan de ser opcionales. Tercera: ¿qué SLA de frescura exige cada dominio? Documentado por dominio, no como aspiración genérica de «tiempo real». Cuarta: ¿qué perfil tiene el equipo? Un equipo fuerte en SQL y Git rinde de inmediato en ELT; un equipo formado durante años en una suite ETL gráfica tiene allí un activo que no conviene tirar a la basura por una moda. Quinta: ¿qué estructura de coste tolera mejor la organización? Hay direcciones financieras que prefieren licencia fija y previsible, y otras que exigen OPEX variable; ambas posturas son legítimas y condicionan el patrón. Sexta: ¿cuánto pesa el legacy? Cientos de flujos ETL estables y documentados no se migran «porque sí»: se migran cuando el coste de mantenerlos supera al de reescribirlos, dominio a dominio. Y séptima: ¿cuánta dependencia de proveedor se está dispuesto a aceptar? El ELT profundiza el compromiso con el warehouse elegido; el zero-ETL lo convierte casi en matrimonio.

Cuatro sectores, cuatro respuestas distintas a la misma pregunta

Nada ilustra mejor que el patrón es contextual que ver cómo lo resuelven sectores distintos con restricciones distintas. Los cuatro escenarios siguientes están construidos sobre situaciones recurrentes en proyectos reales del mercado español y europeo.

Fintech: EtLT con tokenización obligatoria. Una entidad de pagos europea como la que protagonizó el caso práctico de la Parte II no puede permitir que un número de tarjeta o un identificador de cliente aterrice en claro en su lakehouse: el alcance PCI DSS y el RGPD lo convierten en línea roja. El patrón resultante es EtLT de libro: tokenización y pseudonimización en vuelo durante la ingesta —el dato sensible se sustituye por tokens antes de tocar la zona bronze— y transformación de negocio en el destino con dbt, donde el antifraude y el reporting regulatorio trabajan sobre datos completos pero protegidos. La capa cruda tokenizada conserva la propiedad que el regulador más aprecia: reproducibilidad total del cálculo de cualquier cifra reportada, años después, sin exposición adicional.

E-commerce: ELT puro y la factura que enseñó FinOps. Un retailer online mediano es el hábitat natural del ELT: decenas de fuentes SaaS —plataforma de comercio, pasarela de pagos, herramientas de marketing, logística de última milla—, equipo de datos pequeño y presión por iterar rápido la analítica de campaña. Conectores gestionados, warehouse cloud y dbt permiten que tres personas operen lo que hace una década exigía un departamento. El riesgo característico es el económico, y el guion se repite con tanta frecuencia que merece contarse: tras un trimestre de crecimiento, la factura de warehouse de uno de estos retailers se triplicó sin que el volumen de negocio lo justificara; la auditoría reveló que la mitad del gasto eran modelos con full refresh horario que nadie consultaba más de una vez al día, más dashboards apuntando directamente a tablas crudas. La corrección —modelos incrementales, cadencias por SLA real, capa de consumo obligatoria— recortó el 40 % del gasto en un mes. Moraleja: en ELT, el diseño de materializaciones es una decisión financiera, no solo técnica.

Salud: donde el ETL clásico sigue siendo la respuesta correcta. Un hospital o un grupo asistencial maneja categorías especiales de datos (artículo 9 RGPD), formatos propios (HL7, DICOM), sistemas departamentales antiguos y, con frecuencia, requisitos estrictos de residencia que mantienen la plataforma analítica on-premise o en nube soberana. Aquí el patrón dominante sigue siendo ETL con anonimización o seudonimización previa a la carga: la historia clínica se transforma y des-identifica en un entorno controlado, y a la zona de explotación e investigación solo llegan datos minimizados conforme a la finalidad. No es atraso tecnológico: es la arquitectura que el DPO puede defender ante una inspección, y un recordatorio de que «moderno» no es sinónimo de «adecuado».

Logística: ELT con agregación temprana para domar la telemetría. Una operadora de transporte con miles de vehículos emitiendo posición y telemetría cada pocos segundos se encuentra el problema inverso: el volumen crudo es tan masivo que cargarlo íntegro al warehouse es tirar el dinero. La solución habitual es un híbrido con «t» de agregación: reducción en vuelo —compactación de pings, cálculo de tramos, descarte de redundancia, que recorta el volumen en más de un 90 %— seguida de ELT sobre lakehouse para el análisis de rutas, consumos y SLA de entrega. El crudo completo, cuando se conserva, va a almacenamiento frío barato con políticas de retención agresivas, aplicando los criterios de tiering del capítulo 14.

Anti-patrones: las siete formas más caras de equivocarse

La experiencia acumulada del sector permite catalogar los errores recurrentes con bastante precisión. Reconocerlos a tiempo vale, literalmente, presupuestos enteros.

1. El «load and forget». Adoptar ELT como excusa para cargarlo todo «por si acaso» y posponer indefinidamente la transformación. El resultado es un data swamp: cientos de tablas crudas sin contrato, sin dueño y sin catálogo, sobre las que cada analista improvisa su propia versión de la verdad. ELT sin disciplina de modelado no es un patrón de integración: es procrastinación con factura de almacenamiento.

2. La migración 1:1. Traducir mecánicamente cientos de jobs de la herramienta ETL legacy a SQL sobre el warehouse, mapping a mapping, sin repensar el modelo. Se hereda toda la deuda técnica, se pierde la optimización que la herramienta original sí aplicaba y se descubre tarde que el coste de re-ejecutar esa lógica ineficiente en cómputo premium supera al de la licencia que se quería ahorrar. Las migraciones que funcionan se hacen por dominios de negocio, rediseñando, y conviven con el legacy durante meses.

3. El SQL espagueti. La barrera de entrada baja del ELT es su mayor virtud y su mayor riesgo: sin revisión de código, tests ni convenciones, la capa de transformación degenera en vistas de tres mil líneas que nadie se atreve a tocar. La transformación en el destino exige las mismas prácticas de ingeniería que cualquier software —modularidad, CI/CD, tests de datos, entornos— o acaba siendo el nuevo legacy, solo que sin soporte del fabricante.

4. El full refresh por defecto. Reconstruir tablas enteras en cada ejecución cuando un modelo incremental procesaría el 1 % del volumen. Es el generador silencioso de bill shock número uno en plataformas ELT, agravado cuando la cadencia se fija «cada hora» sin que ningún SLA lo pida.

5. La doble verdad. Mantener transformaciones paralelas e inconsistentes —parte en el ETL heredado, parte en dbt, parte incrustada en la herramienta de BI— de modo que el mismo KPI tiene tres valores según dónde se mire. Toda lógica de negocio debe tener una única implementación canónica y un único dueño; lo demás es erosión de confianza a cámara lenta.

6. PII en crudo al alcance de todos. Cargar datos personales sin transformación ligera previa ni controles de columna, fiándolo todo a «ya lo protegeremos». Cada día que esa capa existe es riesgo regulatorio acumulado, y los permisos amplios concedidos «temporalmente» tienen una notable tendencia a volverse permanentes.

7. Elegir patrón por moda. Implantar ELT porque lo hace todo el mundo —o aferrarse al ETL porque «siempre se hizo así»— sin haber respondido las siete preguntas del marco anterior. El patrón correcto es una consecuencia del contexto; cuando se convierte en una declaración identitaria, la arquitectura ha dejado de ser ingeniería.

Selección de software: criterios para no comprar el problema

La elección de herramienta llega, deliberadamente, al final del capítulo: primero el patrón, luego el producto. Cuando toque evaluar, estos son los criterios que recomendamos puntuar de forma explícita, y que desarrollamos con detalle de producto en la guía comparativa de herramientas ETL y en el TOP 10 de integración de datos de Dataprix.

El primer filtro es la cobertura de conectores, evaluada contra el inventario real de fuentes de la organización —incluidos el ERP y los sistemas locales habituales— y no contra la cifra total del catálogo: de nada sirven seiscientos conectores si falta el que importa. El segundo, el modelo de precios y su proyección a tres años con los volúmenes propios: por filas activas (estilo Fivetran), por capacidad, por créditos de cómputo o por licencia; cada modelo castiga un perfil de crecimiento distinto, y la simulación de TCO debe incluir el cómputo de transformación en el warehouse, que es donde el ELT esconde la parte sumergida del iceberg. El tercero, las opciones de despliegue y residencia: SaaS puro, híbrido o autoalojado (Airbyte y Pentaho siguen siendo las referencias open source), con procesamiento en región UE si la política de datos lo exige. El cuarto, las capacidades nativas de CDC para las fuentes críticas, que anticipan el capítulo 23. El quinto, la filosofía de transformación —gráfica (Talend, Pentaho, SSIS, Matillion, Informatica), código (dbt, Spark) o mixta— alineada con el perfil real del equipo. El sexto, la integración con el ecosistema de orquestación y observabilidad existente: alertas, reintentos, linaje, métricas de frescura exportables. Y el séptimo, la estrategia de salida: qué costaría irse, qué es exportable y cuánto del trabajo quedaría atrapado en formatos propietarios.

Un consejo final de procurement que rara vez falla: exigir una prueba de concepto con datos y volúmenes propios sobre los tres conectores más difíciles del inventario —no sobre los tres más fáciles de la demo del comercial— y medir en ella coste real, latencia real y comportamiento ante fallos. Las diferencias que importan suelen aparecen ahí.

Checklist operativo

🎓 Formación recomendada

Para llevar estos patrones del papel a la práctica, esta es la formación que mejor encaja con el contenido del capítulo:

Preguntas frecuentes (FAQ)

¿Cuál es la diferencia entre ETL y ELT?
En ETL los datos se transforman en un motor intermedio antes de cargarse en el destino analítico; en ELT se cargan primero en crudo en el data warehouse o lakehouse y se transforman después dentro de él, aprovechando su motor de cómputo. La diferencia práctica está en dónde se ejecuta y se paga la transformación, qué datos se persisten y quién puede modificar la lógica.

¿Es ELT siempre más moderno y mejor que ETL?
No. ELT es el patrón por defecto del data stack moderno cloud, pero ETL sigue siendo la respuesta correcta cuando los datos sensibles no deben aterrizar en crudo en la plataforma analítica (sectores regulados, requisitos estrictos de residencia) o cuando existe un parque ETL estable cuya migración no se justifica económicamente. El patrón adecuado se deduce del coste, la latencia y la gobernanza de cada caso, no del calendario.

¿Qué es el patrón EtLT?
Es el híbrido dominante en 2026: una transformación ligera en vuelo durante la ingesta (enmascarado o tokenización de datos personales, deduplicación, normalización de formatos) seguida de la transformación pesada de negocio dentro del destino, gestionada como código. Combina la protección temprana del dato sensible propia del ETL con la flexibilidad y el cómputo elástico del ELT.

¿Cuándo resulta más caro ELT que ETL?
Cuando los modelos se reconstruyen completos en cada ejecución (full refresh) con cadencias no justificadas por ningún SLA, cuando los consumidores consultan la capa cruda en lugar de la curada y cuando los volúmenes de transformación son masivos, pesados y estables. En esos escenarios, re-ejecutar la lógica en cómputo premium del warehouse supera el coste de una infraestructura de transformación dedicada y amortizada.

¿Cómo afecta el RGPD a la elección entre ETL y ELT?
El RGPD favorece minimizar y proteger los datos personales lo antes posible. El ETL —y la «t» ligera del EtLT— permite enmascarar o tokenizar antes de que el dato aterrice en la plataforma analítica, reduciendo la superficie de exposición. El ELT puro replica datos en crudo, lo que exige controles compensatorios en el destino (clasificación de PII, acceso por etiquetas, enmascarado dinámico, retención de la capa cruda) y complica el derecho de supresión sobre capas inmutables y snapshots.

¿Zero-ETL elimina la necesidad de transformar los datos?
No. Zero-ETL elimina el pipeline de extracción y carga entre servicios de un mismo proveedor (por ejemplo, de la base operacional al warehouse), pero el dato llega crudo: el modelado, la limpieza y la lógica de negocio siguen siendo necesarios aguas abajo. Es una simplificación valiosa de la ingesta, con el coste estratégico de un mayor acoplamiento al proveedor.

En resumen

La pregunta «¿ETL o ELT?» es de las pocas de la arquitectura de datos que se responde con un método y no con una opinión. ETL transforma antes de cargar y protege el destino; ELT carga antes de transformar y aprovecha el destino. El primero gobierna mejor el dato sensible y ofrece costes predecibles; el segundo gobierna mejor la lógica, desacopla la frescura por caso de uso y democratiza la transformación, con el riesgo financiero y de calidad que toda democratización conlleva. Entre ambos, el EtLT —proteger en vuelo, transformar en destino, gobernar como código— se ha consolidado como el equilibrio razonable para la empresa europea que maneja datos personales sobre un warehouse cloud. Decidir exige responder por escrito a siete preguntas sobre coste, latencia, gobernanza, equipo, presupuesto, legacy y dependencia de proveedor; todo lo demás —la herramienta incluida— es consecuencia.

En el próximo capítulo bajaremos del patrón a la realidad con una muestra de stack de herramientas: una comparativa práctica de Airflow, Prefect, dbt, NiFi y Kafka, cinco nombres que aparecen en muchas de las conversaciones de integración moderna, con sus solapamientos, sus papeles reales y los criterios para combinarlos sin redundancia.

Recursos y lecturas recomendadas

Para profundizar con fuentes primarias:
El ensayo fundacional de dbt Labs sobre qué es dbt y su guía de buenas prácticas explican la filosofía de la transformación en destino de boca de sus creadores;
Fundamentals of Data Engineering de Joe Reis y Matt Housley (O'Reilly, 2022) dedica capítulos enteros al ciclo de ingesta y transformación con criterio independiente de proveedor;
The Data Warehouse ETL Toolkit de Ralph Kimball sigue siendo una referencia de ETL para modelado dimensional que ningún patrón ha jubilado;
La FinOps Foundation publica el marco de gestión de costes cloud aplicable al cómputo de transformación;
En Dataprix, la comparativa de herramientas ETL 2026, la guía práctica de dbt en español y la sección de integración de datos completan el contexto de producto.

📘 Ver el índice completo de la Guía de Arquitectura de Datos

Contenido elaborado con asistencia de inteligencia artificial — Equipo Editorial Dataprix. Verifica la información antes de tomar decisiones. Última actualización: junio de 2026.