Guides
Analyst vs analytics engineer vs data engineer vs data scientist
What each of the four core data roles actually does day to day, where they overlap, and how careers move between them.
These four titles get used loosely enough that two companies' "data scientist" job postings can describe almost entirely different jobs. The titles do point at real, distinct work — the confusion is mostly about where each company draws the boundaries between them, and how much of the earlier stages of the pipeline one person is expected to cover. This guide describes what each role does when the boundaries are drawn cleanly, and where in practice they blur.
Data engineer: gets data somewhere queryable
A data engineer builds and operates the pipelines that move data from source systems — production databases, third-party APIs, event streams — into a warehouse or lake where it can be queried. The daily work looks more like software engineering than analysis: writing and maintaining ETL or ELT code, managing orchestration and scheduling, handling schema changes in source systems without breaking downstream tables, and being on call when a pipeline fails overnight.
The core skill is software engineering discipline applied to data movement: testing, version control, monitoring, and designing for a source system that will eventually change its schema without warning. A data engineer's success is measured by whether data reliably, correctly and promptly lands where it is supposed to — not by what conclusions are drawn from it.
Analytics engineer: turns loaded data into modeled, trustworthy tables
An analytics engineer picks up where the data engineer's pipeline ends: raw, loaded tables that are technically queryable but not yet clean, documented, or joined in a way a business user could safely use. They write the SQL transformations — often in dbt or a similar tool — that turn raw tables into tested, documented models: deduplicated, correctly typed, joined to the right grain, with business logic (what counts as a completed order, how "active" is defined) encoded once rather than reinvented in every downstream query.
This role emerged specifically because analysts were writing the same complex transformation logic repeatedly in BI tools, and data engineers were focused upstream on ingestion, leaving a gap in the middle that nobody owned. The core skill is data modeling combined with strong SQL and enough software engineering practice (version control, testing) to treat transformation logic as production code.
Data analyst: answers business questions with what exists
A data analyst takes data — ideally already modeled by an analytics engineer, sometimes not — and answers a specific business question: why did conversion drop last week, which channel is most efficient, what does the customer base look like by segment. The output is usually a report, a dashboard, or a written recommendation, and the job is judged on whether it changed a decision, not on the elegance of the underlying query.
The core skill is less about any single tool and more about translation in both directions: turning a vague business question into a well-specified analysis, and turning a statistical result back into a plain-language recommendation a non-technical stakeholder can act on. Strong SQL and BI tool fluency are table stakes; the differentiator is judgment about what matters and skepticism about what a number is actually showing.
Data scientist: builds models beyond descriptive reporting
A data scientist applies statistical methods and machine learning to problems that go beyond describing what already happened: predicting churn before it occurs, optimizing a price, running and analyzing a controlled experiment, or building a recommendation system. The work spans from exploratory analysis through model building to, often, working with engineers to get a model running in production.
The core skill set includes statistics and experimental design, machine learning methods, and enough software engineering to make a model's output usable and monitorable in a live system — a model that scores well offline and is never deployed, or is deployed and silently degrades unnoticed, has not actually delivered value.
A quick reference
| Role | Primary output | Judged on |
|---|---|---|
| Data engineer | Reliable pipelines into a queryable store | Data lands correctly, on time, every time |
| Analytics engineer | Tested, documented data models | Downstream numbers are consistent and trustworthy |
| Data analyst | Reports, dashboards, recommendations | Whether the work changed a decision |
| Data scientist | Predictive or causal models | Whether a deployed model holds up in production |
Titles do not map to this table identically everywhere. Smaller companies often use "data scientist" for work this guide would call analyst or analytics engineer work, simply because it was the most recognizable title to post; larger companies with mature data organizations tend to use the four titles closer to the definitions above, because they have enough headcount to actually separate the work. Reading a job description's list of day-to-day responsibilities, rather than trusting the title alone, is the more reliable way to tell which of these four jobs is actually on offer.
Where the boundaries blur
At smaller companies, one person frequently covers two or three of these roles — commonly analyst and analytics engineer together, since both require SQL depth and business context, or data engineer and analytics engineer together, since both touch the same pipeline. At larger companies with dedicated headcount for each, boundaries sharpen, but real overlap persists in two areas: analytics engineers and data engineers both care about pipeline reliability, just at different stages of it; and analysts and data scientists both care about turning results into recommendations, just with a different toolkit for producing the result.
How careers move between them
There is no single correct path, but two common ones:
- Analyst → analytics engineer → data engineer, moving progressively upstream and toward more software engineering, as an analyst grows frustrated maintaining fragile ad hoc queries and invests in the SQL and pipeline skills to fix the source of the fragility.
- Analyst → data scientist, moving toward more statistical depth, as an analyst's descriptive questions ("what happened") evolve into predictive or causal ones ("what will happen, or what caused it") that need formal statistical methods to answer credibly.
Moves in either direction are common and neither is a demotion; they reflect genuinely different day-to-day work, and the right next role depends on which part of the problem — getting data to exist, modeling it cleanly, answering business questions, or building predictive systems — is more interesting to keep doing.
For hiring managers
See how to hire your first data person for matching a role to what the business actually needs first, and how to structure an analytics team for how these roles typically combine into a team as headcount grows. For candidates, see how to become a data analyst for a concrete skills and portfolio path into the most common entry point among the four.