---
title: "Advanced CI"
source: dbt Core Documentation
source_url: https://github.com/dbt-labs/docs.getdbt.com
licence: Apache-2.0
domain: data-and-analysis
subdomain: dbt-docs
date_added: 2026-04-25
---

import CompareChangesTable from '/snippets/_compare-changes-table.md';

# Advanced CI <Lifecycle status="managed,managed_plus" />

[Continuous integration workflows](/docs/deploy/continuous-integration) help increase the governance and improve the quality of the data. Additionally for these CI jobs, you can use Advanced CI features, such as [compare changes](#compare-changes), that provide details about the changes between what's currently in your production environment and the pull request's latest commit, giving you observability into how data changes are affected by your code changes. 

By analyzing the data changes that code changes produce, you can ensure you're always shipping trustworthy data products as you're developing. 

:::info How to enable this feature

You can opt into Advanced CI in <Constant name="dbt" />. Please refer to [Account access to Advanced CI features](/docs/cloud/account-settings#account-access-to-advanced-ci-features) to learn how enable it in your <Constant name="dbt" /> account.

:::

## Prerequisites
- You have a <Constant name="dbt" /> Enterprise or Enterprise+ account.
- You have [Advanced CI features](/docs/cloud/account-settings#account-access-to-advanced-features) enabled.
- You use a supported data platform: BigQuery, Databricks, Postgres, Redshift, or Snowflake. Support for additional data platforms coming soon.

## Compare changes feature {#compare-changes}

For [CI jobs](/docs/deploy/ci-jobs) that have the [**dbt compare** option enabled](/docs/deploy/ci-jobs#set-up-ci-jobs), <Constant name="dbt" /> compares the changes between the last applied state of the production environment (defaulting to deferral for lower compute costs) and the latest changes from the pull request, whenever a pull request is opened or new commits are pushed.  1

You can also compare changes in development. For more details, see [Compare changes in local development]

dbt reports the comparison differences in:

- **<Constant name="dbt" />** &mdash; Shows the changes (if any) to the data's primary keys, rows, and columns in the [Compare tab](/docs/deploy/run-visibility#compare-tab) from the [Job run details](/docs/deploy/run-visibility#job-run-details) page. 
- **The pull request from your <Constant name="git" /> provider** &mdash; Shows a summary of the changes as a <Constant name="git" /> comment.

<Lightbox src="/img/docs/dbt-cloud/example-ci-compare-changes-tab.png" width="55%" title="Example of the Compare tab" />

#### Compare changes in development

You can compare changes locally in development to preview data changes caused by your local edits (for example, added/removed rows or joins) directly in your editor, and without waiting on CI. Compare changes in development is available through the dbt VS Code extension, which is powered by the <Constant name="fusion_engine"/>.

For more details on how to use this feature, see [Compare changes in local development](/docs/fusion/vs-compare-changes).

<Expandable alt_header="Differences between compare changes in development and Advanced CI compare changes">

<CompareChangesTable />

</Expandable>

### Optimizing comparisons

When an [`event_time`](/reference/resource-configs/event-time) column is specified on your model, compare changes can optimize comparisons by using only the overlapping timeframe (meaning the timeframe exists in both the CI and production environment), helping you avoid incorrect row-count changes and return results faster.

This is useful in scenarios like:
- **Subset of data in CI** &mdash; When CI builds only a [subset of data](/best-practices/best-practice-workflows#limit-the-data-processed-when-in-development) (like the most recent 7 days), compare changes would interpret the excluded data as "deleted rows." Configuring `event_time` allows you to avoid this issue by limiting comparisons to the overlapping timeframe, preventing false alerts about data deletions that are just filtered out in CI.
- **Fresher data in CI than in production** &mdash; When your CI job includes fresher data than production (because it has run more recently), compare changes would flag the additional rows as "new" data, even though they’re just fresher data in CI. With `event_time` configured, the comparison only includes the shared timeframe and correctly reflects actual changes in the data.

<Lightbox src="/img/docs/deploy/apples_to_apples.png" width="90%" title="event_time ensures the same time-slice of data is accurately compared between your CI and production environments." />

## About the cached data

After [comparing changes](#compare-changes), <Constant name="dbt" /> stores a cache of no more than 100 records for each modified model for preview purposes. By caching this data, you can view the examples of changed data without rerunning the comparison against the data warehouse every time (optimizing for lower compute costs). To display the changes, <Constant name="dbt" /> uses a cached version of a sample of the data records. These data records are queried from the database using the connection configuration (such as user, role, service account, and so on) that's set in the CI job's environment. 

You control what data to use. This may include synthetic data if pre-production or development data is heavily regulated or sensitive. 

- The selected data is cached on dbt Labs' systems for up to 30 days. No data is retained on dbt Labs' systems beyond this period.
- The cache is encrypted and stored in an Amazon S3 or Azure blob storage in your account’s region. 
- dbt Labs will not access cached data from Advanced CI for its benefit and the data is only used to provide services as directed by you. 
- Third-party subcontractors, other than storage subcontractors, will not have access to the cached data.

If you access a CI job run that's more than 30 days old, you will not be able to see the comparison results. Instead, a message will appear indicating that the data has expired.

<Lightbox src="/img/docs/deploy/compare-expired.png" width="60%" title="Example of message about expired data in the Compare tab" />

## Connection permissions

The compare changes feature uses the same credentials as the CI job, as defined in the CI job’s environment. The <Constant name="dbt" /> administrator must ensure that client CI credentials are appropriately restricted since all customer's account users will be able to view the comparison results and the cached data.

If using dynamic data masking in the data warehouse, the cached data will no longer be dynamically masked in the Advanced CI output, depending on the permissions of the users who view it. dbt Labs recommends limiting user access to unmasked data or considering using synthetic data for the Advanced CI testing functionality.

<Lightbox src="/img/docs/deploy/compare-credentials.png" width="60%" title="Example of credentials in the user settings" />

## Troubleshooting

<Expandable alt_header="Compare changes CI models need to be on same database host/connection">

Compare Changes only works if both CI and production models live on the same database host/connection. Compare Changes runs SQL queries in the current CI job’s environment to compare the CI model (like `ci.dbt_cloud_123.foo`) to the production model (`prod.analytics.foo`).

If the CI job defers to a production job that's on a different database connection or host, then the compare changes feature will not work as expected. This is because the CI environment can't access or query production objects on another host. 

In the following example, the CI job can’t access the production model to compare them because they’re on different database hosts:

  - The dbt CI job in environment `ci.dbt_cloud_123.foo` that connects to host `abc123.rds.amazonaws.com`
  - The dbt production job in environment `prod.analytics.foo` that connects to host `def456.rds.amazonaws.com`

</ Expandable>
