"ETL" covers a lot of ground. Data Sync, as QueryFlow uses it, is one specific and much narrower piece of that ground.
No credit card. 14 days. Cancel in one click.
Quick answer: ETL is the broad category: extract, transform, and load, however complex. Data Sync is a narrower pattern inside it: map columns between a source and a target connection, then write them with Insert, Update, or Upsert, on a schedule if you want. It doesn't cover multi-step orchestration or arbitrary code transforms.
ETL, extract, transform, load, describes an entire category of moving and reshaping data: pulling from a source, applying business logic or cleanup along the way, and landing the result somewhere else. It's a broad enough term to cover everything from a five-line script to an orchestrated pipeline with dozens of interdependent steps. Data Sync, as QueryFlow uses the word, is one specific pattern inside that category: take rows from a source connection, map their columns to a target connection, and write them with a chosen mode, Insert, Update, or Upsert. It's ETL's extract-and-load with a light, structured transform in the middle, not the whole discipline.
A Data Sync in QueryFlow is built in Pipelines → Build: pick a source connection and a target connection from the 9 supported, Snowflake, Redshift, PostgreSQL, MySQL, BigQuery, Databricks, Salesforce, Google Sheets, or CSV/Excel, map columns between them with drag-and-drop or AI Map, and choose a MODE. Insert appends rows. Update or Upsert require a MATCH ON key so existing rows get refreshed instead of duplicated. Run it once, or save it as a scheduled job. That's the whole shape of it, deliberately narrow.
Tools built around the full ETL label usually add things Data Sync doesn't try to do: multi-step dependency graphs where one job's output feeds the next, arbitrary code-based transforms beyond column mapping, and orchestration across many sources and targets in a single run. If your pipeline needs branching logic, conditional steps, or a DAG where twenty tasks run in a specific order with retries at each stage, that's a heavier tool's job. Data Sync is built for the much more common case: this source, that target, these columns, this mode, on this schedule.
Say a nightly process needs to pull orders from Postgres, aggregate them by region, and write the aggregate into a Snowflake table finance reads from. The pull and the write are Data Sync's job. The aggregation step in between, if it needs custom logic beyond a straightforward mapped column, is where you'd reach for a Flow Book to do the transform, then a Data Sync to land the result, or a query with the aggregation built in as the source itself, feeding straight into the sync.
Calling every data-movement task ETL makes it easy to reach for more infrastructure than a given problem needs. Most day-to-day data movement, get this table from A into B, keep it current, is a sync problem, not an orchestration problem. Recognizing which one you actually have before reaching for a tool saves you from either building a fragile custom script for something a mapped sync would cover, or standing up a full orchestrator for a job that's really just two connections and a schedule.
See a Data Sync built end to end in the Data Sync tutorial, the difference between the write modes at Upsert vs. Insert vs. Update, or what decides when a sync runs at What a job scheduler does.
14-day free trial, no card. Build your first Data Sync in a few minutes.
No credit card. 14 days. Cancel in one click.