Empowering analysts with dbt: Who they are and how we help

The term "data analyst" has always been broad, but today it's evolving faster than ever. As data roles diversify and generative AI reshapes workflows, traditional definitions no longer capture the full scope of what analysts do or what they need. At dbt Labs, we believe it’s time to rethink the role of the analyst and, more importantly, to build tools that meet them where they are.

In this post, we’ll share how we think about building for the analyst at dbt Labs, why this perspective matters, and how our product strategy is intentionally designed to empower them across a wide spectrum of technical skill levels.

Analysts are not just dashboard builders

Many tools still treat analysts as lightweight BI users, clicking through dashboards, downloading CSVs, or handing off requests to engineers. But that view is outdated.

Today’s analysts debug models, define metrics, investigate data lineage, and increasingly contribute to the foundations of trustworthy analytics and AI. Some write SQL daily. Others work in visual tools or prompt AI assistants to get the answers they need. Regardless of how they work, the expectations placed on them have grown.

We see analysts as critical participants in the modern data workflow, and we’re building dbt to reflect that reality.

No one definition of “analyst”

The label "data analyst" covers a wide range of responsibilities, depending on the company, the team, and the stack.

In one organization, a “data analyst” might be responsible for building ETL pipelines and maintaining data infrastructure (tasks that other companies might label “data engineering”). In another, a technically inclined “data analyst” could be closer to what some firms call a “business analyst,” primarily interpreting dashboards and writing non-technical reports. The reality is that data practitioners operate within a broad ecosystem and bring varied technical skill sets to different jobs to be done. Titles mask the actual scope of work: two people both called “data analyst” may have dramatically different day-to-day responsibilities, tooling needs, and comfort levels with code.

The spectrum of technical proficiency

When we build new analyst-friendly features, we think in terms of capabilities and comfort levels across three key dimensions:

Coding proficiency (SQL, Python, etc.)

Comfort working with code-based tools, ranging from writing advanced SQL and Python to preferring visual interfaces or natural language interactions.

Familiarity with code management practices

Experience working with version control systems like Git, including an understanding of branching, pull requests, merge conflicts, and collaborative development workflows.

Familiarity with the Analytics Development Lifecycle (ADLC) best practices

Knowledge of how testing, documentation, observability, code reviews, and rollback strategies apply to analytics and data workflows. 

Some practitioners may only sporadically apply these practices; others bake them into every project.

This view helps us design tools that meet people where they are, and where they might want to grow.

Bringing best-in-class data practices to analysts

At dbt Labs, we’re designing our products to support analysts who are shaping data products, not just consuming insights. While the broad array of tools available to analysts today have certainly empowered them to take data work into their own hands, it’s left them without the governance, testing, and SQL-first foundation the modern data stack requires.

Our new capabilities–dbt Canvas, dbt Insights, and dbt Catalog–provide a clear path to production, combining speed with trusted best practices.

To make this more concrete, with the new analyst capabilities in dbt:

1. Users who might work in dashboarding tools, like PowerBI or Sigma, instead have a path to promote their business logic into reusable dbt models with dbt Canvas, turning one-off analyses into production-ready reusable data products.
2. Users in legacy drag-and-drop tooling can get the same fast ad-hoc workflow in dbt Canva, but with added visibility and governance.
3. Users running ad-hoc queries can explore governed data assets and validate their work with dbt Insights, speeding up discovery while staying aligned with standards.
4. Users navigating complex data environments can easily find, understand, and trust their data with dbt Catalog, reducing duplication and improving collaboration.

Our latest analyst-focused investments aren’t a shift in direction; they’re a natural extension of our mission to serve more people working with data. We’re building on our foundation to serve even more analysts, more effectively.

We’re focused on meeting the needs of analysts who:

• Regularly build dashboards or respond to ad hoc data requests- answering “that one quick question” from a boss, peer, or stakeholder - but who want their work to be maintainable, not just one-off assets.
• Want to use context-aware, governed AI to more efficiently answer questions and build data products
• Occasionally need to operationalize new data assets into production pipelines without being engineers by trade.
• Seek guardrails to safely contribute to their organization’s dbt project.

