What is analytics engineering, and when does your team need it?

Analytics engineering is the discipline of transforming raw data in a warehouse into clean, tested, well-documented models that analysts and business intelligence tools can rely on. An analytics engineer sits between data engineering, which moves and stores data, and data analysis, which answers questions with it. They own the transformation layer: the SQL models, tests, and documentation that turn messy source tables into trustworthy tables everyone builds on.

This guide is for data teams, founders, and operators trying to understand a role that barely existed five years ago and now appears on most modern data team org charts. It explains what analytics engineers actually do, where the role fits in the data stack, the tools and workflow involved, and a practical way to decide whether your team needs one yet or can get by without it.

What does an analytics engineer do?

An analytics engineer builds and maintains the data models that everything downstream depends on. Their day-to-day work is mostly SQL, version control, and testing rather than dashboards or infrastructure.

Concretely, the job breaks down into a few responsibilities:

• Modeling. Take raw, loaded source data (Stripe charges, product events, CRM records) and reshape it into clean, analysis-ready tables with consistent naming, types, and grain. This is the core of the role.
• Testing. Write automated checks that catch problems before they reach a dashboard: uniqueness, non-null keys, accepted values, referential integrity. A failing test blocks the pipeline instead of shipping bad numbers.
• Documentation. Describe what each table and column means, where it comes from, and how a metric is defined, so analysts and business users are not guessing.
• Defining metrics. Encode business logic once (“active customer,” “monthly recurring revenue,” “qualified lead”) so every report uses the same definition. This overlaps with the semantic layer and is a frequent source of confusion when it lives in too many places.
• Enabling self-serve. Ship models that are clean enough for analysts and non-technical teammates to query and build on without help.

The distinguishing trait is that analytics engineers apply software engineering practices (version control, code review, testing, CI, modular code) to analytics work that used to live in ad hoc SQL scripts and spreadsheet formulas.

Where does analytics engineering fit in the data stack?

The role exists because a gap opened up between two established jobs. Data engineers were focused on pipelines and infrastructure. Data analysts were focused on answering business questions. The messy middle, turning loaded raw data into reliable modeled data, was owned by no one and done inconsistently by both.

Here is how the three roles compare in a typical modern setup.

In practice these boundaries blur, especially on small teams where one person wears all three hats. But the mental model holds: data engineers get data in, analytics engineers make it trustworthy, analysts turn it into decisions. Analytics engineering is the connective tissue that makes the other two roles more productive.

What is the analytics engineering workflow?

The workflow mirrors software development, applied to data. A typical loop looks like this:

1. Load raw data. Ingestion tools land source data in a warehouse like Snowflake, BigQuery, or Redshift. This is the “extract and load” of ELT, and it usually belongs to data engineering or a managed connector.
2. Model it. The analytics engineer writes SQL that transforms raw tables into staging models (light cleanup, renaming, typing) and then into marts (business-ready tables shaped around how teams think). This is the “transform” step, and it now happens inside the warehouse rather than before loading.
3. Test it. Automated tests validate assumptions. If a primary key is suddenly duplicated or a revenue column goes null, the test fails and the bad data does not propagate.
4. Document it. Descriptions and lineage are generated so anyone can see what a table means and what it depends on.
5. Deploy it. Changes go through version control and code review, then a scheduled job rebuilds the models on a cadence (often nightly or hourly).
6. Expose it to BI. The clean marts become the foundation that dashboards, reports, and ad hoc queries run against.

The shift worth noting is from ETL to ELT. In the old model, data was transformed before loading, often in rigid, hard-to-change pipelines. Cheap cloud warehouse compute made it practical to load raw data first and transform it inside the warehouse with SQL, which is exactly the space analytics engineering occupies. For the related question of where metric logic should live across this chain, see where to define business metrics.

Why did analytics engineering emerge?

The role is a product of three changes that landed around the same time.

• Cloud warehouses got cheap and fast. Snowflake, BigQuery, and Redshift made it affordable to store raw data and run heavy transformations after loading, which killed the need to transform everything upstream.
• Transformation tooling matured. dbt popularized the idea of building data models as version-controlled SQL with built-in testing and documentation. It gave the emerging role a name and a toolkit. dbt Labs coined the term “analytics engineer” in its widely cited analytics engineering guide.
• BI tools pushed self-serve. As more people wanted to answer their own questions, the quality of the underlying models started to matter more than the dashboards on top. Bad models produce confident, wrong answers at scale.

Put together, these created demand for someone who could own the transformation layer with engineering rigor. That someone is the analytics engineer.

What tools do analytics engineers use?

The stack is fairly consistent across teams, organized by layer:

