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:sources/. Declarations limited to one source folder are not available in sibling folders.
See How Visibility Works.
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. If any column declares atype, SQLBuild activates source type enforcement, casts that column during source resolution, 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 changed between runs. This feeds into planning and change detection: changed observations propagate to downstream models and can alter their planned action. Virtual environments can also use the signal for stale-driven execution. Configure freshness per source with afreshness: 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.

