ETL Tool Performance Benchmarks: How to Evaluate in 2026

If you ask a vendor what dataset their benchmark slide is built on, their confidence usually drops fast. Most published numbers come from a lab setup that looks nothing like your stack: a different source system, a different transformation, often hardware you’ll never really run.

If you lead data architecture at a mid-size or large enterprise, it's likely that you’ve sat through this pitch before. You need a method you can run yourself, one that holds up when InfoSec starts asking questions and still works the next time a vendor quietly changes its pricing page.

What is an ETL performance benchmark?

An ETL (Extract, Transform, Load) performance benchmark is a controlled, repeatable test: the same workload, run against each candidate tool, so results line up next to each other instead of past each other.

No single industry standard covers ETL performance. The Transaction Processing Performance Council released TPC-DI to fill that void, the first formal benchmark built for data integration workloads. It models a brokerage firm’s data flow and separates timed work (extraction, transformation, loading) from untimed setup (data generation, teardown).

An ETL performance benchmark is only meaningful if every tool runs against the same dataset, transformations, environment, and success criteria.

Vendor-published numbers are hard to trust because architectures, connectors, and deployment models differ so much between tools. You need to build a method that you can run instead.

Core metrics that matter: throughput, latency, and scalability

Throughput is how much data a pipeline moves per unit of time, usually rows per second or megabytes per second. Latency is the time from extraction to availability at the destination, split into event-time latency (how stale the data is) and processing-time latency (how long the pipeline takes).

The two trade off: research on IoT analytics pipelines found latency from source to destination deteriorates as throughput rises.

A modern enterprise target runs north of 50,000 rows per second, with latency under roughly 10 seconds per batch. Treat these as reference points as your own freshness requirements set the real bar.

Before you benchmark: prerequisites and evaluation criteria

Four things need to be true first: a workload matching your production mix, a dataset sized and skewed like your real data, matched hardware and configuration across every tool, and identical success criteria scored the same way for each.

Test more than one processing mode where supported; batch, incremental, and streaming performance can differ sharply inside one product, which is why TPC-DI runs a historical load plus two incremental loads. Capture a baseline first, and build in correctness checks from day one, hash checks, data model validation, and record-count reconciliation, the way TPC-DI’s audit checks do.

If you want a parallel checklist for the selection side of this problem, our 2026 guide to picking a hybrid ETL tool covers similar ground from a different angle.

Step 1: Define your benchmark scope and success criteria

Write success criteria before any test script: target throughput, maximum p95 latency, a cost ceiling per terabyte. Score every tool pass or fail against those numbers.

Decide which stages count toward the clock; TPC-DI only times ingestion, transformation, and loading. Use the same rule, or your fastest tool might just be the one that cut scope. Tie targets to real freshness needs: near-real-time ingestion means little if the pipeline downstream only runs a few times a day.

Document every scope decision. A report only holds up if it states dataset, transformations, environment, runtime, throughput, cost, and validation method clearly enough to rerun.

Step 2: Build a representative test dataset and cloud ETL environment

Size your dataset to expose bottlenecks, then size it again for growth. TPC-style benchmarks use a Scale Factor, a multiplier that produces proportionally larger datasets so one workload runs at 100 GB, 500 GB, 1 TB, and beyond.

Quick definition: Scale Factor. A multiplier used by benchmark generators to produce proportionally larger datasets for the same workload.

TPC-DI results show the historical load consistently takes about 80% of total elapsed time regardless of data size, with the two incremental loads splitting the rest. Test at more than one scale factor to see whether your candidate scales linearly or degrades.

Hold compute configuration constant across every tool, normalizing performance to price point with enterprise-equivalent tiers, so a budget tier on one platform never gets compared against a premium tier on another. Generate load with mature tooling rather than hand-rolled data, and simulate production noise, compliance deletes, backfills, key rotation, since background activity changes measured throughput.

Step 3: Measure throughput and latency under real-world load

Instrument extraction, transformation, and loading separately so a spike points to a stage. Measure at the driver, per stage, and from source to destination, the three-point approach stream-processing research recommends for isolating where a slowdown starts.

Wire up Prometheus or Grafana (or whatever your cloud already gives you) and watch resource use against execution time while the job runs. That’s where you see a bottleneck form.

Step 4: Test scalability and concurrency for enterprise workloads

Build concurrency into the test: run incremental loads alongside background reads and writes, the way production behaves, and report throughput under that load.

