ELT on-premise: el patrón del que nadie habla (y que quizá ya estás usando)

Por Carlos Fernández  ·  Arquitecto de datos  |  Análisis · Arquitectura de datos

Trabajo como arquitecto de datos, y la mayor parte de los almacenes que diseño viven on-premise, así que esta idea me toca de cerca. Se ha colado en muchas conversaciones sobre datos de los últimos años: que ELT es sinónimo de cloud. Que para cargar el dato en crudo y transformarlo después necesitas un almacén analítico en la nube —Snowflake, BigQuery, Redshift, Databricks— y, a poder ser, dbt facilitándolo todo. Es una idea cómoda, repetida en mil artículos y webinars, y, por lo que veo cada día, no se ajusta del todo a la realidad.

ELT no es una tecnología ni una característica de producto. Es una decisión de arquitectura: dónde y cuándo transformas los datos. Y esa decisión se puede tomar igual de bien sobre un SQL Server o un Oracle dentro de tu centro de datos que sobre un data warehouse en la nube. De hecho, miles de organizaciones llevan décadas haciendo ELT on-premise sin haberlo llamado nunca así. Lo que ocurre es que el relato dominante ha dejado ese patrón huérfano, y eso es un problema para todas las empresas —muchas en España— que siguen, y seguirán, con sus datos en casa por coste, soberanía o cumplimiento.

ETL vs ELT: la diferencia está en dónde ocurre la T

Antes de defender el patrón conviene definirlo con precisión, porque la confusión empieza aquí. La diferencia entre ETL y ELT no está en las herramientas ni en si usas la nube. Está en un único punto: el momento y el lugar en que transformas el dato.

En ETL (Extract – Transform – Load), el dato se extrae del origen, se transforma en un motor intermedio —la propia herramienta ETL, una zona de staging separada— y solo entonces, ya transformado, se escribe en el destino. En ELT (Extract – Load – Transform), el orden cambia: el dato se carga primero en crudo en el destino y se transforma después, dentro del propio motor de destino, aprovechando su capacidad de cómputo. Esa inversión del orden es toda la diferencia.

Nótese que en esta definición no aparece la palabra "nube" por ningún lado. ELT solo exige dos cosas: que el motor de destino tenga capacidad para transformar de forma eficiente y que el lenguaje de transformación sea SQL conjuntista. Un SQL Server, un Oracle o un PostgreSQL on-premise cumplen ambas. La nube no es un requisito; es, en realidad, una comodidad.

Por qué asociamos ELT con la nube (y por qué es un malentendido)

Si ELT no necesita la nube, ¿por qué los tenemos tan unidos en nuestra mente? La explicación es cultural y comercial, no técnica. El término ELT se popularizó masivamente entre 2016 y 2020, justo cuando despegaban los almacenes analíticos en la nube y dbt. El argumento de venta era irresistible: "los data warehouses cloud son tan baratos y elásticos que puedes permitirte cargar todo el crudo y transformarlo dentro, sin preprocesar nada". La separación de almacenamiento y cómputo hacía el ELT no solo posible, sino económicamente atractivo. Y así, ELT quedó asociado a la nube en el imaginario colectivo del sector.

Pero el patrón es muy anterior a esa etiqueta. Las bases de datos analíticas on-premise llevan desde los años noventa cargando datos y transformándolos con SQL dentro del propio motor: es el clásico pushdown de Teradata u Oracle, o lo que durante años se llamó, sin más, "ETL con procedimientos almacenados". Nadie lo bautizó como ELT porque el término todavía no existía, pero conceptualmente era exactamente eso: cargar y transformar en el destino. El marketing del modern data stack reescribió la historia y se quedó con la autoría de una idea que ya estaba inventada.

Cómo se hace ELT on-premise, en la práctica

El patrón, despojado de marketing, es sencillo y robusto. Se extrae el dato de los orígenes —con conectores, con un orquestador, incluso con scripts— y se aterriza en crudo en una zona de carga del propio motor analítico. A partir de ahí, toda la transformación se hace con SQL dentro de ese motor: vistas para las transformaciones ligeras, procedimientos almacenados con operaciones MERGE para las cargas incrementales y los históricos, y un diseño por capas que ordene el flujo.

Ese diseño por capas suele seguir hoy el patrón Medallion —Bronze (crudo), Silver (limpio y conformado), Gold (modelo de negocio)—, que muchos asocian erróneamente al data lake cloud pero que encaja igual de bien sobre un motor relacional on-premise. Es, en el fondo, la evolución del clásico staging → ODS → data marts de toda la vida. La clave arquitectónica, igual que en la nube, es que el orquestador orquesta pero no transforma: SSIS, Airflow, Apache Hop o un simple planificador lanzan la secuencia y controlan los reintentos, mientras el cómputo pesado vive donde debe, en el motor de datos.

