53% of Data Engineering Capacity Goes to Pipeline Maintenance

Data engineering pipeline maintenance eats 53% of engineering capacity at large enterprises, according to Fivetran's 2026 Enterprise Data Infrastructure Benchmark, a survey of 500 senior data and technology leaders at organizations with 5,000+ employees, published March 26, 2026.^[1] Those same leaders estimate pipeline downtime costs their business $49,600 per hour.^[1]

A few weeks later, dbt Labs' 2026 State of Analytics Engineering report, built on 363 practitioners and managers, found that 72% of teams prioritize AI-assisted coding while only 24% prioritize AI-assisted pipeline management such as testing and observability.^[3] In that same survey, 71% worry about incorrect or hallucinated outputs reaching stakeholders, and 41% cite ambiguous data ownership as an ongoing challenge.^[3]

My read: teams are buying speed for the part of the job that was already fast (writing code) and underinvesting in the part that eats half their week (keeping it running). The skills in shortest supply are testing, observability, and ownership. Below is what each report measured, where the numbers are soft, and what to do with them.

What Fivetran Found About Data Engineering Pipeline Maintenance

Fivetran surveyed 500 senior leaders in Q4 2025 across the US, UK, EMEA, and APAC, reporting 95% confidence and a ±4.4% margin of error.^[2] The headline figures:

• 53% of engineering capacity goes to maintaining and troubleshooting pipelines, which Fivetran values at $2.2 million a year in full-time engineer effort per organization.^[1]
• The average organization runs 328 pipelines, sees 4.7 failures per month, and takes roughly 13 hours to resolve each one, for about 60.4 hours of monthly downtime.^[2]
• Larger enterprises report 8.3 breaks per month, and their downtime estimate rises to $75,200 per hour.^[2]
• 97% report that pipeline issues have disrupted AI or analytics initiatives, and 73% say their data initiatives fall short of expectations despite an average $29.3 million in annual data spend.^[2]
• Fivetran reports that legacy and DIY pipelines fail 30% to 47% more often than automated solutions.^[2]

The "$3 million per month" figure in the press release headline is arithmetic on those inputs.^[1] Multiply $49,600 by roughly 60 hours of downtime and you land near $3 million monthly, or about $36 million a year. Keep that in mind; we'll come back to how solid each input is.

The 53% Matches What I've Lived

Half your capacity on maintenance sounds high until you've done the job. My worst week ever was spent tracing a job that had silently dropped 40% of records for 6 months before anyone noticed. Nobody wrote a ticket for "build a feature." The ticket was "why is revenue down in this dashboard," and the answer was a join on a column an upstream team had quietly started nulling out.

That's the actual job. Less "write a DAG," more "figure out why this pipeline dropped 2M rows last Tuesday and make sure it never happens again." The Fivetran number puts a price tag on something every working DE already knew.

What the State of Analytics Engineering 2026 Report Found

dbt Labs fielded its survey from December 5, 2025 to February 1, 2026; respondents were 73% practitioners and 27% managers or executives.^[3] Where Fivetran asked executives about cost, dbt asked the people closer to the code about priorities and worries.

dbt Labs says the jump in trust from 66% to 83% is the steepest single-year increase of any objective it measures.^[3] The company's own framing of the results is that "AI is scaling analytics output faster than the trust and governance mechanisms designed to support it."^[4]

The ownership breakdown is the part I'd tape to the wall. Per the report, 42.5% of data models are owned by whoever built the pipeline, 19.2% have a dedicated modeler or architect, and 7.8% have no formal owner at all.^[3] "Whoever built it" is the ownership model where the owner left 18 months ago and the Slack channel is a ghost town.

Read Together: AI Coding Is Outrunning Data Pipeline Observability and Testing

Here's where I move from reporting to interpretation.

Put the 2 surveys side by side and the shape is clear enough. Leaders say maintenance consumes half their engineering time. Practitioners say they're spending their AI enthusiasm on generating code, with a 48-point gap between coding (72%) and testing or observability (24%). Both groups say trust matters more than ever.

If AI lets you write 3x the models and your testing coverage stays flat, you now have 3x the surface area for the stuff that already eats 53% of your week. Writing code was never the bottleneck. I've written plenty of SQL at 2am; the slow part was always figuring out which of 300 tables was lying to me.

Key takeaway: Both reports point at the same scarcity. Code generation is getting cheap; knowing whether the output is correct, who owns it, and how fast you'll find out when it breaks is getting expensive. Build your skills where the scarcity is.

The budget numbers reinforce it. 57% report higher warehouse and compute spend while only 36% report bigger team budgets.^[3] More infrastructure, roughly the same people. That's a team that needs every pipeline to fail loudly and early, because nobody has spare hours for a 13-hour incident.

What These Surveys Can't Tell You

I'd be doing you a disservice if I passed these numbers along without the caveats. Both are vendor surveys, and both vendors now share an owner: Fivetran and dbt Labs completed their merger on June 1, 2026.^[5] Both surveys were fielded before that close, but the incentives are obvious. Fivetran sells managed pipelines, so a report quantifying DIY pipeline pain is on-message. dbt sells transformation and testing tooling, so a report showing testing lagging AI adoption is also on-message.

That doesn't make the findings wrong. It means you should read them like this:

