dbt Core v1.12 is GA

dbt Core v1.12 is a big one. It does two things at once. It delivers meaningful improvements for teams using dbt Core today, including UDF enhancements, simpler Iceberg catalog and Semantic Layer specs, and plenty of quality-of-life upgrades like a new on_error config for handling upstream failures, a dedicated vars.yml file, and ad hoc SQL through dbt run-operation --sql. It also introduces a new opt-in Rust-based parser, the same one that powers dbt Core v2.0, giving teams a practical, low-risk way to start preparing for the next major version of dbt.

Check out the v1.12 upgrade guide for the full list of changes.

If you’d rather hear it straight from the team, join us for a live virtual recap and Q&A. We’ll walk through what shipped, explain why it matters, share more context on the path to v2.0, and answer your questions live.

Let’s get into what’s new in dbt Core.

Take the first step toward dbt Core v2.0 with the v2 parser

Before dbt can compile or run your project, it needs to read your project files, understand your resources and configurations, resolve dependencies, and construct the DAG. As projects grow, the time required to do that work can become a meaningful part of the development loop and startup time.

dbt Core v1.12 introduces the opt-in --use-v2-parser flag, which delegates that work to the new Rust parser built for v2 instead of the Python parser used by dbt Core v1.x. On larger projects, the Rust parser can be 5–10× faster.

The flag is entirely opt-in. Nothing changes unless you enable it, and you can return to the existing parser simply by removing the flag. That makes v1.12 a low-risk place to test the new parser against your real project, identify compatibility issues, and address them gradually rather than all at once.

In other words: this is not just a performance improvement. It is a stepping stone to dbt Core v2.0.

The next major version of dbt Core is being rebuilt in Rust on the same foundations as the dbt Fusion engine. It raises the baseline for parser performance, language validation, artifacts, documentation, and adapter development. Trying the parser in v1.12 gives you an early look at one of the most foundational parts of that new architecture without requiring you to move your whole project to dbt Core v2.0 today.

And yes, we want your feedback. If you encounter a difference or edge case, open an issue and let us know. Real-world testing from the community is how we close those gaps before dbt Core v2.0 reaches GA.

New dbt framework features

More control when an upstream model fails

This one has been a long time coming.

In 2020, community member @ian-whitestone proposed allowing downstream models to continue running in cases where an upstream failure did not make their results unusable. Let’s say for example an infrequently changing country or currency dimension: if that dimension fails to refresh, a daily rollup may still be able to process new transactions against its last successful version.

The new on_error config gives teams more control over whether downstream models should be skipped or allowed to continue after a failure.

on_error accepts two values:

• skip_children (the default): all downstream models are skipped, exactly as dbt behaves today.
• continue: downstream models keep running instead of being skipped.

-- models/dim_customers.sql
{{ config(
    materialized='table',
    on_error='continue'
) }}

A cleaner home for project variables

If your project contains a lot of variables, dbt_project.yml starts doing double duty: project configuration and variable storage, in one increasingly long file that everyone on the team edits. Back in 2020, @benjaminsingleton suggested giving variables their own file to keep that file readable and cut down on merge conflicts.

dbt Core v1.12 makes that possible with support for a dedicated vars.yml file at the project root.

# vars.yml
vars:
  schema_name: analytics
  materialization: table

In addition to keeping dbt_project.yml cleaner, variables defined there are available while the project file is parsed, making them useful in project-level configuration as well. That means you can reference those variables inside your project file itself, and this is something you couldn't do when the variables lived in the same file they needed to configure:

# dbt_project.yml
models:
  my_dbt_project:
    +schema: "{{ var('schema_name') }}"
    +materialized: "{{ var('materialization') }}"

Run ad hoc SQL without creating a macro

The new --sql flag for dbt run-operation lets you execute a one-off database statement through dbt’s Jinja compilation context, without first creating a named macro. It is a simpler way to handle one-time operations while still using dbt’s existing connection and compilation behavior.

dbt run-operation --sql "grant select on {{ ref('fct_orders') }} to role reporting"

Extend reusable logic with new UDF capabilities

In dbt Core v1.11, user-defined functions (UDFs) officially became part of the dbt standard. That work was shaped by years of community experimentation and feedback and the community continued to help move it forward in v1.12.

JavaScript UDFs. You can now define JavaScript UDFs for Snowflake and BigQuery directly within your dbt project. Drop the function body in a .js file under functions/:

Then define its arguments and return type in the corresponding properties file.

A special thank you goes to @pempey, whose adapter override macro for experimenting with UDFs in additional languages gave the team a solid starting point for this work.

Python UDFs on Databricks. Python UDFs aren't new, but starting in v1.12, they can run on Databricks (Unity Catalog required), joining Snowflake and BigQuery.

Multiple signatures with overloads. The new overloads property lets one function accept several argument signatures, so you don't need a separate UDF for every input type. Each overload points to its own body file:

# functions/is_positive_int.yml
functions:
  - name: is_positive_int
    arguments:
      - name: a_string
        data_type: string
    returns:
      data_type: integer
    overloads:
      - defined_in: is_positive_int_numeric
        arguments:
          - name: a_num
            data_type: numeric

Third-party packages for Python UDFs. Python UDFs can now declare public PyPI packages through the packages config. Your warehouse installs them when it creates the function:

# functions/is_positive_int.yml
functions:
  - name: is_positive_int
    config:
      runtime_version: "3.11"
      entry_point: main
      packages:
        - numpy
        - pandas==1.5.0

Together, these enhancements make reusable transformation logic easier to define, govern, and deploy alongside the rest of your dbt project.

New Semantic Layer spec and Apache Ossie support

v1.12 introduces the latest dbt Semantic Layer YAML specification, designed to make semantic definitions feel more closely connected to the models and columns they describe.

Rather than defining a semantic model as a separate top-level resource, you can nest semantic information directly within a model. Entities and dimensions are defined at the column level, while simple metrics replace measures and can live alongside the model that provides their underlying data.

Legacy spec:

semantic_models:
  - name: orders
    model: ref('orders')
    defaults:
      agg_time_dimension: ordered_at
    entities:
      - name: order
        type: primary
        expr: order_id
      - name: customer
        type: foreign
        expr: customer_id
    dimensions:
      - name: ordered_at
        type: time
        type_params:
          time_granularity: day
      - name: status
        type: categorical
        expr: order_status
    measures:
      - name: order_total
        agg: sum
        expr: amount

metrics:
  - name: order_total
    type: simple
    type_params:
      measure: order_total

Latest spec:

models:
  - name: orders
    semantic_model:
      enabled: true
    agg_time_dimension: ordered_at
    columns:
      - name: order_id
        entity:
          type: primary
          name: order
      - name: customer_id
        entity:
          type: foreign
          name: customer
      - name: ordered_at
        granularity: day
        dimension:
          type: time
      - name: order_status
        dimension:
          type: categorical
    metrics:
      - name: order_total
        type: simple
        agg: sum
        expr: amount

This makes it easier to understand the relationship between a physical model and its semantic meaning without jumping between disconnected definitions.

dbt Core v1.12 also adds support for defining semantic models using Apache Ossie documents (formerly the Open Semantic Interchange). dbt can parse Ossie-format JSON files alongside native dbt semantic models and generate an osi_document.json artifact representing your project’s Semantic Layer.

Together, these changes move us forward on a path where semantic context is easier to author in dbt and more portable across the broader ecosystem.

Adapter-specific features and enhancements

As always, the Core release is only part of the story. Adapter maintainers have continued improving the experience across individual data platforms.

Highlights include:

• Snowflake: Iceberg v3 support and more control over dynamic-table scheduling, support for separate warehouses during initial builds, and transient tables.
• BigQuery: Parallel microbatch execution, standard SQL for partition metadata, and per-resource execution timeouts.
• Redshift: Support for the query_group session parameter, enabling better workload routing and query logging.
• Databricks: Unity Catalog row filters and additive merging of tags across project configuration levels.

Head to the v1.12 upgrade guide for the complete adapter-by-adapter breakdown.

Quick hits

Here's what else landed in v1.12.

• Native private packages: Install packages from private GitHub, GitLab, or Azure DevOps repositories using your existing SSH configuration, without specifying a full Git URL or separately configuring a token.
• Expanded Iceberg support: Use a simplified catalogs.yml specification, enable cross-platform dbt Mesh, and create Iceberg v3 tables on Snowflake.
• Composable selectors: Reference a named YAML selector within --select or --exclude, making it easier to combine reusable selectors with other selection methods.
• Clearer errors: More internal Python exceptions are now translated into useful dbt compilation and parsing errors, with cleaner default output and fewer mysterious stack traces.
• Latest version pointer: Set the new latest_version_pointer_enabled_by_default flag to true and dbt automatically creates a pointer view for every versioned model in your project, always resolving to the latest version, without any per-model configuration.
• and MANY others

What’s next: dbt Core v2.0

dbt Core v2.0 is the next major version of dbt. It replaces the Python-based v1.x runtime with the high-performance, Rust-based foundation developed for the dbt Fusion engine, while keeping the dbt framework open source under the Apache 2.0 license.

A major-version transition gives us an opportunity to remove deprecated behavior, enforce a more rigorous language specification, and establish a stronger foundation for the next era of dbt. It also means teams deserve a clear, gradual path to get there.

That path starts with v1.12.

Try the v2 parser. Resolve outstanding deprecations. See how it behaves with your macros, packages, configurations, and project structure. Tell us what works, and, more importantly, what does not.

To learn more, join the dbt Core product, engineering, and developer experience teams for a live virtual release recap and Q&A. We’ll cover the most important changes in v1.12, demonstrate the new parser, discuss how the release fits into the path toward v2.0, and answer your questions live.

And to everyone who filed an issue, contributed code, tested a prerelease, joined a discussion: thank you.