¿Y dónde queda dbt, el estandarte del ELT moderno? También funciona on-premise: existen adaptadores como dbt-sqlserver y dbt-postgres que permiten llevar al mundo on-premise la disciplina que ha hecho famoso a dbt —SQL versionado, tests de datos, documentación y linaje automáticos—. El matiz que sí hay que admitir es que esos adaptadores están menos pulidos que los de los data warehouses cloud, así que muchas organizaciones optan por transformaciones en SQL "artesanal" (vistas y procedimientos almacenados). Funciona, pero conviene saber que se renuncia a los tests y al linaje automáticos que dbt genera automáticamente, y que hay que construir esa disciplina a mano. Quien quiera comparar opciones de orquestación y transformación encontrará una guía práctica en nuestra comparativa de herramientas de integración de datos.

Lo cuento desde mi propia práctica: en los almacenes que diseño, toda la transformación vive en el motor —vistas para el conformado, procedimientos con MERGE para el modelo de negocio—, orquestada por una herramienta que se limita a coordinar. No echo de menos la nube para esto. Lo que sí echo de menos a veces es la disciplina de tests que en dbt ya vienen de serie y que, por este camino, hay que construir a mano. Es el precio del control total, y conviene pagarlo a conciencia en lugar de olvidarlo.

Cuándo tiene sentido el ELT on-premise (y cuándo no)

Defender que el patrón existe no es defender que sea siempre la mejor opción. Tiene sentido cuando ya cuentas con un motor analítico potente on-premise y no quieres infrautilizarlo; cuando trabajas con datos sensibles o sujetos a soberanía —sanidad, administración pública, banca, sectores donde el RGPD y la residencia del dato pesan más que cualquier otra cosa—; cuando el coste de migrar a la nube no está justificado para tus volúmenes; o cuando tienes un equipo fuerte en SQL que rinde más transformando en el motor que aprendiendo un stack nuevo. Para buena parte del tejido empresarial español —PYME y mediana empresa, con infraestructura ya amortizada y exigencias de cumplimiento—, estas condiciones se dan con frecuencia.

Conviene pensárselo, en cambio, cuando los volúmenes empiezan a desbordar la capacidad de tu motor on-premise: aquí aparece el límite real del patrón, que no es de corrección sino de elasticidad. También cuando necesitas escalar el cómputo de forma puntual y masiva (picos de transformación que de otro modo competirían con tus cargas operativas), o cuando la organización ya ha decidido, por estrategia, moverse al cloud. En esos escenarios, el ELT en la nube ofrece ventajas que on-premise no puede replicar sin comprar hierro extra para soportar el pico.

Lo que cambia respecto al ELT en la nube

Para que esto no suene a defensa acrítica del on-premise, conviene ser claro con las renuncias. Frente al ELT cloud, con on-premise pierdes dos cosas. La primera es la elasticidad: la separación de almacenamiento y cómputo que permite escalar bajo demanda y pagar por uso no existe; tu cómputo es fijo, las transformaciones pesadas compiten con el resto de cargas y tienes que dimensionar para el pico (capex, no opex). La segunda es parte del instrumental moderno: dbt rinde mejor sobre los warehouses cloud, y funciones nativas como las tablas dinámicas no tienen equivalente directo on-premise.

Pero —y este es el punto— lo que no pierdes es la validez del patrón ni sus beneficios esenciales: la simplicidad de cargar el crudo y dejar que el motor haga lo que mejor sabe hacer, que es SQL conjuntista. Las renuncias son de elasticidad y de tooling, no de corrección. Confundir ambas cosas es justamente el error que lleva a tantas empresas a asumir que "hacer las cosas bien" obliga a migrar a la nube. No obliga.

Otro matiz que poco se comenta: tu "Bronze" no tiene por qué guardarlo todo

Hay una pieza del dogma del modern data stack que conviene cuestionar específicamente en on-premise: la idea de que la capa Bronze —la del crudo— debe guardarlo todo para siempre, como archivo histórico inmutable y reproducible. Esa práctica nació donde el almacenamiento es baratísimo: el object storage en la nube (S3, ADLS). En On-premise, persistir todo el histórico crudo en tablas tiene un coste real —disco caro, índices, backups— y obliga a una lógica de selección incremental que añade complejidad.

