Versioning

Models maintain a version history of the SQL code that defines them, giving you full lineage from a Job Run back to the specific code change that produced it.

How Versioning Works

Every change made to the flow in the Workbench creates a new version of the Project. You can review the change history via the Project History interface:

Versions are tracked at the Project level. A Model Job is tagged when the Model is deployed or re-deployed. The tag pins the Model Job to the specific version of the Project, enabling full lineage tracing and the ability to run multiple different tagged versions of a Model using different Model Jobs.

Version Tags

The first deployment creates an auto-generated tag. Subsequent re-deployments prompt you to enter a meaningful tag. Tags can follow any naming convention that suits your team's workflow, for example:

• A date-based release label: 2026.1
• A descriptive fix label: bugfix-bad-date-fmt
• A sprint or ticket reference: sprint-42

Using Tags Across Environments

When a Model is deployed into multiple environments, each Job can be pinned to a specific tag. This allows different environments to run different versions of the same Model simultaneously — for example, production continues running a stable tagged version while development moves to a newer one.