What Is ELT?

by

Data doesn’t always arrive clean, structured, or ready to use. And anyone who’s worked with data knows that gap between raw information and actionable insight is where a lot of the real work happens. ELT is a modern approach to bridging that gap.

Unlike its older cousin ETL, ELT flips the script by loading data into its destination first and transforming it there, taking advantage of the processing power that today’s cloud data warehouses have in abundance. The result is a faster, more flexible pipeline that’s become something of a default choice for many data teams building on platforms like Snowflake, BigQuery, or Redshift.

What Does ELT Stand For?

ELT stands for stands for Extract, Load, Transform. The three steps are the same as ETL, just with the last two swapped. Here’s what’s involved at each step:

  • Extract is pulling data from your source systems. This could be your CRM, payment processor, product database, marketing tools, whatever. This step is the same as in ETL.
  • Load comes next. Instead of cleaning the data first (like you would do in ETL), you move it raw into your destination (almost always a cloud data warehouse like Snowflake, BigQuery, or Redshift). The data lands exactly as it came from the source.
  • Transform happens last, inside the warehouse. Once the raw data is sitting there, you write SQL-based transformations to clean it, join it, reshape it, and model it into tables that analysts can actually use.

How ELT Differs from ETL

In traditional ETL, data gets transformed before it reaches the warehouse. That means you need a separate processing layer in the form of a server or pipeline that cleans and restructures data mid-flight.

ELT flips that. You load first, transform later. The warehouse itself does the heavy lifting.

This shift became practical because modern cloud warehouses are fast and cheap enough to handle large-scale transformations directly. You don’t need a separate compute layer anymore. Instead, you just run SQL.

Why ELT Has Become the Default

A few things has driven the switch from ETL to ELT:

  • Cloud warehouses changed the economics. Platforms like BigQuery, Snowflake, and Redshift are built to run complex queries across massive datasets quickly. Running transformations inside the warehouse is often faster and cheaper than running them in a separate system.
  • You keep the raw data. Because you load before transforming, the original source data always lives in your warehouse. If a transformation has a bug, or business logic changes, you can re-transform from the raw layer without going back to re-extract from the source. This can be a big deal operationally.
  • The tooling got really good. dbt (data build tool) turned SQL-based transformation into a proper software engineering practice (with version control, testing, documentation, and modular models). ELT and dbt became nearly synonymous for a lot of teams.
  • Managed connectors made extraction easy. Tools like Fivetran and Airbyte handle the extract and load steps with pre-built connectors to hundreds of sources. You configure the connection and they keep the data syncing. That leaves your team free to focus on the transform layer, where the actual business logic lives.

What the ELT Stack Usually Looks Like

Most modern data teams running ELT use a combination of:

  • A connector tool to extract and load raw data from source systems into the warehouse on a schedule. Examples include Fivetran, Airbyte, Stitch.
  • A cloud data warehouse as the destination and transformation engine. Examples include Snowflake, BigQuery, Redshift, Databricks.
  • dbt to define and run SQL transformations, turning raw tables into clean, business-ready models.
  • A BI tool sitting on top of the warehouse to visualize the final output. Examples include Looker, Tableau, Metabase, Mode.

This stack (often called the “modern data stack”) is what most mid-size and enterprise data teams are running today.

A Simple Example Scenario

Suppose you run a subscription SaaS business. Your data is spread across Stripe (billing), Intercom (support), and your own product database (usage events). You want to analyze churn by customer segment. Here’s how you might use ETL to do this:

  1. Extract + Load: Fivetran pulls raw data from Stripe, Intercom, and your product DB and loads it into Snowflake as-is. You now have raw tables like stripe.charges, intercom.conversations, and app.events sitting in the warehouse.
  2. Transform: Using dbt, you write SQL models that join those raw tables together, standardize customer IDs, calculate metrics like MRR and days since last login, and build a clean customers model with one row per customer and all the relevant attributes attached.
  3. Analyze: Your BI tool queries the customers model to build the churn dashboard.

The raw data is always there if you need to debug or rebuild. The transformation logic lives in version-controlled SQL. And the whole pipeline runs on a schedule without anyone touching it manually.

When ETL Still Makes Sense

ELT isn’t necessarily the right call in every situation. ETL (transforming before loading) might still make sense when:

  • You’re working with sensitive data that needs to be masked or filtered before it ever hits a shared warehouse
  • Your destination system can’t handle raw, unstructured data
  • Storage costs make loading everything raw impractical
  • You’re working with legacy infrastructure that predates modern cloud warehouses

For most teams building a data stack today, though, ELT is usually the starting point.

Conclusion

ELT moves data extraction and loading upstream, and pushes transformation into the warehouse where modern compute can handle it. The practical benefits (keeping raw data, simpler pipelines, better tooling) have made it the standard pattern for data teams working with cloud infrastructure.

If you’re evaluating data stack options, understanding ELT will help you see why the modern data stack is built the way it is, and what tradeoffs you’re making compared to traditional ETL approaches.