sources/ in your project directory.
Table sources
Point at an existing table or view in your warehouse:__source("raw_events").
Expression sources
Define source data inline as a SQL expression. No external tables or setup scripts needed:Source audits
Sources support the same audit system as models. Audits attached to sources run before any dependent model is built:error severity fails, all downstream models that depend on that source are blocked.
Type enforcement
Type enforcement is implicit for sources, the same as for models. If any column declares atype, SQLBuild automatically casts that column and uses declared types for schema-change detection:
id has a type declared, so only id is cast. Columns without a type are passed through unchanged.
For expression sources, SQLBuild probes the expression’s output columns and builds a projection that casts typed columns while preserving the rest. For table sources, it uses warehouse metadata to validate that declared column names exist and applies casts accordingly.
You can explicitly set type_enforcement: false on a source to disable casting even when column types are declared.
Managed sources (loaders)
Sources can be loaded by Python functions instead of pointing at existing tables or inline expressions. Setmanaged: true to bind a source to the @loader function of the same name, and SQLBuild will call it to populate the source table:
table, append, delete_insert, merge), cursor-based loading, and concurrent execution.
See Loaders for the full guide on writing loader functions, write strategies, the loader context API, and auto-load behavior during builds.
Declarative integrations (no Python)
For common ingestion you can declare the source entirely in YAML, with no@loader function. SQLBuild generates the loader for you and runs it during the build:
- dlt - declare
dlt_sourcesforrest_api,sql_database, andfilesystemsources. - ingestr - add an
ingestrblock to a source to pull from 50+ sources.
Source freshness
Source freshness lets SQLBuild observe whether a source’s data has changed between runs. This feeds into planning and change detection: under--changes-only, models downstream of unchanged sources are skipped.
Configure freshness per source with a freshness: block:
Strategies
adapter
type, column, or query.
column
MAX(column) from the source table. The column must be a plain column name (no expressions; use sql strategy for those). Requires type.
sql
type. Does not support column.
Type
Thetype field declares the value kind for comparison:
Lag tolerance
lag_tolerance is optional and only valid with type: timestamp. It declares how much the observed timestamp can drift from the previous observation before being treated as a change:
15m (minutes), 2h (hours), 1d (days). If the current observation is within the tolerance of the previous one, the source is treated as unchanged.
Auto-observation
Sources without an explicitfreshness: block are auto-observed using the adapter strategy if:
- The source has a physical table (not an expression source)
- The source is not managed
- The adapter supports table freshness metadata
sqb freshness to observe source freshness on demand without triggering a build. See Source freshness for how freshness feeds into change-aware builds.

