## Introduction

Most data teams hit the same wall. The pipelines run, the warehouse fills up, and yet nobody trusts the numbers. Two dashboards report different revenue. An analyst spends a morning rebuilding a definition of "active user" that someone already wrote last quarter. The data exists, but the data nobody argues about does not.

Analytics engineering is the work that closes that gap. It sits between the people who move data and the people who interpret it, and it owns the messy middle where raw tables become datasets you can trust.

**Analytics engineering** is the discipline of transforming raw, loaded data into clean, tested, documented datasets that analysts and business users can rely on. The analytics engineer does not build ingestion infrastructure and does not write the final business report. They own the transformation layer in between and treat it like software: version-controlled, tested, reviewed, and documented.

This role matters because the failure it prevents is so easy to miss. Nobody files a ticket that says "the metrics disagree by 3%." People slowly stop trusting the data, route around it with spreadsheets, and the warehouse becomes expensive shelfware. Analytics engineering is how a team keeps that trust.

**What this is (and isn't):** This article explains what analytics engineering is, why it emerged, and the durable ideas behind it: the shift from Extract, Transform, Load (ETL) to Extract, Load, Transform (ELT), the layered transformation model, applying software engineering practices to SQL, and the semantic layer. It doesn't teach a specific tool, and it won't walk you through setting one up. It gives you a mental model so you can evaluate any tool or workflow against it.

**Why analytics engineering fundamentals matter:**

* **Trusted numbers** - Tested, documented models stop dashboards from disagreeing with each other.
* **Less rework** - A shared transformation layer means a metric gets defined once, not re-derived in every report.
* **Faster onboarding** - Modular, named models let a new analyst find where any number comes from.
* **A bridge role** - Understanding this layer lets engineers and analysts meet in the middle instead of throwing work over a wall.

Understanding these fundamentals moves a team from collecting data to producing data products that people use without second-guessing.

This article follows a basic flow that every analytics engineering workflow shares:

1. **Load** raw data into the warehouse, untouched.
2. **Stage** each source into a clean, renamed model.
3. **Model** staged data into integrated, business-shaped tables.
4. **Test and document** those models so consumers can trust them.

![Cover: layered diagram showing raw loaded data flowing through staging and intermediate models into trusted data marts](fundamentals-of-analytics-engineering.png)

> Type: **Explanation** (understanding-oriented).  
> Primary audience: **beginner to intermediate** analysts and engineers who want a durable mental model for the layer between pipelines and reports.

### Prerequisites & Audience

**Prerequisites:** Comfort with SQL and some exposure to a database or warehouse. If pipelines are new to you, read [Fundamentals of Data Engineering][data-engineering] first, since it covers the ingestion mechanics this article assumes. It fits into the layered structure that data architecture defines.

**Primary audience:** Analysts who write SQL and want to make it durable, and data engineers who want to understand the layer that consumes their pipelines. Experienced practitioners may use it to align vocabulary with a team.

**Jump to:**

* [The Missing Middle](#section-1-the-missing-middle) • [ELT and the Modern Warehouse](#section-2-elt-and-the-modern-warehouse) • [The Transformation Layer](#section-3-the-transformation-layer)
* [Software Practices for Analytics](#section-4-software-practices-for-analytics) • [Testing and Trust](#section-5-testing-and-trust) • [The Semantic Layer](#section-6-the-semantic-layer)
* [Common Mistakes](#section-7-common-analytics-engineering-mistakes) • [Common Misconceptions](#section-8-common-misconceptions) • [When Not to Invest](#section-9-when-not-to-invest)
* [Laws, Bias, and Fallacies](#laws-bias-and-fallacies) • [Future Trends](#future-trends) • [Glossary](#glossary)

If you are new to the topic, read from top to bottom. If you already know ELT and want the modeling structure, jump to [The Transformation Layer](#section-3-the-transformation-layer).

### TL;DR – Analytics Engineering in One Pass

If you remember one thing, make it this: analytics engineering treats SQL transformations like software, so the downstream data is something you can trust rather than auditing.

* **ELT, not ETL** so raw data lands first, and transformation happens in the warehouse where it is cheap and visible.
* **Layered models** (staging, intermediate, marts) so each model has one job and you always know where logic belongs.
* **Software practices on SQL** (version control, tests, review, docs) so analytics stops being a pile of one-off queries.
* **One definition per metric** so "revenue" means the same thing in every dashboard.

The flow looks like this:

```mermaid
graph TB
    SRC[Source systems] --> LOAD[Load: raw tables, untouched]
    LOAD --> STG[Staging: cleaned, renamed, one per source]
    STG --> INT[Intermediate: joined, business logic]
    INT --> MART[Marts: tested, documented data products]
    MART --> BI[Dashboards and analysis]

    style SRC fill:#fff3e0
    style LOAD fill:#e1f5fe
    style STG fill:#e3f2fd
    style INT fill:#f3e5f5
    style MART fill:#e8f5e8
    style BI fill:#fce4ec
```

### Learning Outcomes

By the end of this article, you will be able to:

* Explain **why** analytics engineering exists as a distinct role between data engineering and analysis.
* Describe **why** ELT replaced ETL and what that shift made possible.
* Explain **why** the staging, intermediate, and mart layers each exist and what belongs in each.
* Describe **how** software engineering practices apply to SQL, and why they matter for trust.
* Explain **why** data tests and documentation are what make a dataset a product rather than an output.
* Recognize **when** a semantic layer is worth the effort, and when analytics engineering is overkill.

## Section 1: The Missing Middle

The core idea is that there is a gap between the people who move data and the people who interpret it, and that gap needs an owner. Analytics engineering is the role that fills it.

Think of a restaurant. The data engineer is the supplier who delivers raw ingredients to the loading dock: reliable, on time, in bulk. The analyst is the diner who wants a finished plate. The analytics engineer is the prep kitchen in between, turning crates of raw produce into clean, portioned, labeled components the line cooks can assemble without thinking. Skip the prep kitchen, and every cook re-washes the same lettuce, slightly differently each time.

### Why the Role Emerged

For a long time, this middle work fell through the cracks. Data engineers were busy with infrastructure and saw transformation as someone else's logic. Analysts were busy answering questions and saw transformation as someone else's plumbing. So the work happened anyway, badly: buried in a business intelligence (BI) tool, copied between spreadsheets, or hidden in a 600-line query that one person understood.

The analytics engineer takes ownership of that layer on purpose. They have enough engineering discipline to version and test their work, and enough business context to know what a "customer" actually is. That combination is the whole point of the role.

### What an Analytics Engineer Owns

* **Transformation models** - The SQL that turns raw tables into analysis-ready datasets.
* **Tests and documentation** - The assertions and descriptions that make those datasets trustworthy.
* **Metric definitions** - The single, agreed version of measures like revenue or churn.
* **Data quality in the warehouse** - Not the pipeline that loads data, but whether the loaded data is correct and usable.

### When the Role Isn't Enough

Analytics engineering owns the transformation layer, not the ends. If raw data never lands reliably, that is a data engineering problem upstream, covered in [Fundamentals of Data Engineering][data-engineering]. If the question itself is unclear or the analysis is statistically wrong, that is a data analysis problem downstream, covered in [Fundamentals of Data Analysis][data-analysis]. The analytics engineer makes the middle trustworthy; they cannot fix a broken source or a bad question.

### Quick Check: The Role

Before moving on, see if you can answer these:

* Where does an analytics engineer's responsibility start and stop?
* Why did this work fall through the cracks before the role existed?
* What does the prep-kitchen analogy say about doing transformation once versus per report?

**Answer guidance:** You can place the role in the middle, owning transformation, tests, and metric definitions, while ingestion sits upstream and interpretation sits downstream. If the boundaries feel fuzzy, re-read "What an Analytics Engineer Owns."

## Section 2: ELT and the Modern Warehouse

The core idea is that analytics engineering became practical because of a sequence change. The industry moved from ETL to ELT, and that single reordering is what made the whole discipline possible.

For decades, the pattern was **ETL**, short for Extract, Transform, Load. You pulled data from sources, transformed it in a separate processing tier, and loaded only the finished result into the warehouse. Storage and compute were expensive, so you paid to shape data before it landed, and you threw the raw version away.

The pattern flipped to **ELT**, short for Extract, Load, Transform. Cloud warehouses made storage cheap and compute elastic, so it became affordable to load all the raw data first and transform it in place, inside the warehouse, with SQL.

### Why the Reorder Matters

Loading first changes who can do the work and how safe it is.

**The raw data stays.** Because you keep the untouched source, you can rebuild any transformation from scratch when logic changes or a bug appears. Under ETL, a transformation mistake meant re-extracting from the source; under ELT, you just re-run SQL.

**SQL becomes the interface.** Transformation happens in the warehouse, in the language analysts already know. The work no longer requires a separate engineering tier, which is exactly why analysts could grow into analytics engineers.

**Transformation becomes visible.** The logic lives as queryable, version-controllable SQL instead of hidden inside an ETL tool's proprietary boxes. You can read it, review it, and diff it.

### The Modern Data Stack

This shift came packaged as the modern data stack: managed ingestion drops raw data into a cloud warehouse, in-warehouse transformation shapes it, and a BI tool reads the result. Analytics engineering is the transformation slice of that stack. The economics of cheap warehouse compute are the ground it stands on.

### Trade-offs

ELT is not free. Keeping raw data and transforming it in the warehouse means you pay for storage and for compute on every model run. A poorly written model can run up a real bill. The discipline of analytics engineering, including incremental models and sensible materializations, is partly about keeping that cost in check. The deeper storage and ingestion design belongs to data architecture, one layer down.

## Section 3: The Transformation Layer

The core idea is that good transformation is layered, not monolithic. Instead of one giant query from raw to report, you build a chain of small models where each has a single job. The standard chain has three stages.

### Staging: Clean One Source

A **staging model** maps one-to-one onto a single raw source table. It does light, boring work: rename cryptic columns, cast types, standardize casing, maybe coalesce a null. It does not join. Staging gives every downstream model a clean, predictable starting point so nobody builds on raw tables directly.

The whole model is this small on purpose: rename, cast, convert cents to dollars, drop test rows, no joins:

```sql
-- staging model: stg_orders
select
    id            as order_id,
    customer_id,
    status,
    amount_cents / 100.0  as amount_usd,
    created_at    as ordered_at
from raw.shop.orders
where not is_test
```

### Intermediate: Apply Business Logic

An **intermediate model** joins staged models and applies the logic that does not belong to any single source: combining orders with refunds, classifying customers, computing a per-order net value. Intermediate models are the workhorses, and they exist so a mart does not have to do everything at once.

### Marts: Build the Product

A **data mart** is the consumer-facing output, often denormalized and shaped around a business area like finance or marketing. A mart is what a dashboard or analyst queries. It is purpose-built, named in business terms, and the model you test and document hardest, because people depend on it.

```mermaid
graph TB
    RAW[raw.shop.orders] --> STG[stg_orders]
    RAWC[raw.shop.customers] --> STGC[stg_customers]
    STG --> INT[int_orders_with_refunds]
    STGC --> INT
    INT --> MART[fct_customer_revenue]

    style RAW fill:#fff3e0
    style RAWC fill:#fff3e0
    style STG fill:#e3f2fd
    style STGC fill:#e3f2fd
    style INT fill:#f3e5f5
    style MART fill:#e8f5e8
```

### Why Layering Wins

Layering keeps logic in one place. When the definition of a valid order changes, you edit `stg_orders` once, and all downstream models inherit the fix. A monolithic query forces you to find and change that logic in five places and miss the sixth. This is the same Don't Repeat Yourself principle that governs ordinary software, applied to SQL. Clear, consistent model names carry much of that weight, which is why [Fundamentals of Naming][naming] applies here as much as anywhere.

### Quick Check: The Layers

* What is the one job of a staging model, and what should it never do?
* Why does business logic belong in intermediate models rather than marts?
* If a customer definition changes, how many places should you have to edit?

**Answer guidance:** Staging cleans one source and does not join; intermediate carries cross-source logic; marts serve consumers. A definition change should touch one model. If you find logic duplicated across marts, the layering has leaked.

## Section 4: Software Practices for Analytics

The core idea, and the one that gives the field its name, is that analytics work improves when you treat it like software engineering. The transformation layer is code, so the practices that make code reliable make data reliable.

### Version Control

Models live in a Git repository, not in a BI tool's saved-query list. That means history, branches, and the ability to see exactly what changed and when. A bad metric change becomes a revertable commit instead of a mystery.

### Code Review

Because models are code in a repository, changes to revenue logic go through a pull request that someone else reviews before it ships. Review is where a second pair of eyes catches a wrong join or a silent filter, the same way it would for application code.

### Modularity and DRY

The layered models from Section 3 are the analytics version of functions: small, named, reused by reference rather than copy-paste. A downstream model selects from `stg_orders`; it does not re-paste the cleaning logic. Define once, reference everywhere.

### Continuous Integration

When a model changes, an automated pipeline rebuilds the affected models and runs their tests before the change is merged. This is ordinary continuous integration pointed at data, and it is covered in depth in [Fundamentals of CI/CD and Release Engineering][ci-cd]. It is what turns guesswork like "this query probably still works" into "the build is green."

### Tooling That Encodes the Workflow

These practices used to require gluing tools together by hand. Purpose-built frameworks now encode the whole workflow: compile modular SQL, resolve references between models into a dependency graph, run tests, and generate documentation. The open source [dbt][dbt-core] is the most common example, and its rise is a large part of why analytics engineering exists as a named role. It earns a mention not because the tool is the point, but because it made these practices the default instead of a heroic effort. The practices are what matter; the tool is interchangeable, the same point data architecture makes about architecture in general.

## Section 5: Testing and Trust

The core idea is that a dataset becomes a product the moment people can trust it without checking, and trust comes from tests and documentation, not from good intentions.

### Data Tests

A **data test** is an automated assertion about a table that fails the build when reality violates it. The common ones are simple and catch most real problems:

* **Not null** - a column that should always have a value never has a gap.
* **Unique** - a primary key has no duplicates, so joins do not silently fan out.
* **Accepted values** - a status column only contains values you expect, catching a new unhandled state.
* **Relationships** - every foreign key points at a row that exists, so nothing is orphaned.

```yaml
# a test specification for the orders staging model
models:
  - name: stg_orders
    columns:
      - name: order_id
        tests:
          - unique
          - not_null
      - name: status
        tests:
          - accepted_values:
              values: ['placed', 'shipped', 'refunded', 'canceled ']
```

When one of these fails, the build stops, and someone hears about it before the number reaches a dashboard. That is the entire value: problems surface at the source instead of in a board meeting. The discipline mirrors ordinary software testing, covered in [Fundamentals of Software Testing][software-testing].

### Source Freshness

**Source freshness** checks how recently a raw table was loaded. A model can be perfect and still serve stale numbers if the upstream load broke silently. A freshness check turns "the data looks old" into an alert.

### Documentation and Lineage

Documentation describes what each model and column means, in the same repository as the code, so it cannot drift out of date the way a separate wiki does. **Data lineage** is the map of how each model is built from its sources through every transformation. Lineage answers two questions that used to take an afternoon: where this number came from and what you'd break if you changed this model.

### Why This Is the Real Deliverable

A query that returns rows is an output. A dataset that is tested, fresh, documented, and traceable is a product. The difference is whether a stranger can use it without asking you a question. That is the bar analytics engineering aims for.

## Section 6: The Semantic Layer

The core idea is that the hardest disagreements in analytics are not about data; they are about definitions. A semantic layer is where a definition gets settled once.

Ask three people what "active user" means, and you will get three answers: logged in this month, performed a key action, or has a paid subscription. None is wrong, but if each lives in a different dashboard's SQL, the company has three active-user numbers and no truth. The **semantic layer** is a shared definition of entities and metrics that sits between your models and the tools that consume them, so a measure like revenue or active users is computed one way everywhere.

Think of it as the company dictionary. A dictionary does not store every sentence anyone writes; it stores the agreed meaning of each word, and every writer reaches for the same entry. The semantic layer does the same for metrics: "revenue" and "active user" get one authoritative definition, and every dashboard, notebook, and export looks it up instead of spelling it out again slightly differently.

### What It Replaces

Without a semantic layer, metric logic gets re-implemented in every BI dashboard, every notebook, every export. Each copy drifts. The semantic layer pulls that logic back into one defined place, the same way a staging model pulls cleaning logic out of every downstream query.

### Why It Is Hard

The technical part is easy; the agreement is not. Defining "churn" forces finance, product, and marketing to reconcile views they have held separately for years. The semantic layer is where that argument happens once and gets written down. That is also why it is valuable: the artifact is a decision, not just code. For how these metrics connect to business outcomes, see [Fundamentals of Metrics][metrics].

### When You Need One

A small team with five dashboards probably does not need a formal semantic layer; the shared marts are enough. The need grows with the number of consumers and the cost of disagreement. When two executives show up to a meeting with different revenue numbers, you have found the threshold.

## Section 7: Common Analytics Engineering Mistakes

Common mistakes turn a transformation layer back into the tangle it was meant to replace. Here are the ones that recur.

### Building on Raw Tables

Skipping staging and querying raw sources directly means every model re-implements cleaning, and a column rename upstream breaks everything at once. The two blocks below compute the same revenue; the difference is where the cleanup lives.

**Incorrect:**

```sql
-- a mart reaching straight into raw, redoing cleanup
select customer_id, sum(amount_cents) / 100.0 as revenue
from raw.shop.orders
where status != 'test'
group by 1
```

**Correct:**

```sql
-- The mart builds on a staging model that has already cleaned the source
select customer_id, sum(amount_usd) as revenue
from stg_orders
group by 1
```

### The Monolithic Query

Packing extract, join, business logic, and aggregation into one 500-line query makes it impossible to test a piece, reuse a piece, or understand a piece. Break it into layered models.

### Models Without Tests

An untested model is a guess. Without a uniqueness test on a key, a duplicate row in a source silently doubles revenue, and nobody notices until a customer does. Tests are not optional.

### Transformation Logic in the BI Tool

Defining metrics inside the dashboard tool hides them from version control, review, and reuse. The logic becomes invisible and per-dashboard, which is exactly the problem analytics engineering exists to solve. Keep logic in modeled, tested SQL and let the BI tool display it.

### Quick Check: Mistakes

* Why is querying raw tables directly a trap, even when it works today?
* What does a uniqueness test on a primary key protect you from?
* Where should metric logic live, and why not in the dashboard?

**Answer guidance:** You can explain that raw access duplicates logic and is fragile to change upstream, that key tests prevent silent fan-out, and that logic belongs in version-controlled models, not BI tools. If any felt unclear, revisit the matching subsection.

## Section 8: Common Misconceptions

* **"Analytics engineering is just writing SQL."** SQL is the medium, not the discipline. The discipline involves testing, layering, version control, and definition work around SQL. Anyone can write a query; the value lies in making it trustworthy and reusable.

* **"It is the same as data engineering."** Data engineering builds pipelines and infrastructure for data movement and storage, while analytics engineering converts this data into trusted models. These are different layers requiring separate skills, detailed in [Fundamentals of Data Engineering][data-engineering].

* **"A tool makes you an analytics engineer."** Adopting a framework without practices just creates the same mess in a new wrapper. Practices like version control, testing, and modularity are essential; tools make them easier.

* **"More transformation is always better."** Over-modeling incurs costs for maintenance, testing, and compute. A two-person startup doesn't need fifty models to answer five questions.

* **"Once the models are built, the work is done."** Sources change, definitions evolve, and tests need updating. A transformation layer is a living system, not a one-time build, like any codebase, as [Fundamentals of Maintainability][maintainability] explains.

## Section 9: When Not to Invest

Analytics engineering involves real overhead and isn't always worthwhile. Knowing when to skip it keeps effort worthwhile.

**The data is tiny, and the questions are one-off.** A single analyst answering ad hoc questions from one clean table doesn't need a layered, tested project; a well-written query suffices.

**The team is one person.** Version control and code review benefit teams, but solo, they might outweigh the benefit. Basic hygiene like saved, named queries still helps.

**The sources are already clean and stable.** If data is well-modeled and rarely changes, the transformation layer does little. Don't build staging for sources that need none.

**The lifespan is short.** For a one-quarter experiment or throwaway analysis, the durability analytics engineering provides is unnecessary.

**Speed to a single answer beats everything.** When you need a one-time number today, the fastest correct query beats a maintainable, reusable model.

Even when you skip full discipline, a little helps: name things clearly, keep cleaning logic in one query, and define tricky metrics. Fundamentals scale both ways.

## Laws, Bias, and Fallacies

How people reason about analytics shapes the work as much as the technology does. A few named effects and thinking traps show up again and again.

### Laws and Named Principles

* **Conway's Law** - Systems mirror the communication structure of the organization that builds them. Gist: org charts leak into data models. How it shows up: when finance and product never talk, their metrics never reconcile, and the semantic layer becomes the forced conversation.
* **Goodhart's Law** - When a measure becomes a target, it stops being a good measure. Gist: Optimizing a proxy corrupts it. How it shows up: a team told to maximize "active users" loosens the definition until the number looks good and means nothing.
* **Don't Repeat Yourself (DRY)** - Every piece of knowledge should have one authoritative representation. Gist: define once, reference everywhere. How it shows up: it is the entire justification for the layered model and the semantic layer.

### Bias

* **Confirmation bias** - Favoring data that confirms what you expected. What goes wrong: an analyst picks the metric definition that supports the conclusion they already reached. What to do instead: settle definitions in a shared semantic layer before anyone runs the analysis.
* **Sunk-cost bias** - Sticking with work because of past investment. What goes wrong: a sprawling, fragile model stays because it took months to build, even as it slows everyone down. What to do instead: judge a model by whether it earns its maintenance now, not by what it cost.
* **Automation complacency** - Trusting an automated result because it is automated. What goes wrong: people trust a green dashboard even when an untested model is silently double-counting. What to do instead: tests and freshness checks, so "automated" actually means "verified."

### Fallacies

* **False dichotomy** - Framing a choice as either-or when both can coexist. Scenario: "analyst or engineer?" when analytics engineering is precisely the role that refuses to pick.
* **Appeal to novelty** - Treating the newest tool as inherently better. Scenario: migrating the whole stack for a tool that automates practices the team has not adopted yet.
* **Moving the goalposts** - Redefining success mid-argument. Scenario: a metric debate that started about accuracy ends up about which number looks better in the board deck.

## Building Analytics Engineering That Lasts

The pieces fit into one coherent picture: raw data loaded faithfully, transformed into clean layers, tested and documented into products, with metrics defined once.

### Key Takeaways

* **Own the middle** - Analytics engineering is the trusted layer between pipelines and reports.
* **Load then transform** - ELT keeps raw data and makes SQL the interface, which is what makes the rest possible.
* **Layer the models** - Staging cleans, intermediate applies logic, marts serve, each with one job.
* **Treat SQL like software** - Version control, tests, review, and documentation are what create trust.
* **Define metrics once** - A semantic layer settles the arguments that data alone cannot.

### How These Concepts Connect

ELT loads raw data into the warehouse, allowing you to transform it into version-controlled SQL. Layering that SQL keeps logic in one place, which is what makes tests meaningful and documentation correct. Tested, documented models become products, and a semantic layer on top guarantees everyone reads those products the same way. Each idea exists to protect the trust the next one depends on. That is the same flow as the diagram in the TL;DR traces from source systems to dashboards, now with a reason attached to every arrow.

### Getting Started with Analytics Engineering

If you are starting, build the smallest version of the loop and grow it:

1. **Pick one important source** and write a single staging model that cleans it.
2. **Build one mart** that answers a real, recurring question on top of that staging model.
3. **Add a few tests** to the mart's key columns: unique, not null, accepted values.
4. **Put it in version control** and document what each column means.
5. **Wire a simple CI check** that rebuilds and tests the model on every change.

Once that loop feels routine, the same shape extends to the next source and the next question without becoming a tangle.

### Self-Assessment – Can You Explain These in Your Own Words?

Before moving on, see if you can explain these out loud:

* Why does analytics engineering exist as a separate role, and what does it own?
* Why did ELT make this discipline possible where ETL did not?
* What is the job of each model layer, and why does layering reduce rework?
* Why are tests and a semantic layer what turn data into something people trust?

If you can explain these clearly, you have internalized the fundamentals.

## Future Trends

The tools around analytics engineering churn quickly, but the underlying ideas (trusted transformation and shared definitions) move slowly. A few trends are worth tracking without mistaking them for new foundations.

### The Semantic Layer Moves Down the Stack

Metric definitions are shifting out of individual BI tools and into a shared layer that many tools query.

**What this means:** The "one definition of revenue" goal gets closer to being enforceable, because the definition lives below every consumer rather than inside one of them.

**How to prepare:** Get disciplined about defining metrics in modeled SQL now, so the logic is ready to lift into a semantic layer when one arrives.

### Data Contracts and Producer Accountability

Data contracts push quality expectations upstream, asking the teams that produce data to guarantee its shape rather than having analytics engineers clean up surprises.

**What this means:** Some staging and testing burden shifts to producers, and the boundary between data engineering and analytics engineering gets negotiated explicitly. This is a Conway's Law problem as much as a technical one.

**How to prepare:** Be precise about what your models assume from each source. A clear assumption is the first draft of a contract.

### AI-Assisted Modeling

Assistants now draft models, tests, and documentation from a schema and a prompt.

**What this means:** The mechanical part of writing SQL gets cheaper, which raises the value of the judgment that does not automate: what a metric should mean and whether a model is correct.

**How to prepare:** Lean into the definition and review work. Generated SQL still needs tests and a human who knows what "correct" means here.

## Glossary

## References

### Related Articles

*Related fundamentals articles:*

**Data foundations:** [Fundamentals of Data Engineering][data-engineering] covers the ingestion and pipeline mechanics that load the raw data that this layer transforms. [Fundamentals of Databases][databases] explains the warehouse storage and query concepts the models depend on. [Fundamentals of Data Analysis][data-analysis] shows how the trusted datasets are used downstream.

**Engineering practices:** [Fundamentals of Software Testing][software-testing] grounds the testing mindset that data tests apply to SQL. [Fundamentals of CI/CD and Release Engineering][ci-cd] explains the automation that rebuilds and validates models on every change. [Fundamentals of Maintainability][maintainability] covers why a transformation layer is a living system. [Fundamentals of Naming][naming] matters because clear model names carry much of the layering's value.

**Measurement:** [Fundamentals of Metrics][metrics] connects the semantic layer's definitions to business outcomes. [Fundamentals of Monitoring and Observability][monitoring] is how you detect when a model goes stale or a test starts failing.

### Practical Resources

* [dbt Core][dbt-core], the open source framework that compiles modular SQL, builds a dependency graph, and runs tests, is a large reason analytics engineering exists as a named role.
* [The Analytics Engineering Guide][ae-guide], for a fuller treatment of the role and its workflow.
* [Kimball, R., & Ross, M., The Data Warehouse Toolkit][kimball], the definitive guide to the dimensional modeling that shapes data marts.
* [Fundamentals of Data Engineering: Plan and Build Robust Data Systems][data-engineering], the definitive guide to the data engineering workflow.

**Note:** Analytics engineering tooling evolves faster than the ideas underneath it. Treat new tools with curiosity, but check them against the fundamentals (trusted transformation and shared definitions) before assuming they change anything essential.

[data-engineering]: https://jeffbailey.us/blog/2025/11/22/fundamentals-of-data-engineering/
[databases]: https://jeffbailey.us/blog/2025/09/24/fundamentals-of-databases/
[data-analysis]: https://jeffbailey.us/blog/2025/10/19/fundamentals-of-data-analysis/
[software-testing]: https://jeffbailey.us/blog/2025/11/30/fundamentals-of-software-testing/
[ci-cd]: https://jeffbailey.us/blog/2025/12/23/fundamentals-of-ci-cd-and-release-engineering/
[maintainability]: https://jeffbailey.us/blog/2026/02/22/fundamentals-of-maintainability/
[naming]: https://jeffbailey.us/blog/2025/12/31/fundamentals-of-naming/
[metrics]: https://jeffbailey.us/blog/2025/11/09/fundamentals-of-metrics/
[monitoring]: https://jeffbailey.us/blog/2025/11/16/fundamentals-of-monitoring-and-observability/
[dbt-core]: https://github.com/dbt-labs/dbt-core
[ae-guide]: https://www.getdbt.com/analytics-engineering/
[kimball]: https://www.kimballgroup.com/data-warehouse-business-intelligence-resources/books/data-warehouse-dw-toolkit/
[data-engineering]: https://www.amazon.com/dp/1098108302