Today we are introducing the dbt integration in Cube.

The integration connects your existing dbt project to Cube and turns every dbt model into a governed cube in your semantic layer—dimensions, measures, descriptions, and joins, generated from the modeling work your team has already done. You can run a pull manually, or put it on a schedule: trigger one from your CI pipeline or on every push to your dbt repo, and Cube regenerates the matching cubes and routes them to a reviewer before anything goes live.

We think about the data model as layers. Your dbt project is the bottom layer—tables, columns, and the tests that encode how they relate. The Cube data model sits on top of it, and that's where you define what dbt doesn't: more advanced metrics, the dimensions and joins people explore against, the semantics an AI agent needs to answer a question correctly. That upper layer builds on the foundation you already have in dbt instead of restating it.

The way the integration works is that it reads your dbt models and turns them into the foundational cubes in the Cube data model, and from there you can create and extend those cubes with all the advanced metrics on top. The sync regenerates those foundational cubes when needed.

One direction to start

What we're shipping today is the first big piece: metrics sync one way, dbt → Cube. Cube clones your repo and reads it; it never writes back. dbt stays the source of truth for how your tables are transformed, and Cube governs the models on top of it—powering dashboards and analytics chat for your own team, embedded analytics for your customers, and the AI agents and APIs that query them. Nothing in your dbt repo changes, and the credentials you hand Cube only ever need read access.

The layered model is meant to run both ways. The fastest place to prototype a new metric or dimension is often the upper Cube layer—you define it there, iterate against real questions, and use it right away. Once it's proven, it may belong down in the dbt layer as part of the shared foundation, and we want to support that move too: promoting a definition from Cube back into dbt. Today's pull runs one way, dbt → Cube; that two-way flow is where we're taking it.

For now, the unit of translation is the dbt model. The integration doesn't import metric definitions, trigger a dbt run, or manage your transformations—it assumes your tables are built and generates the layer that makes them queryable.

What a pull generates

When a pull runs, Cube clones your dbt repository into a short-lived, isolated sandbox, installs your project's dependencies, and runs dbt parse to produce the manifest—dbt's structured description of every model, column, test, and constraint. A pull never connects to your data warehouse—a line we drew deliberately: it reads your project's structure, not your data, and assumes the tables were already built by your own dbt run. That keeps a pull fast, and it means the integration can't touch production data.

How the dbt integration works: dbt models flow from your repo through Cube, which parses the project and generates cubes on a reviewable branch

From the manifest, each dbt model becomes one cube:

  • Columns become dimensions, with types mapped from the column data types.
  • Descriptions carry over. The documentation you wrote on models and columns in dbt shows up on the generated cubes and fields.
  • Every cube gets a count measure, and numeric columns with additive names (amount, total, price) get sum measures.
  • Primary keys are detected from id and *_id columns and marked on the matching dimensions.
  • dbt relationships tests and foreign-key constraints become joins between cubes—many_to_one, one_to_many, or one_to_one.

Because the joins come from relationships you've already encoded as tests, the generated model arrives pre-wired—you can query across cubes from the first pull without adding a single join by hand.

Generated cubes get configurable name and title prefixes (dbt_ and (dbt) by default) so they're easy to tell apart from hand-written ones, and you can scope a pull to your marts folder or a dbt selector like tag:cube instead of the whole project.

A dbt model side by side with the cube generated from it, showing carried-over descriptions and a generated join

Automated sync

You can run a pull by hand: open the data model in dev mode, choose Integrations → dbt → Pull, review the generated cubes in the Changes view, merge. That's the right way to run your first pull. But a semantic layer that's synced only when someone remembers to sync it drifts just like a hand-written one, so the integration automates the same pipeline:

  • Trigger from your CI. Cube exposes a REST endpoint you can call at the tail end of your dbt deployment job, right after dbt run. As soon as your warehouse tables are rebuilt, your pipeline tells Cube to regenerate the matching cubes. The endpoint URL for your deployment is shown in the dbt settings card, ready to drop into a CI step.
  • Trigger on every push. Register a webhook on your dbt repository and Cube syncs whenever the tracked branch changes. Pushes are verified by signature, de-duplicated, and scoped to the branch you're syncing.
  • Review notifications. When an automated sync produces changes, Cube emails the reviewers you nominate with a link straight to the review.
  • One saved configuration. Output path, prefixes, model selection, join generation, and the rest now live on the integration, so every pull—manual or automated—uses the same settings. You also pick which branch of the dbt repo to sync.

Automated syncs never write to your live model. Each one lands on a fresh review branch, and a person approves the changes before they reach production. So when dbt changes overnight, the regenerated cubes are waiting on a review branch for someone to approve the next morning.

Credentials and access

You connect Cube to your repo over HTTPS with a personal access token, or with an SSH deploy key—Cube generates the key pair and shows you the public half to register on your Git host; the private key is stored server-side and never leaves Cube. That makes the integration provider-agnostic: GitHub, GitLab, Bitbucket, Azure DevOps, and self-hosted Git servers all work, including orgs that mandate SSH deploy keys. Either way, the secret is stored encrypted and resolved server-side at pull time—your Git credentials never touch the browser. The sandbox that runs a pull is torn down after each run, along with the cloned files and any key material.

The dbt project settings card on the Data Sources page, with the HTTPS / SSH authentication toggle and the generated public deploy key

Getting started

The dbt integration works with Snowflake, Amazon Redshift, PostgreSQL, and Google BigQuery today.

If you're already on Cube: open Settings → Data Sources, fill in the dbt project card—repository, auth, project path, branch, and the schema your production dbt run builds into—and run a first pull from Integrations → dbt → Pull. Review the generated cubes, merge, then wire up the CI endpoint or the webhook and add reviewer emails so the semantic layer keeps up with dbt from there.

If you're not on Cube yet, request a demo and we'll walk you through the dbt integration against your own project.