The grim reaper, labeled The Bitter Lesson, has already visited the doors marked Natural Language Processing and Prompt Engineering, and is now knocking on the door marked Skills

Do you remember what it was like trying to code with AI this time last year? The models could write SQL, but their judgment was poor. They skipped many of the signals of tradecraft that skilled analytics engineers have. Skills were the intuitive fix: give the agent the knowledge it needs for this task, without starting from zero every time or stuffing one AGENTS.md with everything that might come up. Skills arrived for Claude in October 2025 and became an open standard that December. We built our own set of dbt agent skills to give coding agents the conventions, commands, and patterns they were missing.

Models have improved a lot since then, and one must always remember the Bitter Lesson for AI, where being too clever is a losing strategy compared to just pointing more computing resources at the problem. So I wanted to check whether that bet still holds. Can the latest models build and maintain a dbt project at real-project scale without skills? And if they can, where do skills still earn their place?

I spent an afternoon or two building a proof of concept eval to find out: 22 agent runs, up to 12 tickets each, on a Formula 1 dbt project in Snowflake. I found that the difference between good runs and bad ones was process, not dbt knowledge. I wouldn't call that conclusive, but in an environment moving this fast it has changed how I think about skills.

Round 2 checks passed by model and arm. Model generation moved the score; skills didn't

• Run-to-run variance is bigger than any skills effect. The same arm, Sonnet 5.5 with skills available, scored 61%, 100% and 67% on three runs.
• The 5.5 models already know dbt. 12 of 19 Claude 5.5 runs passed every check, and without skills every 5.5 model cleared at least 92%.
• Agents rarely opened a skill on their own, and when they did, it was most often for unfamiliar ground like the Semantic Layer or dbt Mesh.
• A model generation is worth more than a skill. Sonnet 4.5 scored 38% without skills and 17% with them forced, the two lowest scores of any run, and the forced run had read the skills before it wrote its first model. (The Bitter Lesson.)
• Process failures dominated: a test that froze today's answers, failed backup attempts, ignoring definitions, miscalibrated lookback windows.

If you maintain skills for a team: cut the docs that explain how dbt works, keep the ones covering features that aren't fully integrated into your stack, and write new ones for how your team tests, deploys, and reviews. Going forward, teams that understand their process and how to support and improve it will be in a much stronger position to leverage frontier models.

Ask an analytics engineer to rename a column and they won't start with the SQL. They'll check what reads it downstream, which tests and dashboards will break, build only what changed, and compare the data before anyone reviews it. The dbt MCP server and agent skills can teach a coding agent those steps, but they can't make sure it follows them every time, builds on what's changed, or shows you the data diff before you review the changes.

We built dbt Wizard around a different idea. Wizard works like an analytics engineer: it thinks in DAGs, tests and fixes its own work, and keeps you in flow, so you review a working change instead of a first draft. None of that comes from the model; it comes from the harness, workflows, and UX we built around it.

Every company is trying to put AI to work on its own data right now, and most are discovering the same thing: the model isn't the hard part. An agent's answer is only ever as good as the context behind it, and in most organizations that context was never modeled for a machine to read.

As a community, we've traditionally been asked to build the analytical systems our teams need to understand measurable performance, and that work already serves AI: an agent can pull a governed, tested metric through the semantic layer today. But the reasons behind the numbers sit in call transcripts, support threads, and contracts that analytics tooling has never been able to reach. Shaping that data so AI can retrieve it, trust it, and cite it has a name: context engineering. It's a practice we believe the dbt community is unusually well positioned to lead.

That belief comes from the observation that context engineering isn't a new discipline you have to learn from scratch. It's analytics engineering, pointed at a new consumer. The habits that made your metrics trustworthy (version control, testing, documentation, lineage) are exactly what AI context is missing today. So we're releasing dbt_context_engineering, an open source package that brings the first set of context engineering patterns into the framework you already use. This post walks through what's in the package, what it unlocks, and why we want to work out the rest of the practice with the community.

