Data engineer vs data analyst: what each does, which one to become, and which your team should hire first

Part of our topic guides on Data Engineering and Data Analyst Careers.

A data engineer builds and runs the systems that make data usable; a data analyst uses those systems to answer business questions. Both write SQL and both think in tables, but the work splits at one line: everything upstream of a trustworthy dataset is engineering, and everything downstream of it, turning that data into a decision, is analysis.

If you are choosing which to become, pick by which of those two you would rather do all day, not by the salary line, because the numbers you will find are not comparing like with like. If you are an employer deciding who to hire first, let the gap decide: when the data itself is late, wrong, or missing you need an engineer, because an analyst placed on top of broken data will only produce confident wrong answers faster; when the data is reliable but nobody is acting on it, an analyst is what is missing.

Sideways moves between analysis roles (an analyst who becomes a senior analyst, say) are common and cheap once you are in the work. The crossing from analysis into engineering is the exception: a genuine change of job, with a real bridge you can train for.

What each one does all day

Read the work, not the title. Job titles in data are unreliable labels, and one company's "analyst" is another's "scientist", so the honest way to tell the two roles apart is by what fills the week.

A data engineer spends most of the week building and maintaining the pipelines that move raw data from operational systems (the CRM, the billing system, the product database, outside feeds) into a warehouse in a clean, consistent shape. They own data quality, schema design, and access control, and they are the person paged when a pipeline breaks overnight. Their success is quiet: the data is right, fresh, and trusted, and nobody notices because nothing went wrong.

A data analyst spends most of the week turning that curated data into answers. They sit close to the business, work out what a stakeholder is actually trying to decide, build and refine dashboards, write up analysis, and present what they found. Their success shows up differently: a team made a better call because of the work, and the number on its own was never the point.

Both roles run on SQL, the language for reaching and shaping data where it lives, which is why it is the first thing to learn for either. From there the toolkits diverge by purpose. An engineer works in the plumbing: pipelines, the orchestration that schedules them, the transformation-and-modelling layer that turns raw tables into clean ones, and the cloud warehouse underneath, with Python for the parts that need real code. An analyst works closer to the surface: spreadsheets for quick, direct exploration, SQL to pull and shape the data, and business-intelligence dashboards for the views a team looks at again and again.

	Data engineer	Data analyst
What they own	The systems that move and shape data: pipelines, models, trustworthy tables	The answers: dashboards, written analysis, recommendations
Where they sit	Upstream, closest to the raw data and the infrastructure	Downstream, closest to the business decision
A good day	A pipeline that just works; data that is right and on time	A stakeholder who changed a decision because of the analysis
Core tools	SQL and Python; orchestration (Airflow among others), a modelling layer such as dbt, cloud warehouses such as BigQuery, Snowflake or Redshift	SQL, spreadsheets, business-intelligence dashboards such as Power BI or Tableau
Usual way in	A software or analytics background, or iO-Sphere's Data Engineering apprenticeship (Level 5)	A numerate role or degree, a free Skills Bootcamp, or iO-Sphere's Advanced Data & AI apprenticeship (Level 4)
Reports into	Head of Data or Engineering	Head of Data, or a business function such as Finance, Marketing or Operations

There is a role between the two. An analytics engineer owns the transformation-and-modelling layer, turning the engineer's raw warehouse tables into clean, well-named datasets an analyst can trust, and in the UK it is still found mostly in scale-ups; smaller teams fold that work into whichever side has the heavier need. If that middle ground is what interests you, our comparison of analytics engineer vs data analyst goes into it.

Which pays more?

In the UK, the median advertised salary for a data engineer is £70,000, while the median measured salary for a data analyst is £38,107. Those are two different kinds of number, and the real gap between the roles is smaller than that contrast looks.

The analyst figure is measured pay: £38,107 is what people in the job actually earn (ONS Annual Survey of Hours and Earnings, 2025 provisional, all employees). The engineer figure is advertised pay: £70,000 is the median in UK job adverts (ITJobsWatch, UK permanent vacancies, the six months to 16 August 2026, 1,448 salaries quoted, with the middle half of adverts between £52,500 and £85,000). There is no measured benchmark for data engineers we would stand behind, which is why the closest figure available for them is an advertised one.