These analysts often sit in a gap between lightweight tools and heavy engineering processes. Our new capabilities give them clarity, guardrails, and flexibility to move faster, without being overwhelmed.

Technical users benefit too

Building on dbt’s foundation as the tool for helping data teams work like software engineers, our analyst features benefit even technical users. Visualization of dbt models, intelligent query interfaces, and context-aware AI help streamline development, accelerate ramp time, and improve cross-functional collaboration. The analyst suite complements and expands on the code these teams have already written, making dbt even more powerful for our existing experienced dbt analytics engineering and data analyst users.

We’ve seen how AI makes data analysts more and more technical. Through our work on the dbt MCP server and AI-powered chat interfaces, users can now engage with dbt models through natural language. As these conversational experiences evolve, they’ll enable secure, self-service access to insights without requiring SQL or navigating developer tools.

Our analyst offering isn’t about narrowing focus, it’s about meeting more users where they are and giving more analysts the tools they need to turn data into impact.

Key use cases our new analyst offerings support today

Our new suite of analyst capabilities, including dbt Canvas, dbt Insights, and dbt Catalog, enable analysts to build, explore, and share data products with speed and confidence, all within a governed environment that scales with their needs.

Exploratory analytics, aided by context-aware AI

Analysts often need to investigate metrics, trends, or anomalies on the fly. dbt Insights provides a streamlined environment for running ad hoc queries, with AI assistance that understands the structure and context of the analyst's dbt project. This enables analysts to generate more accurate queries, explore data faster, and get to insight more efficiently, whether they’re writing SQL themselves or starting from natural language.

Visual, low-code/no-code transformations

For analysts who want to contribute new models but prefer to avoid raw SQL, dbt Canvas provides a visual, drag-and-drop interface for building transformations. Behind the scenes, this generates production-ready SQL that can be audited and version controlled, but the user interacts with an intuitive UI: selecting tables, applying joins, filters, aggregations, and so on. This lowers the barrier to creating new data assets while still producing artifacts that are governed by version control, testing, and deployment checks.

Discovery and trust

Analysts can browse and search for datasets, view lineage, and inspect metadata such as freshness, owners, and descriptions with dbt Catalog. This helps analysts confidently choose and use the right data without needing to escalate to engineering teams.

Streamlined collaboration between data developers and analysts

Hardcore data developers build core data models, transformations, and pipelines. Analysts often bring deep domain knowledge, understanding the nuances of business metrics, customer behavior, or product usage patterns. dbt enables collaboration between these roles through built-in workflows like pull requests, code reviews, and shared documentation. This allows analysts to prototype or suggest model adjustments and then collaborate via version control and review processes. While developers contribute engineering rigor, analysts contribute domain insight. By aligning workflows in a shared environment, dbt ensures that both technical excellence and business context shape the data products teams create together.

These workflows reflect how dbt helps analysts of all skill levels contribute more meaningfully to analytics, from first exploration to fully governed data products.

Looking ahead

The role of the data analyst is fluid and evolving. As AI reshapes how insights are generated and shared, and as embedded and self-service analytics become more common, dbt Labs is focused on enabling analysts to do more with confidence and clarity.

With our new analyst-focused offerings, dbt Canvas, dbt Insights, and dbt Catalog, we’re addressing key friction points head-on including, making it easier to discover and trust the right data, reducing the need to switch between disconnected tools for analysis and presentation, and helping analysts move from exploration to production seamlessly, all while staying within a governed environment.

We also recognize that not every data practitioner fits neatly into a single role or title. While we use personas like "analyst" or "developer" to guide our product decisions, these are flexible starting points, not fixed definitions. Our analyst offerings are designed to support a broad range of use cases, and our focus remains on helping them turn curiosity into impact by removing friction, supporting collaboration, and maintaining the standards that data teams depend on.