The difference is where the transform happens, not which tool you use.

The plain definition

ETL (Extract, Transform, Load) and ELT (Extract, Load, Transform) describe the same three operations in a different order. ETL transforms data in a separate processing step before it ever lands in the destination: extract from the source, apply the transformation logic in an intermediate engine, then load the already-shaped result. ELT loads raw or lightly-shaped data into the destination first, then runs transformation logic as SQL (or a tool like dbt) inside the warehouse itself, using the warehouse's own compute to do the reshaping. Neither term describes a specific product; both describe a sequencing choice that any tool, including a hand-written script, can implement.

Why ELT became the more common default

Modern cloud warehouses (Snowflake, BigQuery, Databricks, Redshift) got cheap and fast enough at large-scale SQL that it usually makes more sense to load raw data in and transform it there, rather than maintaining a separate transformation engine outside the warehouse. This also means the raw, untransformed data is preserved in the destination, which is useful if a transformation turns out to be wrong and needs to be rebuilt, since you're re-running SQL against data you still have, not re-extracting from the source. ETL's older transform-before-load pattern still makes sense when the destination isn't a large SQL-capable warehouse at all, when compliance requires certain fields to never leave a transformation boundary before landing anywhere, or when the transform logic genuinely needs a general-purpose language and libraries a SQL-based warehouse transform can't easily express.

How this is different from our own Data Sync vs. ETL framing

This page is about the generic industry terms; it isn't the same question as Data Sync vs. ETL, which compares QueryFlow's own Data Sync feature name against the general concept of ETL as a category. Here, ELT and ETL are both generic terms describing where transformation logic runs, independent of any specific product.

A concrete example of each

-- ELT: load raw rows into BigQuery first, transform with SQL after
-- Step 1 (load): raw orders land in `my-gcp-project.raw.orders` unchanged.
-- Step 2 (transform, run inside BigQuery):
CREATE OR REPLACE TABLE `my-gcp-project.analytics.orders_clean` AS
SELECT
  order_id,
  UPPER(TRIM(status)) AS status,
  CAST(total_cents AS FLOAT64) / 100 AS total_usd
FROM `my-gcp-project.raw.orders`;

-- ETL: clean and cast the data before it ever reaches the warehouse
-- (transform happens in the pipeline tool, not in the destination's SQL)

In the ELT example, a bad transform is fixed by rewriting the SQL and re-running it against data already sitting in BigQuery; nothing needs to be re-extracted from the source. In the ETL example, if the transform logic was wrong, you'd typically need to re-run the extraction and the transform step together, since the destination never held the untransformed version.

Where QueryFlow fits

QueryFlow's Data Sync leans ELT by default: it moves rows from a source into a destination table using Insert, Update, or Upsert, and any real transformation you want to apply is written as SQL against the source query itself (the SELECT you write feeding the sync) or run separately in your warehouse after load, in a Flow Book, or in the SQL Editor. It isn't a dedicated transformation engine with its own DAG of transform steps the way a dbt-centric ELT stack is; it's closer to the L in ELT, with a T you write yourself in plain SQL wherever makes sense for the job.

A third pattern some tools blur: ETLT

Some modern pipeline tools do a small amount of transformation before load (deduplication, basic type coercion) and the bulk of business-logic transformation after load in the warehouse, sometimes labeled ETLT to acknowledge that the split isn't always clean. In practice this isn't a third category so much as a recognition that "transform" covers a range of work, from light cleanup that's easiest to do close to the source, to heavier business logic that benefits from a warehouse's compute and from being expressed in version-controlled SQL that a team can review.

A practical way to decide, case by case

A useful question when deciding where a specific transform should live: would you ever want to see the pre-transform version of this data again, to debug a wrong number or rebuild a changed business rule. If yes, load it raw and transform with SQL after, so the raw version stays available. If the transform is something like stripping personally identifiable information before it's allowed to leave a compliance boundary, that has to happen before load, full stop, regardless of which pattern is otherwise in use.

Why this matters for a hiring conversation, not just an architecture one

The ELT/ETL distinction shows up often enough in job postings and interviews that it's worth being able to state plainly: it describes when the transform runs relative to the load, not a brand, a specific product, or a level of sophistication. A candidate who can only describe one pattern, or who conflates either term with a specific vendor's product name, is often working from marketing language rather than the underlying mechanics.

Sources

• Fivetran: Usage-Based Pricing (MAR definition) (accessed September 26, 2026)