That difference in kind is the whole point, because measured and advertised numbers do not line up. Advertised figures run high: they are what employers offer, in the IT sector, skewed toward the senior vacancies that pull the median up. You can see the size of that effect in our own analyst data, where the advertised median runs roughly £7,000 above the measured one for the very same job. So do not read £70,000 against £38,107 as data engineers earning nearly double: a good part of that gap is the advertised-versus-measured gap, plus the fact that the engineering figure reflects only the senior end adverts lean on.

Does engineering pay more? The direction is real, since even advert against advert the engineer figure sits well above the analyst one. But the measured evidence, the kind we would most stand behind, exists only on the analyst side, and the salary difference is the wrong thing to decide on regardless. People who pick a data role off a pay table tend to land in work they dislike, because building systems and answering questions are genuinely different days. Choose the work; the pay follows the work you turn out to be good at.

If you are choosing which to become

If you are choosing a direction rather than filling a seat, start from the work you would actually want to own, then check it against the honest route in.

Choose engineering if you like building things that keep working after you have walked away, you can live with being on call when they do not, and you take real satisfaction from reliability nobody sees. The reward for a pipeline that never breaks is that nobody ever mentions it, and that has to be enough.

Choose analysis if you want your work in front of decision-makers regularly, you enjoy the interviewing and the explaining as much as the querying, and open-ended questions energise you rather than frustrate you.

If you are starting cold, analysis is the wider door, and it is also the usual way into engineering: the people who build data systems well have generally used them first.

One honest redirection: if what pulls you is building predictive models rather than pipelines or dashboards, that is data science, a third job that leans harder on statistics. We do not run a data science programme, and a university or specialist route serves it better than either path here; what our Level 4 and Level 5 programmes build is the analytical and engineering ground that most data scientists turn out to have covered first.

Crossing between them: what the bridge actually is

Engineering is not analysis with the difficulty turned up. It is a different job, and it has become a weightier one, because who consumes the output has changed. A dashboard used to tolerate a late or odd number, because a human read it and thought that looks wrong. AI systems read data without pausing to doubt it, so freshness, quality and availability have moved from housekeeping to live production concerns, and the person who keeps them right matters more than they did a few years ago.

As for which is harder to learn: analysis has the lower bar to start, because SQL and a spreadsheet are enough to do real work early, while engineering wants production code and infrastructure knowledge before you are much use. That makes engineering the steeper climb at the beginning, but a harder start does not make it the more senior or the more valuable role. The two are different jobs, and where you begin says nothing about which matters more.

An analyst can absolutely become a data engineer, and the crossing is both a real change of job and the most common way people arrive at it. You start with an advantage: you already understand the stakeholder, the downstream use, and what it costs when data lands late or wrong, because you have been the person it let down.

What you add is two skills, and both are trainable. The first is production-code discipline: version control, testing, and CI/CD applied to data, so your work becomes something a team can run rather than something that ran once. The second is infrastructure literacy: orchestration, cloud warehouses, and how a schema changes safely over time. Your existing SQL and any working Python are real footholds into that world.

That is also why the Level 5 route is not an off-the-street beginner course. It is its own standard rather than a promotion earned from the Level 4, but it is laid over a job that already involves real data work, so the "direct" way in and the through-analysis way in are the same door seen from two sides: you enter it already doing the work, and analysis is where most people build the footing it assumes.

The reverse crossing, engineer to analyst, is easier on paper and harder in the part people underrate. The SQL and the data sense carry straight across; the work is learning to sit with a stakeholder, hold an ambiguous question open, and tell the story the numbers carry. That is a craft, and it is usually where the real difficulty lies, well ahead of anything technical.

Hold the two facts together. Most moves you make inside analysis are low-stakes, because the jobs sit close and the skills carry over, so a wrong early choice costs far less than the job titles suggest. Engineering is the one move that is not like the others: a different job, reached deliberately across a bridge. We walk through the modern engineering stack in what data engineering is.

If you are the employer: which to hire or build first

Picture a Monday morning where a revenue dashboard shows a number that is obviously wrong. Two different jobs meet at that number. The engineer owns why it is wrong: a pipeline that failed overnight, the fix, and the test that stops it recurring unseen. The analyst owns what it means: which decision the number was feeding, the corrected read, and the recommendation that goes back to the business.