As part of releasing dbt v2 to general availability, we've renamed the two distributions to reflect their positions in the ecosystem. The dbt Fusion engine is now just called dbt, and dbt Core v2 is now called dbt OSS. We expect that most people adopting dbt v2 will adopt the primary dbt distribution, which is free to use and locally installable.

The name changes do not change our commitment to open source: there is and always will be a completely open source implementation of the dbt standard. All of the code we released to Apache 2.0 from ELv2 or proprietary licenses in June stays the same, and moving to a shared foundation (instead of having dbt Core remain on the legacy Python engine) makes the open source version of dbt stronger.

The change to two freely usable distributions with a shared foundation is the biggest point of confusion we've seen during the v2 beta. This post will help explain the differences between dbt and dbt OSS, and provide guidance on which distribution you should choose.

After 18 months of engineering, reverse-engineering, de-engineering, and re-engineering, the dbt Fusion engine has graduated into General Availability under its new name: dbt. (Read more about that here). This complete rewrite of dbt solves a number of longstanding problems in dbt v1's implementation, and lays the foundations for another decade of progress. Before:

• dbt didn't understand the SQL it was generating, so it couldn't warn about invalid code without executing the code and consuming compute resources.
• At large scale, dbt could take as long as 20 minutes to parse a project before any execution could begin.
• dbt's artifacts made interoperability difficult, with enormous JSON files being the only way to communicate from one product to another.
• dbt docs was unable to work for many teams due to scaling and performance issues.

The new dbt v2:

• Includes rich SQL comprehension and the ability to catch code mistakes before they hit the warehouse, saving developers time and money and providing verifiable loops for agents.
• Is built for speed throughout, by moving to an optimized Rust binary and using modern technologies like ADBC. We've seen projects that used to take 20 minutes to parse now complete in less than one, and more normal-sized projects will also see a big speedup in daily usage (such as 2x or more faster compilation).
• Introduces the dbt Information Schema which describes an entire project as standard Parquet files. This can reduce file sizes by over 10x while providing richer data, and enables speedy querying through dbt show --info, external tools like DuckDB, and the brand new checks feature.
• Includes a brand new version of dbt docs, which is much more scalable.

When we open-sourced the dbt MCP server in April 2025, it was an experimental, locally hosted project with a clear thesis behind it: structured data is going to be deeply integrated into AI workflows, and dbt is the layer that provides the governed context those workflows run on. Anthropic has helped validate our thesis. Naturally, it made sense to have a cloud-hosted version with remote OAuth, so you can use it with whatever AI tool you are most comfortable with.

The remote dbt MCP server now runs inside the dbt platform, and you can connect it to Claude in a minute or two by signing in and completing the authentication flow. You add dbt as a connector, approve the access you want, and Claude gains access to your governed data and rich dbt metadata.

This post walks through what the remote server brings to Claude, the types of workflows it fits into for both people and agents, and how the tools compose once they share a conversation.

We recently released dbt Wizard, a CLI for doing agentic data work on dbt. This is a harness specifically built for data work and as such I was excited to spend an afternoon running dbt Wizard across a personal project with about 100 models or so that I've been maintaining for a while. You can use this project to see firsthand some of the differentiators for Wizard, particularly how the validation loop works.

Data projects are never done and I had a few tasks I've been putting off:

• Migrating from MotherDuck to Iceberg + BigQuery
• Upgrading dbt Core to dbt Fusion
• Migrating from dbt Core to dbt platform
• Building out a semantic layer

These are a good mix of pretty standard data work (have you done your annual migration yet?) and some dbt specific tasks. A good informal eval for the fundamental question for any dev tool: Does it work?

I was pleasantly surprised with my experience in that I didn't have to babysit Wizard or build any additional workflows on top of it. Because it has a native understanding of what a dbt project is, and its ability to set up validation subagents that match the task made it easy for me to just pop in when needed and I didn't have to babysit the whole process and I accomplished all of my objectives.

