ETL vs ELT vs Reverse ETL: Modern data stack för svenska bolag

Jag får ofta frågan om vad skillnaden mellan ETL och ELT egentligen är, och om Reverse ETL bara är ett buzzword. Det är tre olika svar på tre olika frågor, och om du blandar ihop dem bygger du fel sak. I den här texten reder jag ut vad de tre faktiskt gör och hur jag tänker när jag väljer mönster för ett svenskt bolag som inte har obegränsad budget.

Innan jag går in på de enskilda mönstren vill jag slå fast en sak. Valet handlar inte bara om teknik utan om vem som ska leva med lösningen. Ett mönster som ditt team förstår och kan ändra på egen hand är nästan alltid värt mer än ett som ser elegant ut men kräver en specialist varje gång något ska justeras. Jag återkommer till den principen flera gånger, eftersom den oftare avgör vad som blir rätt än de tekniska detaljerna i sig.

ETL: städa innan du lagrar

I klassisk ETL hämtar du data, transformerar den i ett separat steg och laddar sedan in det färdiga resultatet i målet. Det var standarden när lagring var dyrt och beräkning utanför databasen var billigare. Du betalade för att bara spara det du behövde.

Mönstret lever kvar där det finns starka krav på att känslig data aldrig får landa i råform, till exempel när personuppgifter måste maskeras innan de ens lagras. Då är det rimligt att transformera först.

ELT: lagra först, transformera i lagret

Med moderna molnlager vände ekonomin. Lagring blev billigt och beräkning i lagret skalbart. I ELT laddar du in rådatan som den är och transformerar inuti lagret med verktyg som dbt. Det ger dig full historik och möjlighet att bygga om modeller utan att hämta om från källan.

• Du behåller rådatan och kan rätta misstag i transformationerna i efterhand.
• Transformationerna versionshanteras som kod i stället för att gömmas i ett ETL-verktyg.
• Du slipper en separat beräkningsmiljö och betalar i stället för lagrets kapacitet.

För de flesta bolag jag jobbar med är ELT förstavalet i dag. Det är därför vi bygger nästan all vår leverans av dataplattform kring ett lager där transformationerna lever som kod nära datan.

Reverse ETL: skicka tillbaka insikterna

Reverse ETL är det omvända flödet. När du väl har byggt fina modeller i lagret vill du att säljaren ska se kundens hälsopoäng i sitt CRM, inte i en separat dashboard. Reverse ETL tar tabeller från lagret och synkar dem ut till operativa system som CRM och ERP.

Det är vad som gör datan användbar för människor som aldrig öppnar ett BI-verktyg. Datan möter dem där de redan jobbar. Jag går djupare på verktygsvalet i en separat jämförelse, men principen är att lagret blir källan till sanning även för operativa system.

Inkrementell laddning och historik

En fråga som avgör mer än man tror är hur du laddar data över tid. Att hämta hela källan varje natt är enkelt men blir snabbt dyrt och långsamt när volymen växer. Inkrementell laddning, där du bara hämtar det som ändrats sedan förra körningen, är ofta nödvändigt men kräver att källan kan berätta vad som är nytt, antingen via en tidsstämpel eller en logg. I ELT-världen får du dessutom en intressant möjlighet: eftersom rådatan finns kvar kan du bygga upp en historik även om källsystemet bara visar nuläget. Den som vill veta hur ett värde såg ut för tre månader sedan kan få svar, vilket ett rent operativt system sällan kan ge. Jag tänker alltid igenom historikbehovet tidigt, för det är svårt att rekonstruera historik man inte börjat spara.

Hur de hänger ihop

De tre mönstren utesluter inte varandra. En typisk modern stack använder ELT för att fylla lagret, eventuellt ett inslag av ETL för känsliga källor, och Reverse ETL för att aktivera resultatet. Jag tänker på det som en cirkel: in i lagret, förädling i lagret, ut till verksamheten.

Vanliga misstag jag ser

Det vanligaste misstaget är att hoppa direkt på Reverse ETL innan lagret har pålitliga modeller. Då synkar du dålig data snabbare, vilket inte hjälper någon. Ett annat är att hålla fast vid tung ETL av gammal vana när ELT hade varit både billigare och mer flexibelt.

Så väljer jag

Jag börjar nästan alltid med ELT, lägger till ETL bara där regelkrav tvingar mig, och inför Reverse ETL först när modellerna är stabila och någon faktiskt efterfrågar datan i ett operativt system. Vill du se hur det landat i praktiken finns konkreta exempel i vår casebook.

Relaterat

• BigQuery-dataplattform från noll: Referensarkitektur 2026
• dbt-projektstruktur: Mappar, modeller och tests som skalar
• BI-val: Looker vs Power BI vs Metabase vs Lightdash

Vill du ta det vidare?

Om du är osäker på vilket mönster din situation kräver är du välkommen att höra av dig via kontaktsidan. Jag tittar gärna på dina källor och mål och föreslår en stack som passar både budget och behov.