Skip to main content

volatility

💡Did you know...
Available from dbt v1.11 or with the dbt "Latest" release track.
functions/<filename>.yml
functions:
- name: <function name>
config:
volatility: deterministic | stable | non-deterministic

Definition

You can optionally use the volatility config for SQL or Python UDFs to describe how predictable the function output is by using deterministic, stable, or non-deterministic. Warehouses use this information to decide if results can be cached, reordered, or inlined. Setting the appropriate volatility helps prevent incorrect results when a function isn’t safe to cache or reorder.

For example:

  • A function that returns a random number (random()) should be set as non-deterministic because its output changes every time it’s called.
  • A function that returns today’s date (current_date()) is stable; its value remains consistent within a single query execution but may change between queries. If it were configured as deterministic, a warehouse might incorrectly cache the value and reuse it on subsequent days.

By default, dbt does not specify a volatility value. If you don’t set volatility, dbt generates a CREATE statement without a volatility keyword, and the warehouse’s default behavior applies — except in Redshift.

In Redshift, dbt sets non-deterministic (VOLATILE) by default if no volatility is specified, because Redshift requires an explicit volatility and VOLATILE is the safest assumption.

 Warehouse-specific volatility keywords

Different warehouses show volatility controls with different keywords and default values:

Warehousedeterministicstablenon-deterministic
SnowflakeIMMUTABLENot supportedVOLATILE (default)
RedshiftIMMUTABLESTABLEVOLATILE (default)
DatabricksDETERMINISTICNot supportedAssumed non-deterministic unless declared
PostgresIMMUTABLESTABLEVOLATILE (default)

BigQuery does not support explicitly setting volatility. Instead, BigQuery infers volatility based on the functions and expressions used within the UDF.

Supported volatility types

In dbt, you can use the following values for the volatility config:

ValueDescriptionExample
deterministicAlways returns the same output for the same input. Safe for aggressive optimizations and caching.substr() — Produces the same substring when given the same string and parameters.
stableReturns the same value within a single query execution, but may change across executions. Not supported by all warehouses. For more information, see Warehouse-specific volatility keywords.now() — Returns the current timestamp the moment a query starts; constant within a single query but different across runs.
non-deterministicMay return different results for the same inputs. Warehouses shouldn't cache or reorder assuming stable results.first() — May return different rows depending on query plan or ordering.
random() — Produces a random number that varies with each call, even with identical inputs.

Example

In this example, we're using the deterministic volatility for the is_positive_int function:

functions/schema.yml
functions:
- name: is_positive_int
description: Check whether a string is a positive integer
config:
volatility: deterministic # Optional: stable | non-deterministic | deterministic
arguments:
- name: a_string
data_type: string
returns:
data_type: boolean

Was this page helpful?

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

0