When building a dbt project, you start with the simplest strategy and only add complexity when you need more speed or reduced cost. At a model-by-model level, this is the view → table → incremental materialization pattern. At a project-wide level, optimizations used to require a lot more complexity - rebuilding only the relevant parts of a project meant you spent a lot of mental energy chaining together selectors like state:modified, source_status:fresher, or config.materialized:view and ensuring fresh JSON artifacts were distributed across your organization.

dbt State provides more speed, reduced cost, and less complexity all in one. It works wherever you do: dbt Core or Fusion, locally or on any orchestrator you choose. Since it's backed by a new paid service (with a 30 day free trial), you don't need to adopt the whole dbt platform to get these savings. dbt State supersedes state-aware orchestration, which required a dbt platform subscription and moving to Fusion.

The most technically interesting part of this is the query normalization process1 which means running the new dbt lint command doesn't instantly sign you up for a full rebuild. But before getting into the depths of syntax trees, let's recap what dbt State actually does for an end user.

The basic dbt State workflow​

When dbt runs, it will check with the dbt State server whether a model:

• already exists in the target schema and can be reused
• already exists in another schema and can be reused, or
• needs to be built from scratch.

Today, we published the first alpha release of dbt Core version 2.0, raising the baseline for what dbt users can expect from their transformation tool. As always, dbt Core's code is completely open source under the Apache 2.0 license. What makes this release significant is that dbt Core 2.0 is now built on the same foundations as the dbt Fusion engine – we've open-sourced a lot of Fusion code for the first time.

The launch of dbt Core 2.0 comes with key feature developments:

• Significant parse time improvements, especially on the largest dbt projects
• A tightly-defined language spec which makes it impossible to accidentally configure a desciptin instead of a description, and gives anyone integrating with the dbt ecosystem (including dbt's own development team!) a stable interface to build against.
• New Parquet artifacts as a high-performance alternative to large JSON files that can be directly queried through DuckDB or your agent of choice
• A completely revamped local documentation experience, powered by those new artifacts and capable of scaling to projects of arbitrary size.
• A more streamlined way to build new adapters, powered by ADBC and the Arrow ecosystem
• A simplified installation process that removes the need to fight with Python's virtual environments

"By all means, move at a glacial pace." — Miranda Priestly, The Devil Wears Prada

There's another scene in The Devil Wears Prada that I think about more than that one. If you haven't seen it yet, I'll try not to spoil it for you. Miranda turns to Andy (Miranda's assistant) and explains, with such impatience, that the cerulean blue in Andy's "lumpy sweater" didn't come out of thin air — it's traced back through a chain of deliberate fashion decisions made years earlier, by people who thought carefully about every choice. The sweater Andy bought from the store was the end of a long chain of deliberate curation, carefully veiled to protect the illusion that the sweater effortlessly came into existence.

That's how I'd describe documentation, especially in the AI era. A user — could be a developer, analyst, data engineer, tech writer 😜 — asks an AI tool a question and gets an answer. They don't need to see every decision in the chain behind it: what to include, how to structure it, where the gaps are, what needs updating. But those decisions shape every answer they get. Somewhere upstream, a docs team is making careful, deliberate choices that ripple all the way down to the moment the answer lands in the user's editor.

This blog discusses how docs teams are trying to bring those decisions closer to users — and why that architecture matters more than ever in the AI era.

It's the multitrillion-dollar question that's haunting everyone, from senior software developers and junior lawyers to Hollywood writers and, of course, data analysts and engineers: Can the robots do our jobs?

For us data people, in various forms, the signs are mixed. According to recent research from Anthropic, data scientists are already using AI to augment or automate 46 percent of their work. In two years, LLMs got good at writing code; they are now also very good at writing SQL.1

But, as every data person knows, writing queries is not our job; not really. For better or for worse (and perhaps better, if the great code-writing disruption is already here), our job is, as Caitlin Moorman put it over six years ago, glue work. We map this team's data to that team's goal; we connect questions over here to trends over there. We deal with ambiguity; we say "it depends." We tell people no.

