It is 2 a.m. and a pipeline fails. Someone upstream renamed a field in the billing system. Nobody told the data team, because nobody knew the pipeline depended on it.
By morning, three dashboards show the wrong numbers. A regional manager has already forwarded one of them to leadership. The data team spends the day finding the break, fixing it and explaining what happened.
Nothing about this is unusual. It is what running ETL pipelines looks like at scale. The question more teams are now asking is simple: do we still need to build them at all?
What is zero ETL?
Zero ETL is an approach to data integration that removes the need to build, extract, transform, and load pipelines. Instead of copying data into a central store, queries run directly against source systems, so data stays current, stays in place and never has to be moved.
In plain terms, the question travels to the data instead of the data traveling to the question. We covered the basics of this idea in our article on data virtualization. This piece is about the practical decision: when to keep building pipelines, and when to stop.
What does ETL actually cost?
The cost of a pipeline is rarely the cost of building it. It is everything that comes after.
Maintenance never ends. Every source system changes over time. Each change can break a pipeline, and someone has to notice, fix and test it.
Data is always behind. A pipeline that runs every night means every report is up to a day old. For network operations, fraud or customer service, that delay matters.
Every copy needs protecting. Each pipeline creates another copy of the data. Each copy needs its own security, its own access rules and its own audit trail.
The data team becomes a queue. When every new question needs a new pipeline, the team that builds them becomes the bottleneck. Business teams wait weeks for answers that should take minutes.
None of these costs show up in the original project plan. They show up in the second year, and every year after.
When does ETL still make sense?
Zero ETL is not the right answer for every workload. Being honest about that is what makes the decision easier.
ETL still makes sense when you need a fixed historical snapshot, such as month-end figures that must never change. It also makes sense for heavy transformations that run once and are reused many times, or for archives of data from systems that are being retired.
It can also make sense when a legacy system cannot tolerate external query loads. Huckleberry protects underlying systems by pushing down only optimized queries, throttling concurrency, and caching frequent requests at the semantic layer. If an underlying database is too fragile to sustain federated read queries even with those protections in place, routing through a dedicated read replica or a traditional ETL pipeline is the pragmatic call.
For most day-to-day questions, though, the picture is different. Teams want current answers, drawn from several systems, with the right permissions applied. That is where pipelines cost the most and add the least.
Five signals it is time to stop building pipelines
If several of these sound familiar, your team is probably spending more on pipelines than they are worth.
- Your data team spends more time fixing pipelines than answering questions.
- Business teams wait weeks for data that already exists somewhere.
- Reports from different teams show different numbers for the same thing.
- Security asks how many copies of customer data exist, and nobody knows.
- You want AI agents to use company data, but every connection needs a new ETL pipeline.
What does the difference look like day to day?
Take one common request. A customer team wants to see which business accounts have open network tickets and an upcoming renewal.
With ETL, the request goes into the data team's queue. Someone maps the ticketing, network, and CRM systems. They build a pipeline, test it, and schedule it. A few weeks later, the report arrives. It runs nightly, so it is always up to a day behind. And the next report starts the process again.
With zero ETL, the three systems are already connected as governed data products. The question is answered the same day, against current data. The next report is just another query, not another project.
The difference is not only speed. It is that the data team stops being a queue and starts being a partner.
What does zero ETL look like in practice?
In a zero ETL setup, each system stays where it is. A governed layer sits on top and turns source data into data products that people and applications can query.
Rules are applied before anything runs. Each data product carries its own data contract, so the same rules apply to every analyst, dashboard and AI agent. By applying element-level security rules before queries ever run, each request returns only what that user may see. Sometimes that is a partial result, with line-item details redacted at the source and totals for very small groups held back.
Huckleberry was built this way. It connects to more than 100 data sources, formats, and systems without copying them, serving governed data products through SQL and GraphQL for analysts and MCP for AI agents. Teams can go from zero to live in under 10 minutes and reach governed data in under five days, without building a single pipeline.
Frequently asked questions
Is zero ETL the same as ELT?
No. ELT still copies data into a central store and transforms it there. Zero ETL avoids the copy altogether. The data stays in its source system, and queries run against it directly.
Does zero ETL replace our data warehouse?
Not necessarily. A warehouse can be one of the sources a zero ETL layer connects to. Many teams keep their warehouse for historical reporting and use zero ETL for current, cross-system questions.
Is zero ETL secure?
It can be more secure than ETL, because there are fewer copies of the data to protect. The key is that permissions are checked before each query runs, and every request is recorded.
How do we start with zero ETL?
Start with one cross-system question that your team asks often and that currently needs a pipeline. Connect those sources, answer the question in place and compare the effort. One working example is the fastest way to decide what to do next.
Fewer pipelines, faster answers
Pipelines were the only way to bring data together for a long time. That is no longer true.
Keep ETL for the workloads it suits best. For everything else, let the question travel to the data. Your data team will spend less time fixing what broke overnight, and more time answering what the business actually needs.
See it without a single pipeline
If your team is spending more time on pipelines than answers, let's talk about how Huckleberry can unlock your data and put safe, practical AI to work for your business. Bring us a real data problem, and we will show you the answer in a working environment. Connect with us to schedule a conversation.