• Warehouse: Snowflake, BigQuery, Redshift, Databricks, or increasingly a Postgres-based warehouse for smaller teams. This is where models are built and stored.
• Transformation: dbt is the dominant tool, though SQL views, stored procedures, and newer alternatives like SQLMesh are also used. This is the analytics engineer’s primary workspace.
• Ingestion: Fivetran, Airbyte, or Stitch load raw data from sources. Analytics engineers usually consume this rather than build it.
• Orchestration: Airflow, Dagster, or dbt Cloud schedule and sequence the model builds.
• BI and consumption: The clean models feed a BI tool where analysts and business users explore data and build dashboards.

A team does not need every layer. Many lean teams run a warehouse, dbt, a managed connector, and a BI tool, and skip standalone orchestration entirely.

When does your team actually need an analytics engineer?

This is the question most role explainers skip. Hiring a dedicated analytics engineer is a real investment, and plenty of teams either do not need one yet or already have someone doing the work under a different title. Use these signals to decide where you stand.

You probably need analytics engineering when:

• Multiple teams define the same metric differently, and nobody trusts the numbers in a meeting. This is the clearest signal. It is a modeling and definition problem, and it is exactly what the role fixes.
• Analysts spend more time cleaning and joining raw tables than answering questions. Repeated, ad hoc cleanup is a sign the transformation layer should be built once and reused.
• Dashboards break silently when a source schema changes, and you find out from a confused executive rather than a test.
• You have moved to a warehouse and loaded raw data, but there is no consistent modeled layer on top of it.

You probably do not need a dedicated hire yet when:

• You are a small team running analytics on a production database or a single warehouse, and one analyst can model the handful of tables that matter. The work still needs doing, but it may be part of an analyst’s or engineer’s role rather than a separate job.
• Your metric definitions are simple and stable, and there is no disagreement about what the numbers mean.
• You have not yet centralized data into a warehouse. Solve ingestion first; there is nothing to model well until the data is in one place.

The honest framing: analytics engineering is work that every data team does, whether or not anyone holds the title. The question is rarely “do we need the function” and more often “has the volume and complexity grown enough to justify a dedicated person.” For most startups, the answer arrives when metric disputes and repeated cleanup start eating real analyst time.

How analytics engineering relates to BI and self-serve analytics

Analytics engineering and business intelligence are complementary, not competing. Analytics engineers build the trustworthy foundation; BI tools are how people consume it. The better the models, the more a business can safely offer self-serve analytics without every question routing through the data team.

The relationship also shapes how much analytics engineering you need. A heavy, warehouse-plus-dbt stack makes sense when data complexity is high. But a lot of teams overbuild the transformation layer before they have the scale to justify it. Modern BI tools have absorbed part of the role: they connect directly to databases and warehouses, let you define reusable metrics, and let non-technical teammates query clean data in plain language.

Basedash is one example. It connects to sources like PostgreSQL, Snowflake, and BigQuery, lets teams define and reuse metrics, and lets technical and non-technical users explore data through natural language and charts. For a lean team, that can cover the “expose clean, consistent data to the business” half of analytics engineering without a full dbt-and-orchestration setup, and layer cleanly on top of one when you do adopt it. If your data already lives in a warehouse modeled with dbt, see how to choose a BI tool for dbt without duplicating your metrics.

FAQ

What is the difference between an analytics engineer and a data engineer?

A data engineer builds and maintains the pipelines and infrastructure that move and store data, working mostly in Python and orchestration tools. An analytics engineer takes that loaded data and transforms it into clean, tested, documented models using SQL, usually in dbt. Data engineering gets data into the warehouse reliably; analytics engineering makes it trustworthy and ready for analysis. On small teams one person often does both.

What is the difference between an analytics engineer and a data analyst?

A data analyst answers business questions by querying data, building dashboards, and making recommendations. An analytics engineer builds the modeled tables and metric definitions that analysts query. Analysts optimize for insight and speed of answering questions; analytics engineers optimize for correctness, consistency, and documentation of the underlying data. The analyst is a primary internal customer of the analytics engineer’s work.

Do you need dbt to do analytics engineering?

No, but dbt is the dominant tool and shaped how the discipline is practiced. Analytics engineering is fundamentally about applying software practices (version control, testing, documentation, modular SQL) to the transformation layer. You can do that with dbt, SQLMesh, plain SQL views, or a warehouse’s native tooling. dbt is popular because it bundles those practices into one workflow, but the principles matter more than the specific tool.

Does a startup need an analytics engineer?

Usually not as a dedicated hire early on. The work of modeling and cleaning data still needs doing, but a single analyst or engineer can handle it while the number of tables and metrics is small. The signal to hire specifically for the role is when teams disagree about metric definitions, analysts spend most of their time cleaning data, or dashboards keep breaking when sources change. Before that point, a warehouse and a capable BI tool often cover the need.

What skills does an analytics engineer need?

Strong SQL is the core skill, followed by data modeling (dimensional modeling, understanding grain and keys), and comfort with software engineering practices like version control, code review, and automated testing. Familiarity with dbt, a cloud warehouse, and at least one BI tool is standard. The role also rewards communication skills, since defining metrics correctly requires understanding what the business actually means by terms like “active user” or “revenue.”