ETL och ELT löser samma problem på olika sätt — var transformationen sker och vem som äger logiken. Vi går igenom när varje modell vinner, vilka verktyg som dominerar 2026, och hur du väljer rätt för din dataplattforms mognad.
ETL och ELT löser samma problem — flytta data från källsystem till en plats där den går att analysera — men på fundamentalt olika sätt. Skillnaden låter teknisk, men den avgör var transformationslogiken bor, vem som äger den, vad plattformen kostar att driva och hur snabbt ni kan ändra er när verksamheten kräver det. Vi får frågan i nästan varje dataplattformsprojekt: ska vi transformera innan eller efter att datan landar?
Svaret är sällan ett binärt val för hela plattformen. I den här guiden går vi igenom vad som faktiskt skiljer modellerna åt, när ETL fortfarande vinner, varför ELT blivit standard i molnet, vilka verktyg som dominerar 2026, och hur vi rekommenderar att svenska bolag väljer — per källa, inte en gång för alltid.
Vad skiljer ETL och ELT rent tekniskt
ETL (Extract, Transform, Load) transformerar data i ett separat beräkningslager — traditionellt ett dedikerat ETL-verktyg som Informatica eller SSIS — innan den laddas in i målsystemet. Målsystemet ser bara färdigstädad data. ELT (Extract, Load, Transform) laddar rådata direkt till målplattformen och gör transformationen där, med hjälp av plattformens egen beräkningskraft — i praktiken SQL som körs i BigQuery, Snowflake eller Redshift, ofta orkestrerat av dbt.
Skillnaden är alltså inte om data transformeras, utan var och när. ETL transformerar en gång, tidigt, och kasserar ofta rådatan. ELT bevarar rådatan permanent och transformerar om och om igen i takt med att affärslogiken förändras — vilket blir avgörande så fort en definition av till exempel "aktiv kund" ändras och ni behöver räkna om historiken.
Det märks tydligast när något går fel efteråt. Med ETL upptäcker ni ofta ett fel i transformationslogiken månader senare — och då finns rådatan sällan kvar att räkna om från. Med ELT ligger rådatan orörd i warehouset, så en bugg i en dbt-modell rättas genom att köra om transformationen, inte genom att gå tillbaka till källsystemet och begära en ny export.
När ETL fortfarande vinner
ETL är inte förlegat — det är rätt val i specifika scenarier. Reglerade branscher som vård och finans kräver ofta att känsliga uppgifter maskeras, tokeniseras eller pseudonymiseras innan de överhuvudtaget landar i ett analyslager, vilket kräver transformation före lastning. Vi har byggt lösningar åt vårdaktörer där personnummer och journaluppgifter aldrig får existera i klartext utanför källsystemet — då är ETL med maskning i pipelinen inte förhandlingsbart.
ETL vinner också när ni redan har en fungerande Informatica- eller Talend-installation som sköter kritiska flöden pålitligt. Att migrera bort från ett stabilt system enbart för att ELT är trenden 2026 är sällan en bra avvägning — risken och kostnaden för en "big bang"-migrering överstiger ofta vinsten.
När ELT är rätt val — och det är oftast rätt idag
För molnbaserade dataplattformar är ELT idag standardmönstret. Lagring är billig, beräkningskraft i warehouset skalar elastiskt, och att bevara rådata gör att ni kan bygga om transformationslogiken utan att gå tillbaka till källsystemen. Vi ser att ELT står för uppåt 80–90 procent av de nya dataplattformsprojekt vi bygger åt kunder idag, oavsett om molnleverantören är Google Cloud, Snowflake eller Microsoft Fabric.
Den stora fördelen är organisatorisk snarare än teknisk: när transformationen sker i SQL inne i warehouset kan analytiker och analytikerteam bygga och äga sina egna dataset med dbt, utan att köa hos ett centralt ETL-team för varje ändring. Det är den enskilt vanligaste flaskhalsen vi löser upp när vi migrerar kunder från ETL till ELT.
| 1 | -- ELT: transformation sker i warehouset, inte i pipelinen |
| 2 | with raw_orders as ( |
| 3 | select * from {{ source('raw', 'orders') }} |
| 4 | ) |
| 5 | select |
| 6 | order_id, |
| 7 | customer_id, |
| 8 | cast(order_total as numeric) as order_total, |
| 9 | date(created_at) as order_date |
| 10 | from raw_orders |
| 11 | where order_total is not null |
Verktygslandskapet 2026
På EL-sidan (extract + load) dominerar Fivetran och Airbyte för SaaS-källor, Meltano för team som vill äga sin egen konfiguration i kod, och molnleverantörernas egna verktyg (Datastream på GCP, Data Factory på Azure) för databasnära förändringsdatafångst. På T-sidan (transform) är dbt fortfarande dominerande, men SQLMesh har vuxit snabbt 2026 tack vare bättre hantering av inkrementella modeller och virtuella miljöer för att testa ändringar utan att köra om hela plattformen. Dataform, numera nativt integrerat i BigQuery, är ett gratisalternativ för team som redan är låsta till Google Cloud.
Legacy ETL-verktyg som Informatica PowerCenter, Talend och SSIS lever fortfarande vidare i stora organisationer med tunga on-prem-investeringar, men få nya projekt startas på dem 2026.
Hybrider — Reverse ETL och ELT+
Reverse ETL har blivit ett eget lager i arkitekturen: verktyg som Hightouch och Census synkar transformerad data från warehouset tillbaka till operativa system — CRM, marknadsföringsverktyg, supportplattformar — så att den analys ni redan byggt faktiskt går att agera på där säljare och marknadsförare arbetar. Det är det snabbast växande mönstret vi ser i svenska ELT-arkitekturer just nu.
Vi bygger också ofta en hybrid vi kallar ELT+: en lätt transformation redan i inmatningssteget — typiskt maskning av personnummer eller andra känsliga fält — kombinerat med full ELT-transformation för allt övrigt. Det ger regelefterlevnaden från ETL utan att offra flexibiliteten från ELT.
Kostnadsbilden — licens mot förbrukning
ETL-verktyg som Informatica prissätts traditionellt som fasta årslicenser, ofta i storleksordningen några hundra tusen kronor per år beroende på volym och antal anslutningar, oavsett hur mycket eller lite plattformen faktiskt används. ELT flyttar den kostnaden till förbrukning: Fivetran och Airbyte Cloud tar betalt per aktiv rad (Monthly Active Rows), dbt Cloud per utvecklarplats, och själva transformationen kostar beräkningstid i warehouset — hos BigQuery per skannad TiB, hos Snowflake per aktiv sekund av ett virtuellt warehouse.
Det är varken billigare eller dyrare per definition — det är en annan riskprofil. En växande verksamhet med oförutsägbar datavolym kan få obehagliga överraskningar med förbrukningsbaserad prissättning om ingen sätter budgetgränser, medan en mogen verksamhet med stabil volym ofta sparar pengar jämfört med en fast licens dimensionerad för toppbelastning. Vi rekommenderar alltid att sätta kostnadstak per anslutning och per dbt-jobb redan från start — samma disciplin som beskrivs i vår guide till kostnadskontroll i BigQuery.
Migrera från ETL till ELT utan big bang
De flesta lyckade migreringar vi genomför sker källa för källa, inte som ett enda stort skifte. Vi kör den nya ELT-pipelinen parallellt med den befintliga ETL-processen under två till fyra veckor, jämför utdata rad för rad, och växlar över trafiken först när siffrorna stämmer i tio raka dagar. Källor med enkel, stabil logik migreras först — de ger snabba vinster och bygger förtroende för det nya mönstret. Komplexa flöden med mycket affärslogik inbakad i den gamla ETL-koden sparas till sist, när teamet har erfarenhet av att felsöka i den nya miljön.
Vår rekommendation per scenario
- Startup eller scale-up med molnnativ stack: ELT med Fivetran eller Airbyte för inmatning, dbt för transformation, BigQuery eller Snowflake som lager.
- Reglerad sektor (vård, finans) med krav på maskning: ETL eller ELT+ hybrid där känsliga fält maskeras innan lastning.
- Stort befintligt Informatica- eller SSIS-landskap: behåll ETL för kritiska, fungerande flöden — komplettera med ELT för nya källor istället för att migrera allt på en gång.
- Höga volymer strömmande data (IoT, clickstream): ELT med strömmande inmatning (Pub/Sub eller Kafka rakt in i warehouset) snarare än batch-ETL över natten.
Slutsats
Frågan är sällan "ETL eller ELT" för hela plattformen — det är var i kedjan känslig data får landas okrypterad, och vilken flexibilitet organisationen behöver när affärslogiken ändras. De flesta moderna dataplattformar vi bygger idag är ELT som standard med punktinsatser av ETL-liknande maskning där lagen kräver det. Läs mer om hur vi sätter upp en dataplattform på Google Cloud och BigQuery, eller om ni hanterar känsliga uppgifter, hur vi tänker kring datasäkerhet och regelefterlevnad.
Osäker på vilken modell som passar er datakälla? läs mer om våra tjänster eller boka ett samtal.
“ELT har vunnit standardstriden i molnet — men rätt fråga är inte ETL eller ELT, det är var i kedjan känslig data får landas okrypterad.”
- Simon Axelsson
Vanliga frågor
- Är ELT alltid bättre än ETL?
- Nej. ELT är rätt standardval för de flesta molnbaserade dataplattformar eftersom det bevarar rådata och ger flexibilitet, men om känsliga uppgifter måste maskeras innan de landar — till exempel personnummer eller journaldata — är ETL eller en ELT+-hybrid ofta det enda regelefterlevande alternativet.
- Vad kostar det att byta från Informatica eller SSIS till dbt?
- Kostnaden varierar kraftigt med antal flöden, men den största posten är sällan licenser — det är arbetet med att migrera och validera affärslogik källa för källa. Vi rekommenderar en stegvis migrering med parallellkörning snarare än en big bang, vilket sprider kostnaden och risken över flera månader istället för ett enda projekt.
- Hur hanterar vi känslig data (personnummer, journaluppgifter) i en ELT-arkitektur?
- Genom att lägga en lätt maskerings- eller tokeniseringsprocess i inmatningssteget innan data landar i det råa lagret — det vi kallar ELT+. Personnummer och andra direkta identifierare pseudonymiseras redan vid källan, medan övrig data behåller full ELT-flexibilitet i transformationslagret.
- Vad är Reverse ETL och behöver vi det?
- Reverse ETL synkar transformerad, färdig data från warehouset tillbaka till operativa system som CRM eller marknadsföringsverktyg, så att analysen faktiskt går att agera på där säljare och marknadsförare redan arbetar. Ni behöver det om era mest värdefulla insikter idag stannar i ett dashboard som operativa team sällan öppnar.
- Kan vi köra ETL och ELT parallellt i samma dataplattform?
- Ja, och det är i praktiken vanligast. De flesta plattformar vi bygger använder ELT som standard för merparten av källorna, med punktinsatser av ETL-liknande transformation eller maskning för de källor som kräver det av regel- eller säkerhetsskäl.
Om författaren
SIAX Technologys teknikteam skriver guiderna utifrån verkliga leveranser inom molninfrastruktur, dataplattformar och AI-automation åt nordiska företag.
Fler artiklar av SIAX