The same incident needs both, and one dependency only ever runs one way: the analyst's answer is only as good as the engineer's data, so an analyst set to work on broken data hands back a confident wrong answer.

So let the gap decide.

• No warehouse or trusted data yet: hire the engineer first. There is nothing for an analyst to work with, and an analyst left to stitch spreadsheets together by hand produces inconsistent answers and not much else.
• A warehouse exists but the numbers keep coming out wrong: hire an engineer to fix the pipelines. This is the Monday dashboard as a standing condition rather than a one-off, and no amount of extra analysis will fix it.
• The data is reliable but nobody acts on it: hire an analyst. What is missing is the business framing and the craft that turns a correct number into a decision.
• Both look broken: start with the engineer, for the dependency above. Fix the data first, because the best analyst you can hire still reads broken data wrong.

On a small team, five people or fewer, one person usually wears both hats, and the title is normally "analyst" until the pipeline workload forces a split. The split becomes unavoidable once keeping the data flowing is a full-time job in itself: enough sources, schedules and checks that nobody can maintain them and still have time to answer questions. At that point a dedicated engineering hire earns its place.

iO-Sphere has trained 900+ learners in data and AI since 2022, and we now run data apprenticeships inside UK employers. Across that work, getting the order wrong is expensive: it usually means a long stretch of a capable analyst being pulled into engineering their role and their tooling were never set up for. If you want to talk it through for your own team, our apprenticeship team will say which role to build first, including when the honest answer is that neither a data analyst nor a data engineer is what you need yet.

The routes into each role in the UK

The route that fits you depends less on which role you want than on one fact about your situation: whether you already have an employer. With one, the funded apprenticeship is open to you; without one, paid and free courses are how you get started.

If you are employed in a role that already does real data work, the apprenticeship is the funded route, and it exists for both roles. The analyst route is our Level 4 Advanced Data & AI apprenticeship, built on the Data Analyst standard (ST0118). The engineering route is our Level 5 Data Engineering apprenticeship, built on the Data Engineer standard (ST1386).

The engineering standard carries more protected off-the-job study, 418 hours against the analyst standard's 370, in keeping with the deeper technical ground it covers. Both are set nationally, with a typical duration of 24 months, per Skills England's published standards, and we deliver ours in 15 months of training plus a 3-month end-point assessment.

You do not need a computer science degree for the Level 5 route. The standard sets no entry requirements at all, so those are the provider's to set, and the surest preparation is real analytical work rather than a stack of tools listed on a CV.

For the employer, the training is the cost the funding removes. Any start you plan now falls in the 2026-27 funding year, and for an apprentice under 25 the training costs the employer nothing, at every kind of employer; for an older apprentice the government still covers most of the training price through co-investment, with the employer paying a small share.

Levy status changes only which pocket the training cost comes from, not that outcome: a levy-paying employer draws it from its levy pot, while a smaller employer that pays no levy has it covered by government funding directly. Where a genuine choice exists, the apprenticeship is usually the one to reach for first: it is regulated, it is funded, and the learner is doing the real work throughout.

Most people who start already hold that qualifying job, and the programme is laid over the role they are in. If that is you, the practical move is to apply on our website, and our admissions team helps build the business case and prepares the person for the employer conversation, rather than opening a cold, half-formed ask with a manager.

Without an employer, there are courses you can join directly, and here the two roles part ways. On the analytics side, our Applied Diploma in Data Analytics is a 14-week full-time intensive that finishes with an NCFE Level 4 diploma badged as a Data Analyst higher technical qualification. There are also free Skills Bootcamps in data analytics, which open in funded intakes a few times a year rather than running all the time: our Oxfordshire bootcamp is funded by the DWP at Level 3, and our London bootcamp is funded by the Greater London Authority.

On the engineering side, the paid option is our Applied Diploma in Data Engineering, also 14 weeks and NCFE Level 4; the funded engineering route is the apprenticeship. These courses are built around real practice rather than tutorial exercises: our bootcamps and the Applied Diploma run on Prism, a simulated e-commerce company built on 500M+ rows of real data.

Underneath the routes, the choice itself stays simple: these are two related but different jobs, not two rungs of one ladder. Pick the one whose daily work you would want to own, or, if you are hiring, the one your team is actually missing, and let the funded route lead where it fits.