event_time

Available in dbt Cloud Versionless and dbt Core v1.9 and higher.

Models

dbt_project.yml

models:
  resource-path:
    +event_time: my_time_field

models/properties.yml

models:
  - name: model_name
    config:
      event_time: my_time_field

models/modelname.sql

{{ config(
    event_time='my_time_field'
) }}

Seeds

dbt_project.yml

seeds:
  resource-path:
    +event_time: my_time_field

seeds/properties.yml

seeds:
  - name: seed_name
    config:
      event_time: my_time_field

Snapshots

dbt_project.yml

snapshots:
  resource-path:
    +event_time: my_time_field

Sources

dbt_project.yml

sources:
  resource-path:
    +event_time: my_time_field

models/properties.yml

sources:
  - name: source_name
    config:
      event_time: my_time_field

Definition

Set the event_time to the name of the field that represents the timestamp of the event, as opposed to a date-like data loading date. You can configure event_time for a model, seed, or source in your dbt_project.yml file, property YAML file, or config block.

Here are some examples of good and bad event_time columns: ✅ Good:

• account_created_at — This represents the specific time when an account was created, making it a fixed event in time.
• session_began_at — This captures the exact timestamp when a user session started, which won’t change and directly ties to the event.

❌ Bad:

• _fivetran_synced — This isn't the time that the event happened, it's the time that the event was ingested.
• last_updated_at — This isn't a good use case as this will keep changing over time.

event_time is required for Incremental microbatch and Advanced CI's compare changes in CI/CD workflows, where it ensures the same time-slice of data is correctly compared between your CI and production environments.

When you configure event_time, it enables compare changes to:

• Compare data in CI versus production for overlapping times only, reducing false discrepancies.
• Handle scenarios where CI has "fresher" data than production, by using only the overlapping timeframe, allowing you to avoid incorrect row-count changes.
• Accounts for subset data builds in CI without flagging filtered-out rows as "deleted" when compared with production.

Examples

Models

Here's an example in the dbt_project.yml file:

dbt_project.yml

models:
  my_project:
    user_sessions:
      +event_time: session_start_time

Example in a properties YAML file:

models/properties.yml

models:
  - name: user_sessions
    config:
      event_time: session_start_time

Example in sql model config block:

models/user_sessions.sql

{{ config(
    event_time='session_start_time'
) }}

This setup sets session_start_time as the event_time for the user_sessions model. This makes sure the compare changes process uses this timestamp for time-slice comparisons or incremental microbatching.

Seeds

Here's an example in the dbt_project.yml file:

dbt_project.yml

seeds:
  my_project:
    my_seed:
      +event_time: record_timestamp

Example in a seed properties YAML:

seeds/properties.yml

seeds:
  - name: my_seed
    config:
      event_time: record_timestamp

This setup sets record_timestamp as the event_time for my_seed. It ensures that the record_timestamp is used consistently in Advanced CI's compare changes or incremental microbatching.

Sources

Here's an example of source properties YAML file:

models/properties.yml

sources:
  - name: source_name
    tables:
      - name: table_name
        config:
          event_time: event_timestamp

This setup sets event_timestamp as the event_time for the specified source table.