En mi opinión, ese coste no siempre compensa. Si tus orígenes son re-suministrables (puedes volver a extraer) y el histórico lo conservas en las capas transformadas (Silver y Gold), un Bronze transitorio —que guarde solo la carga de cada ejecución y se sobrescriba— simplifica enormemente: cargar a Silver se reduce a "selecciona todo lo que hay". Lo que cedes a cambio es la auditoría punto-en-el-tiempo ("qué nos envió exactamente el origen el día X") y el reproceso sin re-extraer. Si eso te hace falta —por ejemplo, por requisitos de auditoría—, la solución ligera no es un Bronze persistente completo, sino un archivo de dato en bruto acotado (ficheros comprimidos con retención rodante, por ejemplo) sólo para auditoría y reproceso reciente. Es la idea del data lake adaptada con cabeza al mundo on-premise, no copiada por inercia.

En mi caso, actualmente lo hago así: uso la capa bronce como staging transitorio —guarda solo la carga de cada ejecución y se sobrescribe en la siguiente—, de modo que pasar a la siguiente capa es, literalmente, "selecciona todo lo que hay". Si pasa algo en la carga sé que ahí siempre tengo los datos de la última carga, y al menos ahí sí que puedo reprocesar sin volver a acudir al origen. Pero, ¿existen muchos más casos en los que sea necesario reprocesar? Sí, pero no son lo habitual, y para datos de tiempo atrás me aporta más seguridad volver a obtenerlos del origen que reprocesar una copia de una extracción anterior, porque los datos cambian cada dia.

Asumo a cambio que la auditoría punto-en-el-tiempo no vive en esa capa, sino en las transformadas y en poder volver a extraer del origen en caso de tener que reprocesar datos de cargas anteriores. Para mi contexto, el intercambio compensa con holgura: me ahorro mantener un histórico de datos en bruto y toda la lógica de selección incremental que arrastraría.

Conclusión: el cloud no es un requisito para hacer ELT

La moraleja es sencilla: el mejor patrón de integración no es el que más resuena, sino el que tu organización puede operar bien. ELT es una decisión de arquitectura —cargar primero, transformar en el destino— que funciona genial sobre un motor on-premise, y que muchas empresas ya están aplicando sin saber que tiene nombre. Reconocerlo tiene un valor práctico: si sabes que haces ELT on-premise, puedes hacerlo deliberadamente bien con un diseño por capas claro, una capa de tests de datos, un orquestador que solo orqueste y una estrategia de carga incremental robusta.

El discurso cloud-nativo seguirá dominando los titulares, pero la realidad del tejido empresarial —y muy especialmente del español, con su peso de sectores regulados y de infraestructura on-premise amortizada— es más variada de lo que esos titulares sugieren. Para profundizar en esta decisión, el capítulo dedicado a ETL frente a ELT de nuestra Guía práctica de Arquitectura de Datos entra en el detalle de cuándo transformar en origen o en destino, con sus costes y compromisos.

Preguntas frecuentes

¿Se puede hacer ELT sin estar en la nube?
Sí. ELT es un patrón arquitectónico —cargar el dato en crudo y transformarlo dentro del motor de destino—, no una característica del cloud. Cualquier motor analítico con capacidad de cómputo y SQL conjuntista (SQL Server, Oracle, PostgreSQL) puede ejecutarlo on-premise.

¿ELT on-premise necesita dbt?
No es obligatorio. dbt aporta disciplina (tests, linaje, documentación) y funciona on-premise con adaptadores como dbt-sqlserver o dbt-postgres, aunque menos pulidos que en la nube. También se puede hacer ELT con vistas y procedimientos almacenados, asumiendo que esa disciplina habrá que construirla a mano.

¿ETL o ELT para un proyecto on-premise?
Depende de dónde tenga más sentido transformar. Si tu motor analítico tiene capacidad de sobra, ELT (transformar en el destino con SQL) suele ser más simple y aprovecha mejor el motor. Si el destino está limitado o necesitas preprocesar antes de cargar, ETL clásico puede encajar mejor. No es una elección de moda, sino de capacidad y caso de uso.

¿El diseño Medallion es solo para data lakes en la nube?
No. El patrón Bronze / Silver / Gold organiza el flujo de transformación por capas y encaja igual de bien sobre un motor relacional on-premise. Es, en esencia, la evolución del clásico staging → ODS → data marts.

¿Por qué casi no se habla del ELT on-premise?
Por una cuestión cultural y comercial: el término ELT se popularizó de la mano de los almacenes cloud y dbt entre 2016 y 2020, y el marketing lo presentó como un diferencial de la nube. El patrón, sin embargo, se hace on-premise desde hace décadas, antes con el nombre de "ETL con procedimientos almacenados".

Artículo de Carlos Fernández, elaborado con asistencia de inteligencia artificial. Última actualización: junio de 2026.

Etiquetas: ELT · ETL · on-premise · integración de datos · arquitectura de datos · Medallion · data warehouse · SQL Server · dbt · data engineering