Open the comparison page of any ELT tool and you will find the same five claims: hundreds of connectors, elastic scale, enterprise-grade security, real-time sync, and an interface anyone can learn in an afternoon.
They are mostly true. That is the problem. A criterion every vendor satisfies cannot help you choose between them, and none of them is the reason teams are unhappy with the tool they picked eighteen months later.
The questions that separate the options are less flattering, which is why they are not on the page.
What the checklist says, and what to ask instead
| On the comparison page | The question underneath it |
|---|---|
| ”300+ connectors” | What happens when I need the 301st? |
| ”Powerful transformations” | Where does that logic live — your UI, or my repository? |
| ”Enterprise-grade reliability” | When a sync fails at 3am, can I see why? |
| ”Flexible pricing” | What shape is it, and what does it do at ten times my volume? |
| ”Easy migration onto the platform” | And off it? |
1. What happens when the connector does not exist
Every catalogue is long and none is complete. Within a year you will need a source nobody has built: an internal service, a regional payment provider, a partner’s SFTP drop with an idiosyncratic CSV.
So the real question is what the tool does at that boundary. Can your team write a connector against a documented interface, run it on the same schedule and monitoring as the built-in ones? Or is the answer a support ticket, a quote, and a roadmap slot?
Ask for the SDK documentation during evaluation, not after. If the answer is “we’ll build it for you”, price that in — you will be back for the 302nd.
2. Where the transformation logic lives
This is the one that decides how the next three years feel.
If transformations live in the vendor’s interface, they are not reviewable — no pull request, no diff, no history of who changed the revenue definition and why. They are not testable outside the platform. And they are not portable: they are the part of your work that does not come with you.
If they live in your repository as SQL, every one of those problems disappears, and the vendor is moving data rather than owning your business logic. This is the in-the-model layer — the one place that should encode decisions someone could disagree with, which is exactly why it belongs in version control rather than a dropdown.
A tool that loads well and leaves modelling to you is usually a better long-term position than one that does both adequately.
3. What you can see when it breaks
Everything fails eventually. The difference between tools is what you are left holding at 3am.
Concrete things to check during a trial — by deliberately breaking something:
- Rename a source column. Does the sync fail loudly, silently null the field, or drop the column without comment?
- Kill a sync mid-run. Does it resume, restart, or duplicate rows?
- Look at the logs. Do they tell you which record failed and why, or only that a job did?
A tool that logs “sync failed” and one that logs “row 4,812: created_at was not a timestamp” cost different amounts of your life. Neither comparison page mentions this, and no demo will show it to you unless you ask.
It is also why checks belong on your side of the boundary regardless of what the vendor promises.
4. The shape of the pricing, not the number
Headline rates are comparable. Pricing shapes are not, and the shape is what determines the bill in year three.
Per row aligns cost with data volume, which means it punishes exactly the growth you are hoping for. It also creates a bad incentive: teams start not syncing tables to save money, and a table nobody syncs is a question nobody can answer.
Per connector punishes breadth. It is fine when you have eight sources and painful when a new SaaS tool arrives every quarter.
Flat or capacity-based is predictable but usually means paying for headroom you are not using yet.
None is wrong. But model your volume at 3x and 10x before signing, because the ranking between vendors frequently flips somewhere in between.
5. The exit cost
The honest question, and the one nobody asks during a sales process: if this goes badly, how much of what we built comes with us?
Connectors configured in a UI: nothing. SQL models in your own repository: everything. Schedules and dependency graphs defined in a proprietary format: it depends on whether that format is exportable.
A useful rule: the more of your work that lives in your repository rather than the vendor’s database, the cheaper the exit — and the less the answer to this question matters at all.
What this means for evaluating us too
Everything above applies to Datablast. Ask us where transformation logic lives, what happens when you need a connector we do not have, and what you could take with you. Those answers are the comparison; the feature grid is not.
The takeaway
Connectors, scale and security are table stakes — they filter out the unserious and tell you nothing about the rest. What separates tools is what happens at the edges: the missing connector, the failed sync at 3am, the bill at ten times the volume, and the day you leave.
Evaluate those on a trial by deliberately breaking things, not on a comparison page.
Datablast is built on the position that most of this should not be the vendor’s to own: ingestion and orchestration that we run, transformation logic in your git repository, and quality checks defined alongside it.
Originally published on datablast.io in August 2023 as part of a longer piece on ELT. The ETL/ELT comparison from that post now lives here; this is the selection half, rewritten September 2026.
See it on your own data
20 minutes, your questions, a live walkthrough.