ETL vs ELT: quin patró triar el 2026

El debat ETL contra ELT s'ha tornat religiós els darrers anys. Twitter de dades, conferències, venedors de plataforma — tothom t'explica per què el seu patró és el bo i l'altre és mort. La realitat pràctica a escala mid-market és més avorrida: tots dos patrons són útils, et calen els dos en moments diferents del cicle de vida del negoci, i triar el patró equivocat per a la teva fase et costa mesos de runway i una factura cloud sorprenentment alta.

Això és el que apliquem quan arrenquem una arquitectura de dades des de zero per a una empresa entre 50 i 500 persones.

Les definicions, en una frase

ETL (Extract, Transform, Load): extreus les dades de l'origen, les transformes en un procés intermedi i carregues el resultat net al destí. El destí només veu dades llestes per al consum.

ELT (Extract, Load, Transform): extreus les dades de l'origen, les carregues crues al destí (típicament un warehouse cloud) i fas la transformació dins el warehouse amb SQL. El destí guarda cru + transformat, i la transformació s'executa quan cal.

La diferència operativa real, no la teòrica: a ETL el coll d'ampolla és la màquina que fa la transformació. A ELT el coll d'ampolla és el warehouse, que escala millor — però també factura millor.

La comparativa que importa

Aquesta taula sona òbvia. El que veiem en projectes reals és que les empreses trien ELT per moda — perquè "warehouse modern" és el que es porta — sense passar per la pregunta del cost i la càrrega operativa. I la factura cloud arriba a final de mes amb sorpresa.

Quan l'ETL clàssic encara és la resposta correcta

Tres situacions on l'ETL clàssic és l'opció de menor cost i menor risc:

1. El teu volum mensual és contingut i estable. Si el que mous cada mes cap en gigabytes i no en terabytes, muntar un warehouse cloud complet és overkill. Un servei sobre Azure Functions o AWS Lambda corrent cada nit ho resol sense cost recurrent significatiu.

2. Tens poques fonts i són estables. Si la teva informació de negoci viu al teu ERP (Business Central, Dynamics, Sage X3) més un o dos sistemes més, i aquests no canvien d'esquema cada setmana, muntar ETL directe contra aquestes APIs és el més ràpid. El dia que aparegui la cinquena font, et planteges migrar.

3. Hi ha dades que no poden sortir de la teva infraestructura. Dades financeres sensibles, informació subjecta a compliance, sector regulat. ETL local (transformació dins la teva VPC, només el resultat anonimitzat va on es consulta) continua sent l'opció més senzilla per complir.

Quan ELT modern és la resposta per defecte

Tres situacions on ELT bat ETL gairebé sempre:

1. Tens 5 fonts o més i creixen. Cada font nova en ETL és un script nou a mantenir. En ELT amb connectors estàndard, una font nova és una configuració que apliques i oblides.

2. L'equip de negoci demana preguntes noves cada setmana. ELT et deixa respondre demà el que et van preguntar avui, perquè la dada crua ja està carregada i només cal escriure SQL nou. ETL t'obliga a planificar la transformació abans.

3. Tens analistes que escriuen SQL. ELT fa que SQL sigui la llengua de l'equip — els analistes poden contribuir transformacions, no només dashboards. Això multiplica la productivitat sense contractar ningú nou.

La trampa del "modern"

ELT mal muntat costa més que ETL ben fet. Els tres errors que veiem repetir-se:

Carregar-ho tot al warehouse per defecte. Carregar taules que ningú no consultarà et costa diners en emmagatzematge i, pitjor, alenteix les consultes que sí importen. Decideix quines fonts val la pena carregar abans de connectar el primer connector. La selectivitat al començament es tradueix en factura raonable als 6 mesos.

Fer transformacions sense tests automàtics. Sense tests a cada model és una bomba de rellotgeria. Les dades es desincronitzen en silenci i el dashboard menteix. Quan algú se n'adona, ja ningú no confia en els números. Cada model necessita com a mínim dos tests: uniqueness a la clau primària i not_null a les columnes que mostres a l'usuari final.

No mesurar el cost de les consultes. Cada warehouse cloud cobra diferent — alguns per TB escanejat, altres per hora de clúster, altres per warehouse-segon. Un dashboard mal escrit pot multiplicar la teva factura per cinc sense que ningú se n'adoni fins al tall de mes. Monitoritza cost per equip i per consulta les primeres 6 setmanes i posa alertes.

Com triar segons la fase

L'elecció entre ETL i ELT no és tècnica — és de fase de negoci. Tres senyals que indiquen un canvi de fase:

• Passes de 3 fonts de dades a 7+ en un trimestre. És hora de pensar en ELT.
• L'equip dedica més temps a mantenir pipelines que a construir nous casos d'ús. És hora de pensar en ELT.
• La teva factura del warehouse creix més ràpid que el volum de dades. És hora de revisar si segueixes en l'ELT correcte o estàs pagant per excessos arquitectònics.

L'stack concret varia segons el client: ecosistema Microsoft, ecosistema AWS, o multi-cloud amb independència de proveïdor. L'important no és la marca — és si la teva fase justifica un warehouse cloud complet o encara no.

El pas següent si no saps en quina fase ets

L'elecció entre ETL i ELT no és tècnica — és de fase de negoci. I la resposta canvia cada 12-18 mesos a mesura que creix l'empresa.

El Diagnòstic Flash són 30-45 minuts per videotrucada en què mapegem les teves fonts de dades, calculem volum real i et diem en quina fase ets i quina és l'arquitectura mínima que t'aguanta els propers 12 mesos. Sense vendre't l'stack més car, sense vendre't el que està de moda. És gratuït i sense compromís.

Reserva un Diagnòstic Flash →