Skip to main content

Redis configurations

This page describes how dbt models behave with the community-maintained dbt-redis-adbc adapter. The adapter's Redis ADBC driver presents Redis data as SQL relations named schema.table, in a single catalog named redis. For the general configuration syntax, refer to materializations and incremental models. For installation and connection settings, refer to Redis setup.

Materializations​

Set materialized in a model's config() block or in dbt_project.yml. For the syntax, refer to materializations. The adapter supports these materializations:

MaterializationSupport
tableSQL and Python models
viewSQL models
ephemeralSQL models
incrementalSQL models, using the strategies below
materialized_viewNot supported

Incremental models​

Supported strategies are append, delete+insert, merge, and microbatch. With a unique_key, the default strategy is delete+insert. Without a unique_key, the default appends rows.

For example, use merge to update existing rows and insert new rows:

models/orders.sql
{{ config(
    materialized='incremental',
    incremental_strategy='merge',
    unique_key='order_id'
) }}

select *
from {{ ref('stg_orders') }}
{% if is_incremental() %}
where updated_at >= (select max(updated_at) from {{ this }})
{% endif %}

The adapter also supports on_schema_change and incremental_predicates. For microbatch models, configure event_time, begin, and batch_size using the standard microbatch configuration. Each batch replaces its event-time window; batches can run in parallel.

Model contracts and constraints​

You can enforce model contracts. The driver enforces not_null and check constraints. It accepts primary_key, unique, and foreign_key constraints without enforcing them; dbt warns about those constraints.

Small integer literals have the integer type. In a contract, declare a column such as select 1 as id as integer, or cast the expression to bigint in the model.

Persisted documentation​

Enable persist_docs to store relation and column descriptions through SQL comments:

dbt_project.yml
models:
  PROJECT_NAME:
    +persist_docs:
      relation: true
      columns: true

Python models​

Python models run inside the dbt process and support the table materialization. dbt.ref() and dbt.source() return Arrow tables, loading each input into the process's memory. The session argument exposes the connection for SQL execution. Return an Arrow table or record batch reader, a pandas or polars DataFrame, or an object implementing the Arrow stream interface.

Incremental Python models are not supported.

Relation names and access control​

SQL relations render as schema.table, without the redis catalog. By default, the adapter doesn't quote schema or table names, and the driver folds unquoted identifiers to lowercase, as PostgreSQL does. Double-quoted names keep their exact case. To keep a name's case, enable dbt's quoting configuration for it.

Relations that driver releases earlier than 0.0.16 created with mixed-case names keep those names. Quote their exact names when you reference them, or rename them.

Redis controls access through ACL users, commands, and key patterns. The adapter skips SQL grants configurations with a warning. Configure permissions in Redis instead, following the driver's ACL documentation.

Transactions and interrupted runs​

Every statement autocommits; the driver does not provide SQL transactions or rollback. A failed or cancelled materialization can leave partial writes and __dbt_tmp or __dbt_backup relations. dbt drops those relations at the start of the next run of that model. Account for this behavior when planning recovery from an interrupted run.

For package-specific macro overrides, refer to the adapter repository's package compatibility documentation.

Was this page helpful?

This site is protected by reCAPTCHA and the Google Privacy Policy and Terms of Service apply.

0
Loading