Quick definition: sustainable throughput. The highest data rate a pipeline can process continuously without latency growing unbounded or a backlog forming.

Latency climbs as throughput rises, and checkpoint and recovery settings trade service quality against recovery speed. Record where each tool’s latency curve breaks as concurrency increases; that breakpoint matters more than the peak number on a slide.

Illustrative figures, not vendor-reported results.

Step 5: Compare connector depth across Snowflake, Databricks, and AWS

Connector depth covers driver efficiency, live connectivity, and how much transformation logic a connector pushes down before data crosses the network.

Quick definition: query pushdown. A technique that translates transformation logic into SQL executed at the source or target database, avoiding costly data movement.

Pushdown pushes filters, joins, and aggregations into the data source instead of pulling everything across the network into the ETL engine. Skip it, and the ETL server absorbs the full load, which bottlenecks fast on large datasets. Snowflake’s pushdown shifts real processing weight onto Snowflake itself. AWS Glue’s cuts scanned data, but unevenly; its DynamoDB reader skips pushdown predicates entirely.

CData’s standards-based JDBC and ODBC drivers give live connectivity to Snowflake, Databricks, and hundreds of other sources, with pushdown bounded by what the source and driver can support, a solid reference point for what connector depth should mean here.

Step 6: Evaluate price-performance and total cost of ownership at scale

ETL often eats the biggest chunk of cloud data spend, over half of it by one estimate. That’s reason enough to rank tools on price-performance when you’re the one justifying the budget.

Measure runtime and cost on the same workload, then compute cost-per-gigabyte and normalize each platform to its price point. Newer Snowflake compute generations run faster but cost more, enough to flip a ranking that looked settled on speed alone.

AWS Glue gives a concrete anchor: $0.44 per DPU-hour, billed per second with a one-minute minimum, where one DPU is 4 vCPUs and 16 GB of memory. Six DPUs for 42 minutes runs about $1.85 in compute, a number that scales cleanly to a production estimate. One catch: consumption-based pricing swings with usage, so budget off a load-scaled projection, not the price of one test run.

Row-based and DPU-based pricing carry the same forecasting problem; our look at usage-based ETL pricing uncovers how that plays out across a few common models.

Rate from AWS Glue’s published pricing; cost-per-TB is illustrative.

Interpreting your results: a side-by-side comparison framework

Put every result in one scorecard, dataset, environment, runtime, throughput, cost, scaling behavior, and validation method all in the same row. If you leave one out, nobody can check your work. Weigh the metrics by what your team cares about: cost and speed rarely rank the same tool first. And add a correctness gate, a column that confirms every candidate passed reconciliation.

Illustrative row; populate with your own results.

Rank candidates on price-performance and reliability. Throughput alone picks the wrong tool.

Practical tips and troubleshooting for reliable benchmarks

• Add automated performance gates to CI/CD that fail a build on a meaningful execution-time spike, and track history to catch drift early

• Correlate CPU, memory, disk I/O, and network per run against execution time to find the resource-bound stage, comparing variants rather than absolute numbers

• Rule out hardware first: limited I/O, insufficient RAM, and an under-provisioned CPU cap throughput regardless of the ETL logic

• Average metrics over a window and measure after several incremental loads, not a cold start, so results reflect stable-state performance

Common ETL benchmarking mistakes to avoid

• Comparing tools on unequal footing. Different datasets, transformations, or default write modes, append-only versus upsert, can skew results on their own

• Measuring only total runtime. Without per-stage insight, teams optimize blind

• Ignoring concurrency and background processes. Skipping concurrent reads, writes, and incremental loads overstates real-world throughput

• Skipping correctness validation. A performance win means nothing if output fails hash checks or record reconciliation

• Trusting a single vendor’s benchmark at face value. No universal standard exists; reproduce every result in your own environment first

Build a defensible ETL evaluation with CData Sync

Based on an internal benchmarking report, CData Sync replicated a 360 GB, 1-billion-row SQL Server table into Databricks in 2 hours 41 minutes, down from 11 hours 6 minutes on the prior version, same infrastructure, same workload.

Run this framework against your own shortlist, including a configuration built on CData Sync’s standards-based connectivity to Snowflake, Databricks, and hundreds of other sources. Do not take any vendor’s published numbers, including this one, without rerunning the test yourself.

Start a free 30-day trial of CData Sync.

Frequently asked questions