There are two primary ways to get answers from your data using LLMs today: have the model write SQL directly, or have it query through a structured ontology like the dbt Semantic Layer. Both work. Companies are getting real value from each. But they fail in very different ways, and understanding those failure modes is what actually matters when you're deciding which to use.

In 2023, we ran a benchmark comparing the two approaches and the Semantic Layer won handily. But 2023 is roughly 10 million years ago in LLM time. Models have gotten dramatically better at writing SQL. So we reran the benchmark with the latest generation models to see whether the gap has closed.

The Catalog Linked Database Diaries: On Freshness and Writes​

Last November, at dbt Summit, Jeremy introduced dbt’s multi-platform Iceberg capabilities.

What intrigued us most was the promised interconnectivity of Databricks Unity Catalog and Snowflake catalog-linked databases.

AI’s all the rage, but another little revolution is taking shape: Teams are breaking their data storage out of vendor-specific platforms. For months, we have been chatting with users excited to adopt Iceberg as a core pillar of their data architecture. The Iceberg table format and Iceberg REST catalogs are the emerging standards powering that flexibility.

For dbt’s part, this shows up in two concrete use cases:

• dbt projects at scale: Teams share one logical database, with many schemas and hundreds to thousands of tables
• Cross-platform mesh: One project in Snowflake, one in Databricks, sharing data without juggling manual refreshes or metadata pointers

Community-driven creation and curation of best practices is perhaps the driving factor behind dbt and analytics engineering’s rise - transferable workflows and processes enable everyone to create and disseminate organizational knowledge. In the early days, dbt Labs’ Fishtown Analytics’ dbt_style_guide.md contained foundational guidelines for anyone adopting the dbt viewpoint for the first time.