• The 53% is a self-reported estimate. Leaders estimated how much capacity goes to maintenance; it isn't time-tracking or payroll data.^[1]
• The $49,600 per hour is a perception. It averages what leaders think downtime costs; nobody measured incident losses. The $3 million monthly figure inherits that softness.
• The sample is big companies only. Every Fivetran respondent works at a 5,000+ employee organization, and 70% are at companies with 5,000 to 9,999 employees.^[2] If you're at a 200-person startup, the dollar figures don't transfer.
• Sourcing isn't disclosed. Fivetran doesn't publicly say how respondents were recruited or how familiar they were with its products.
• The dbt percentages overlap. The report notes that multi-select totals may exceed 100%.^[3] The same person can sit in both the 72% and the 24%; treat the gap as relative emphasis, not 2 separate camps.
• dbt's sample skews toward its community. 363 respondents who answer a dbt Labs survey are likely more engaged with modern tooling than the median data team.

The directional finding survives all of that: maintenance is heavy, testing is underinvested, ownership is fuzzy. I'd bet on the direction. I wouldn't put the $36 million figure in a slide deck without a footnote.

Data Engineer Skills 2026: Where to Put Your Reps

I've been through 3 waves of "data engineering is getting automated away." Still here. Still debugging the same categories of problems: schema drift, late-arriving data, upstream teams breaking contracts without telling anyone. AI-generated code doesn't retire those problems; it produces more code for them to happen in. Here's where I'd spend time.

Testing That Runs on Every Build

The cheapest test is the one that runs automatically before bad data lands anywhere a stakeholder can see it. In dbt, that's a few lines of YAML. Note the meta.owner field; I'll get to why.

Uniqueness on the grain, not-null on keys, referential integrity on joins. That covers a shocking share of the incidents I've debugged. If you're prepping for interviews and your dbt knowledge stops at ref(), work through some dbt interview questions that cover tests and sources.

Observability That Catches Silent Failures

Tests catch broken rules. They don't catch a pipeline that succeeds with 40% fewer rows than yesterday. That failure mode is the one that runs for 6 months. A volume check against a trailing average is a few lines of SQL:

Schedule it, alert on any returned row, done. You don't need a platform to start; you need the habit. (The window frame there is a classic interview question too; if ROWS BETWEEN feels shaky, drill some window function practice.) Pair checks like this with idempotent pipeline design so a rerun after an incident fixes data instead of duplicating it. Half of that 13-hour resolution time is often people afraid to hit "retry."

Ownership as an Engineering Artifact

41% citing ambiguous ownership tells me most teams treat ownership as tribal knowledge.^[3] Put it in code. A meta.owner on every model, an alert route that reads it, and a rule that nothing merges without one. It's boring. It's also the difference between a 20-minute incident and a 2-day scavenger hunt through Git blame.

How to Use This in Data Engineering Interviews

The interview is a different skill than the job, and most loops still over-index on puzzle problems. But the behavioral and pipeline architecture rounds are where reliability stories land, and these reports give you a reason to lean into them.

When You're the Candidate

• Lead with an incident, not a launch. "I built a pipeline" is table stakes. "I found a join that was silently dropping records, quantified the impact, fixed it, and added a volume check so it couldn't recur" is a story. Interviewers remember detection and prevention.
• Talk about AI output like a reviewer. If you use AI to write SQL, say how you validate it: tests, row-count reconciliation, diffing against the old model. That answers the exact worry 71% of the dbt sample expressed.
• Put numbers on it. Mean time to detect, mean time to resolve, failures per month before and after. You don't need $49,600 an hour; "we went from finding issues via stakeholder Slack messages to finding them in alerts" is plenty.

Practice saying these out loud before the real thing. Narrating a debugging story under pressure is its own skill, and the mock interview simulator on DataDriven is the best reps I've found for that. For the full loop, the data engineering interview prep guide covers what each round tests.

When You're Evaluating the Team

Remember that 53% is an average. Your actual number depends on the team you join. Ask:

• How many pipeline incidents last quarter, and how did you find out about them?
• Who owns a model after the person who built it leaves?
• What runs before a model reaches production: tests, freshness checks, anything?
• Did the team's headcount grow when warehouse spend did?

If the answers are "a lot," "um," "not much," and "no," you're signing up to be the 53%. That can still be a good job (some of my best career growth came from cleaning up messes), but go in knowing it and price your offer accordingly.

What to Watch Next

3 things I'm watching, based on the evidence here:

• Whether the 24% moves. If next year's dbt survey shows testing and observability priority closing on AI coding, the market is correcting. If the gap widens, expect more incident-driven hiring for reliability work.
• How the merged company frames future benchmarks. With Fivetran and dbt Labs under one roof, look for independent surveys that confirm or contradict these numbers before treating them as industry baselines.
• Whether ownership stays stuck at 41%. AI can write a test. It can't decide who gets paged. That part is judgment, and judgment is the thing that compounds over a career.

The tools will change again in 18 months. The pipeline that silently drops rows will still be there, waiting for whoever knows how to catch it.

References

1. Fivetran, "Data Pipeline Failures Cost Enterprises $3 Million per Month, Fivetran Benchmark Finds," March 26, 2026. fivetran.com
2. Fivetran, "The Enterprise Data Infrastructure Benchmark Report 2026," March 26, 2026. fivetran.com
3. dbt Labs, "2026 State of Analytics Engineering Report," April 14, 2026. getdbt.com
4. dbt Labs, "New dbt Labs Report Finds AI-driven Acceleration is Outpacing Trust and Governance," April 14, 2026. getdbt.com
5. Fivetran, "Fivetran + dbt Labs Complete Merger to Create the Data Infrastructure for Trusted AI Agents," June 1, 2026. fivetran.com