How to Choose an ETL Tool: A 12-Point Checklist for Regulated Teams

Most ETL evaluations compare connector counts and pricing pages. Both matter, but neither predicts whether the tool will still be the right choice after the first incident, the first audit, or the first time a second team wants to use it.

This checklist is the one we would use ourselves. Each point has the question to ask and what a good answer looks like. It applies whether you are looking at hosted services, open-source projects or our own Revoluzen Flow.

1. Where does the data flow?

Ask: Does any data pass through the vendor's infrastructure, and if so, which data and where?

Good answer: Either "none, it runs entirely in your network" or a precise list of what is held, in which region, for how long. Vague answers about encryption in transit are not an answer to this question.

2. Who owns the copies?

Ask: When the pipeline runs, how many copies of the data exist afterwards, and who controls each one?

Good answer: One copy in your destination. Hosted connectors often keep staging copies and logs that contain row samples; find out before a privacy review finds out for you.

3. What is the pricing basis, and what happens when the business grows?

Ask: Does the bill rise with rows, credits, connectors or seats? What did last quarter's growth do to the invoice?

Good answer: A basis you can predict from things you already know, such as the number of production environments. Per-row and per-credit pricing turn success into a cost and push teams to collect less data. See how we price.

4. Can a failed run resume from the failed step?

Ask: A run fails on step four of six. What happens on rerun?

Good answer: It resumes at step four, and steps one to three are not repeated. If the answer is "it reruns from the start", every failure doubles the load on your sources and your warehouse.

5. Are loads idempotent?

Ask: If the same run executes twice, do rows duplicate?

Good answer: No, by design, not by discipline. The tool should merge on keys or replace partitions so a retry is always safe.

6. How are backfills done?

Ask: Reprocess the last ninety days. Show me.

Good answer: The same pipeline, with a date range, producing the same tables a scheduled run would. A separate one-off script is a sign that history will diverge from the daily path.

7. What happens when a source schema changes?

Ask: A column is renamed upstream. What does the next run do?

Good answer: It fails loudly, or quarantines the rows, and tells you which step and which column. Silently loading nulls for a week is the common failure, and it is the expensive one.

8. Which connectors are production-ready, and how do you know?

Ask: For the five systems we depend on, what is the maturity of each connector, and how is that measured?

Good answer: A published status per connector with the testing behind it. A single catalog number tells you nothing about the connector you need. Revoluzen publishes maturity per connector and, as of this writing, marks none as production-ready, which is the kind of answer you want to hear before you build on one.

9. Can the people who understand the data build the pipelines?

Ask: Can an analyst change a schedule or add a filter without a code review, and can an engineer drop into code when the visual tool is not enough?

Good answer: Both, in the same tool, on the same pipeline. Tools that are code-only put every change through engineering; tools that are visual-only hit a wall on the first complex transformation.

10. What evidence does a run leave?

Ask: Eight months from now, an auditor asks which inputs produced a figure. What do you hand them?

Good answer: A record of inputs, outputs, code version and result for the run, ideally signed so it can be verified without trusting the system that produced it. Logs that rotate after ninety days are not evidence. See Revoluzen Evidence.

11. How is a change promoted to production?

Ask: An engineer edits a pipeline. How does it reach production, and who approved it?

Good answer: Separate environments, a reviewable diff, an approval, and a rollback. Editing production directly is fine for a pilot and a liability after it.

12. What happens if the vendor disappears?

Ask: If you are not here in three years, what do we have?

Good answer: An open-source core you can keep running, data in open formats in your own storage, and for commercial parts, source escrow in the contract. For a young vendor this is a fair question; a good one will have an answer ready.

Using the checklist

Score each tool on all twelve before looking at price. Points 1, 2 and 10 are usually disqualifiers for regulated teams; points 4 to 7 decide the operational cost; points 9 and 11 decide whether the tool scales to a second team. Then run the top two candidates against one real source for a week. A week of production-like use beats any demo, including ours. The open-source build of Revoluzen Flow installs in one command for exactly that purpose; see get started free.

Frequently asked questions

Should I choose an open-source or a commercial ETL tool?

Judge the boundary, not the label. A good open-source tool publishes exactly what is free and what is paid, and the free part runs real production work without artificial limits. A commercial tool should state where your data goes and what the bill depends on.

How many connectors does an ETL tool need?

Enough to cover the systems you actually run, at a maturity you can verify. Five production-ready connectors you need beat five hundred you do not.

What is the biggest mistake in ETL tool selection?

Choosing on the happy path. Evaluate the second run, the failed run and the backfill, because that is where the cost of ownership lives.

How long should an ETL evaluation take?

Two weeks: one to score candidates on this checklist, one to run the top two against a real source. Longer evaluations rarely change the answer.