If your analytics team is waiting too long for dbt CI jobs to finish, it can stall developer productivity significantly. Long pull request checks—whether 30, 45, or even 60 minutes—create a slow feedback loop that delays insights, increases compute costs, and frustrates engineers. Imagine shrinking those run times by over 90%.

dbt’s Slim CI (or Slim Build mode) is designed to build and test only what has changed. Instead of running your entire dbt project with every commit, Slim CI smartly detects the modified models and their downstream dependencies, saving you precious time and resources.

In this practical guide, we will explain how dbt Slim CI works and provide a step-by-step playbook to implement a production-ready pipeline using GitHub Actions. You will learn not only how to set it up but also how to implement it properly—a core principle in our dbt development workflows. At Stellans, we help enterprise teams perfect this process, and now we are sharing our playbook with you.

dbt Slim CI applies the core principles of Continuous Integration specifically for analytics engineering. It transforms your CI/CD pipeline into a precise, efficient instrument.

From Full Builds to Smart Builds

Think about your dbt project as a 500-page book. Traditional CI is like proofreading the entire book from cover to cover every time a typo is corrected. Although thorough, it’s highly inefficient.

dbt Slim CI is smarter. It recognizes changes in just one word in Chapter 5. Rather than rereading the whole book, it focuses on that chapter and any chapters referencing it. This is the heart of Slim CI: it uses a feature called state comparison (state:modified+) to identify the small subset of changed models and their dependent models. This creates a build process that’s faster, more economical, and focused.

The Core Benefits: Speed, Cost, and Confidence

Slim CI is a strategic upgrade that brings clear business benefits. At Stellans, clients have often reduced CI times by more than 90%, gaining:

• Speed: The most immediate impact is faster feedback. CI times typically drop from 40 minutes to under 4, empowering your team to iterate rapidly, test comprehensively, and merge changes with confidence.
• Cost: Fewer models processed means lower compute costs in your data warehouse. Each CI job uses a fraction of resources, helping reduce your Snowflake, BigQuery, or Redshift bills.
• Confidence: Quick feedback helps developers catch errors early while the context is fresh. This results in higher-quality code, fewer incidents in production, and a more agile analytics team.

To run Slim CI effectively, you need to understand three key components working together to allow dbt to compare states and build models intelligently.

Key Components You Need to Understand

• Production Artifacts (manifest.json): This file acts as a detailed map of your dbt project. It’s a JSON document representing every resource (models, tests, sources, etc.) and their relationships. Slim CI requires a “golden copy” of this manifest from your most recent production run, serving as the baseline for comparison.
• State Comparison (state:modified+): This selector is the engine behind Slim CI. Running a dbt command with –select state:modified+ means:
  • Comparing code in your current branch against the production manifest.json.
  • Identifying all modified models.
  • Including all downstream models depending on those changes (indicated by +). This approach tests changes both in isolation and in context.
• Deferred Execution (–defer and –state): These flags enable running part of your project without failures.
  • –state ./prod_artifacts: Points to your production manifest.json, providing dbt the context of existing resources.
  • –defer: Instructs dbt to assume that if a model referenced by ref isn’t part of the slim build, it already exists in production. Without this, dbt would fail finding upstream models during the current run.

Now it’s time to apply the theory. Below is our production-ready playbook for setting up a dbt Slim CI pipeline with GitHub Actions.

Prerequisites

• A dbt Project in a Git Repository: Host your dbt project on GitHub.
• A Scheduled Production Job: Have a dbt job that runs your entire project regularly (e.g., daily) to serve as your production environment.
• Cloud Storage for Artifacts: Use a storage service to save your production manifest.json. Popular options include Amazon S3, Google Cloud Storage (GCS), or Azure Blob Storage.

Step 1: Generate and Store Your Production Manifest

Modify your main production dbt job to save its manifest file to cloud storage after every successful run.

Here is an example GitHub Actions workflow snippet that runs daily, builds the project, and uploads the manifest to an S3 bucket.

Step 2: Configure Your CI Job to Use the Manifest

Create a new workflow that triggers on pull requests. This job downloads the production manifest and runs a slim build.

Here is a complete GitHub Actions YAML template ready to use.

This workflow does several important things:

• Triggers on pull requests to the main branch.
• Downloads the manifest.json from S3 into a local prod_artifacts directory.
• Runs SQLFluff to lint SQL files, catching style issues early—a recommended best practice.
• Executes the “magic command,” dbt build –select state:modified+ –defer –state ./prod_artifacts, which intelligently builds and tests only the necessary models.

For detailed technical information, see the official dbt documentation.

Starting with dbt v1.8, you can use the –empty flag for extra optimization.

What is the –empty Flag?

This flag allows a dbt command to succeed with a warning (instead of error) if selectors find no models to run.

Why Use It in CI?

If a developer changes only a README or comments in a .yml file, state:modified+ may return no models to build. Without –empty, dbt build would fail, causing the CI job to fail unnecessarily.

This is excellent for governance-only jobs that check for changes before running builds.

Example command:

dbt ls –select state:modified+ –empty

If models are found, the build continues. If none are found, the job passes with a warning and saves time.

Setting up a basic Slim CI pipeline is a significant improvement. But as organizations grow, managing such solutions manually can become challenging. Issues like artifact versioning, stale manifests if production jobs fail, and monitoring CI performance arise.

These common challenges include:

• Managing artifacts reliably at scale.
• Monitoring CI performance and costs.
• Handling complex edge cases and ensuring pipeline stability.

Instead of spending valuable engineering time on complex CI scripts, we offer a better solution. Our Stellans Analytics CI/CD Optimization service provides managed, production-ready CI/CD pipelines for dbt projects. We deliver battle-tested pipelines with governance, observability dashboards, and expert support for edge cases.

If you’re tired of complexity, schedule a demo to see how Stellans can optimize your dbt workflows in days, not months.

For any analytics team serious about scaling dbt projects, implementing Slim CI is essential, not just optional. By shifting from full builds to intelligent state-based builds, you create a highly efficient development lifecycle.

The main takeaways:

• Slim CI transforms your workflow: It builds only changed models, greatly improving performance.
• The benefits are concrete: You get faster builds, lower warehouse costs, and more productive developers.
• Implementation is within reach: Using tools like GitHub Actions and this guide, you can build a strong pipeline.

Follow these steps to reclaim lost time and empower your team to deliver real value from data.

What is dbt Slim CI and how does it work?

dbt Slim CI builds and tests only modified dbt models and their dependencies, not the entire project. It compares the current pull request state to a production manifest to identify exactly what needs validation, resulting in faster, cheaper CI jobs.

What are the benefits of using dbt slim build in CI?

The main benefits include a dramatic reduction in CI job duration (often over 90%), lower compute costs from processing fewer models, and a faster feedback loop that boosts developer productivity and confidence.

How do you configure GitHub Actions to use dbt slim CI?

Configure a workflow that triggers on pull requests. Key steps:

• Download the production manifest.json artifact from storage like S3.
• Run the build with: dbt build –select state:modified+ –defer –state <path_to_manifest>.

This instructs dbt to build only modified models by comparing with production state.