Analytics Engineering Is Not Just dbt

When I mention analytics engineering in conversations, the response is often immediate: "Oh, so you use dbt?"

That's like asking a chef if they use a knife. Yes, but the knife isn't the cuisine.

Analytics engineering is a discipline that happens to use dbt (among other tools). Understanding this distinction is essential for building sustainable, scalable data practices.

What Analytics Engineering Actually Is

Analytics engineering sits between raw data ingestion and business intelligence. It's the layer that transforms raw data into trusted, reusable, business-logic-infused datasets.

The discipline involves:

1. Data Modeling: Designing structures that serve multiple use cases
2. Business Logic Standardization: Ensuring KPIs mean the same thing everywhere
3. Testing & Quality: Validating data correctness and completeness
4. Documentation: Making data self-describing
5. Version Control: Managing changes systematically
6. Collaboration: Enabling data consumers to contribute

dbt is a tool that supports these practices. It's excellent at transformation orchestration, testing, and documentation. But analytics engineering exists independently of any specific tool.

The Tool vs. Discipline Trap

I've seen teams install dbt, run a few tutorials, and declare themselves "doing analytics engineering." That's like installing Git and declaring yourself a software engineer.

The symptoms of this trap:

• Models that mirror source systems exactly (no abstraction)
• Business logic scattered across BI tools
• No testing strategy beyond "does it run?"
• Documentation that's outdated within weeks
• Metrics defined differently in different places

These problems persist even with dbt if you're not applying the underlying discipline.

The Analytics Engineering Mindset

Here's how I think about analytics engineering:

Layer 1: Staging

• Raw data from sources, minimally transformed
• Focus on getting data reliably into the warehouse
• No business logic here

Layer 2: Intermediate

• Cleaned, standardized data
• Basic transformations (type casting, null handling, deduplication)
• Reusable building blocks

Layer 3: Marts

• Business-logic-infused datasets
• Organized by domain (sales, marketing, operations)
• Ready for consumption by BI tools

Layer 4: Metrics

• Standardized calculations
• Single source of truth for KPIs
• Semantic layer implementation

Each layer has different requirements, different testing strategies, and different documentation needs. Understanding this architecture—and applying it consistently—is analytics engineering, regardless of the tool.

What dbt Actually Provides

dbt excels at:

• Transformation Logic: SQL-based transformations with Jinja templating
• Testing: Built-in and custom tests for data quality
• Documentation: Integrated docs generation from code and comments
• Version Control: Native Git integration
• Dependency Management: Automatic DAG construction

These capabilities support the discipline, but they don't replace it. You still need:

• Thoughtful data modeling decisions
• Business logic standardization processes
• Governance and ownership models
• Collaboration workflows
• Architecture decisions

Building the Discipline

If you're adopting analytics engineering (with or without dbt), focus on:

1. Start with modeling: Understand your domains, design your layers, then implement in dbt
2. Standardize early: Define KPIs once, implement in the semantic layer
3. Test comprehensively: Data quality isn't optional
4. Document continuously: Make it part of the workflow, not an afterthought
5. Iterate on architecture: Your first model won't be perfect; learn and improve

The Bottom Line

Analytics engineering is about creating a sustainable, scalable approach to turning raw data into business insights. dbt is an excellent tool for this, but the discipline transcends any single technology.

Focus on the principles. Then choose the tools that best support them. That's how you build analytics engineering practices that last.