The ETL vs ELT framing gets recycled every year and the arguments are almost always the same: ELT is modern, ETL is legacy, cloud warehouses are powerful enough to do the transform in place, therefore ELT wins. This narrative is approximately 80% true and 20% misleading in ways that actually matter for your architecture decisions.
Let's be precise about what these terms mean in 2025 and then talk about what actually drives the choice for modern analytics teams.
The Mechanical Difference
ETL — Extract, Transform, Load — was the dominant pattern when compute was expensive and storage was cheap relative to processing. You extracted data from source systems, applied transforms in a dedicated compute environment (Informatica, DataStage, SSIS), and loaded the cleaned, structured result into the target database. The transform happened before the warehouse touched the data.
ELT — Extract, Load, Transform — inverts the T and L. You extract from source systems, load raw data directly into the target warehouse, and transform it using the warehouse's own compute engine. The warehouse becomes the transform layer. This became practical when Snowflake, BigQuery, and Redshift made columnar compute cheap enough that running complex SQL transforms at scale wasn't cost-prohibitive.
In the modern data stack circa 2025, the ingestion tools (Fivetran, Airbyte) handle the EL. The transformation tool (dbt, SQLMesh) handles the T. The warehouse (Snowflake, BigQuery, Redshift, Databricks) provides the compute. This is the standard ELT pattern.
When ETL Still Makes Sense
The conventional wisdom that ETL is dead is overstated. There are categories of work where transforming before loading is the right call:
PII scrubbing and tokenization. If your source systems contain PII that should never land in your analytics warehouse in cleartext, you need to transform (scrub or tokenize) before loading. Doing this after load means PII touched the warehouse, even briefly. For GDPR or HIPAA compliance, this matters. ETL-style transform pipelines that handle tokenization before warehouse insertion are the right pattern here.
High-cardinality streaming sources. If you're ingesting high-volume event streams from Kafka or Kinesis — say, clickstream data at 10,000 events per second — loading every raw event into a cloud warehouse is expensive. A lightweight stream processing layer (Apache Flink, or simpler: AWS Lambda with DynamoDB aggregation) that pre-aggregates before loading reduces warehouse storage and query costs significantly.
Legacy system extraction with proprietary formats. Some source systems emit data in formats that cloud warehouses don't natively handle (mainframe EBCDIC, custom binary formats, EDI transactions). You need an extraction and format-conversion step before any loading can happen. That's ETL in the classical sense, and there's no ELT equivalent.
We're not saying ELT is the wrong choice for standard analytics pipelines — it clearly isn't. We're saying the category of "things that should be transformed before they reach the warehouse" is larger than it's commonly acknowledged in modern data stack discussions.
The Role of Fivetran and Airbyte in ELT
Fivetran and Airbyte sit at the EL part of ELT. They handle source connectors, CDC (change data capture) for databases, API polling for SaaS sources, and incremental sync logic. Their value proposition is the connector catalog — someone has already written and maintained the Salesforce, Stripe, Hubspot, and Postgres connectors so you don't have to.
The key distinction is where schema normalization happens. Fivetran normalizes automatically — it takes the source schema and creates a target schema that matches, creating tables and columns as they exist in the source. Airbyte gives you more control but requires more configuration. Neither does semantic transform — they land raw data.
A team managing around 15 source connectors at an early-stage analytics company in 2024 would typically find Fivetran easier to operate (less configuration, better observability) but more expensive at scale compared to a self-hosted Airbyte deployment. The crossover point in cost-per-connector depends heavily on your source count and data volume, but for teams under 10 sources, Fivetran's operational simplicity usually justifies the cost premium.
dbt as the Transform Layer
dbt has become the de facto transform layer in ELT pipelines. Its model — SQL files organized as a DAG, materialized as views or tables, tested with schema assertions, documented in YAML — is well-designed and well-understood. The developer workflow (develop locally, test with dbt test, deploy via CI) maps naturally onto software engineering practices that data teams increasingly use.
Where dbt's model gets strained:
Python transforms. dbt supports Python models (via dbt-spark or Snowpark) but it's a second-class experience compared to SQL. If your transform requires complex NLP preprocessing, ML feature generation, or pandas-style operations that don't express cleanly in SQL, you're fighting the tool. Many teams keep Python transforms in a separate Airflow task that feeds dbt, which adds orchestration complexity.
Real-time requirements. dbt is a batch transform tool. If you need metrics computed with sub-minute latency, dbt runs on a schedule and isn't the right choice. Streaming transformation (Flink, ksqlDB, Materialize) is the correct architecture for real-time requirements, and dbt doesn't compete there.
Reverse ETL: The Third Pattern
Reverse ETL deserves explicit mention because it's neither ETL nor ELT — it's the return path. Tools like Hightouch and Census take data from the warehouse and sync it back to operational systems: CRMs, marketing automation platforms, product databases.
The use case: your data warehouse has a computed segment of high-propensity-to-churn users, calculated from 90 days of behavioral data. You want that segment available in your CRM for the sales team to act on. Reverse ETL syncs it there on a schedule.
Why this matters for the ETL vs ELT framing: reverse ETL means your warehouse is no longer a one-way sink. It's a bidirectional node. Data flows in from operational systems (ELT), gets transformed (dbt), and flows back out (reverse ETL) to operational systems. The warehouse becomes the hub of a data mesh topology, not just a reporting database.
What Actually Drives Your Architecture Choice
In practice, the ETL vs ELT choice is determined less by ideology and more by three constraints:
Data sensitivity requirements. Must PII never touch the warehouse? ETL with pre-load scrubbing. PII is fine in the warehouse with column masking? ELT with policy-based masking in Snowflake or BigQuery.
Source system characteristics. Standard SaaS APIs and relational databases? ELT with Fivetran/Airbyte is the path of least resistance. Proprietary formats, streaming sources, mainframe extracts? ETL-style preprocessing is unavoidable.
Transform complexity and latency requirements. Pure SQL batch transforms feeding dashboards? dbt ELT. Complex Python transforms or real-time requirements? You'll end up with a hybrid architecture regardless of your ideological preference.
The modern data stack's dominant pattern — Fivetran/Airbyte + Snowflake/BigQuery + dbt — is ELT and it works well for the 80% case. The 20% where ETL patterns are still the right call is real and shouldn't be papered over by "just use the cloud warehouse for everything."
The right question isn't "ETL or ELT?" It's "at what points in my pipeline does data need to be transformed, and what's the right compute layer for each transformation?" That question leads to better architecture decisions than the acronym debate.