Today we released a collection of dbt agent skills so that AI agents (like Claude Code, OpenAI's Codex, Cursor, Factory or Kilo Code) can follow the same dbt best practices you would expect of any collaborator in your codebase. This matters because by extending their baseline capabilities, skills can transform generalist coding agents into highly capable data agents.

dbt agent skills allow you to transform generalist coding agents into highly capable data agents

These skills encapsulate a broad swathe of hard-won knowledge from the dbt Community and the dbt Labs Developer Experience team. Collectively, they represent dozens of hours of focused work by dbt experts, backed by years of using dbt.

With access to skills, agents like Claude take a systematic approach to tasks

New engine, who dis?​

It’s unlikely that anyone reading this blog has not heard about the new dbt Fusion engine — it’s been the talk of the data town since last January, culminating in Elias’s legendary live Coalesce 2025 demo of the incredible capabilities that native SQL comprehension in dbt can unlock. If you attended Coalesce, or have upgraded your project to Fusion already, you’ve likely also heard about the changes we’ve made to the authoring layer of dbt (the literal code you write in your project). As part of the major version upgrade, we took the opportunity to simplify + standardize the configuration language of dbt to be built to scale as we enter the next era of analytics engineering.

In particular, we wanted to reevaluate how metrics are defined in the dbt Semantic Layer. We’ve heard from numerous community members over the years that defining metrics was just plain hard. In conversation with internal + external users and our newest pals from SDF, we’ve come up with a redesigned YAML spec that is simpler, more integrated to the dbt configuration experience we’ve come to know and love, and built for the future.

In April, we released the local dbt MCP (Model Context Protocol) server as an open source project to connect AI agents and LLMs with direct, governed access to trusted dbt assets. The dbt MCP server provides a universal, open standard for bridging AI systems with your structured context that keeps your agents accurate, governed, and trustworthy. Learn more in About dbt Model Context Protocol.

Since releasing the local dbt MCP server, the dbt community has been applying it in incredible ways including agentic conversational analytics, data catalog exploration, and dbt project refactoring. However, a key piece of feedback we received from AI engineers was that the local dbt MCP server isn’t easy to deploy or host for multi-tenanted workloads, making it difficult to build applications on top of the dbt MCP server.

This is why we are excited to announce a new way to integrate with dbt MCP: the remote dbt MCP server. The remote dbt MCP server doesn’t require installing dependencies or running the dbt MCP server in your infrastructure, making it easier than ever to build and run agents. It is available today in public beta for users with dbt Starter, Enterprise, or Enterprise+ plans, ready for you to start building AI-powered applications.

Introduction to dbt and BigFrames​

dbt: A framework for transforming data in modern data warehouses using modular SQL or Python. dbt enables data teams to develop analytics code collaboratively and efficiently by applying software engineering best practices such as version control, modularity, portability, CI/CD, testing, and documentation. For more information, refer to What is dbt?

BigQuery DataFrames (BigFrames): An open-source Python library offered by Google. BigFrames scales Python data processing by transpiling common Python data science APIs (pandas and scikit-learn) to BigQuery SQL.

You can read more in the official BigFrames guide and view the public BigFrames GitHub repository.

By combining dbt with BigFrames via the dbt-bigquery adapter (referred to as "dbt-BigFrames"), you gain:

• dbt’s modular SQL and Python modeling, dependency management with dbt.ref(), environment configurations, and data testing. With the cloud-based dbt platform, you also get job scheduling and monitoring.
• BigFrames’ ability to execute complex Python transformations (including machine learning) directly in BigQuery.

dbt-BigFrames utilizes the Colab Enterprise notebook executor service in a GCP project to run Python models. These notebooks execute BigFrames code, which is translated into BigQuery SQL.

Hello, community!

My name is Bruno, and you might have seen me posting dbt content on LinkedIn. If you haven't, let me introduce myself. I started working with dbt more than 3 years ago. At that time, I was very new to the tool, and to understand it a bit better, I started creating some resources to help me with dbt learning. One of them, a dbt cheatsheet, was the starting point for my community journey.

I went from this cheatsheet to creating all different kinds of content, contributing and engaging with the community, until I got the dbt community award two times, and I am very thankful and proud about that.

Since the acquisition of SDF Labs by dbt Labs, I have been waiting for the day that we would see what the result of the fusion of these two companies would be. Spoiler alert: It’s the dbt Fusion engine and it's better than I could have expected.

Today, we announced the dbt Fusion engine.

Fusion isn't just one thing — it's a set of interconnected components working together to power the next generation of analytics engineering.

This post maps out each piece of the Fusion architecture, explains how they fit together, and clarifies what's available to you whether you're compiling from source, using our pre-built binaries, or developing within a dbt Fusion powered product experience.

From the Rust engine to the VS Code extension, through to new Arrow-based adapters and Apache-licensed foundational technologies, we'll break down exactly what each component does, how each component is licensed (for why, see Tristan's accompanying post), and how you can start using it and get involved today.

Today, we announced that the dbt Fusion engine is available in beta.

• If Fusion works with your project today, great! You're in for a treat 😄
• If it's your first day using dbt, welcome! You should start on Fusion — you're in for a treat too.

Today is Launch Day — the first day of a new era: the Age of Fusion. We expect many teams with existing projects will encounter at least one issue that will prevent them from adopting the dbt Fusion engine in production environments. That's ok!

We're moving quickly to unblock more teams, and we are committing that by the time Fusion reaches General Availability:

• We will support Snowflake, Databricks, BigQuery, Redshift — and likely also Athena, Postgres, Spark, and Trino — with the new Fusion Adapter pattern.
• We will have coverage for (basically) all dbt Core functionality. Some things are impractical to replicate outside of Python, or so seldom-used that we'll be more reactive than proactive. On the other hand, many existing dbt Core behaviours will be improved by the unique capabilities of the dbt Fusion engine, such as speed and SQL comprehension. You'll see us talk about this in relevant GitHub issues, many of which we've linked below.
• The source-available dbt-fusion repository will contain more total functionality than what is available in dbt Core today. (Read more about this here.)
• The developer experience will be even speedier and more intuitive.

These statements aren't true yet — but you can see where we're headed. That's what betas are for, that's the journey we're going on together, and that's why we want to have you all involved.