sqt deployment

List, inspect, audit, promote and roll back the deployments that virtual builds create:

sqt deployment list
sqt deployment show --latest
sqt deployment diff --latest
sqt deployment audit --latest
sqt deployment promote --latest
sqt deployment rollback --previous

All commands accept project, target, connection, and --json options. Virtual environments must be enabled.

sqt dev also provides deployment inventory, detail, diff, promotion preview and execution, and retention cleanup. Audit and rollback remain CLI operations.

List and show

deployment list shows every deployment SQLTide recorded and checks each against the tables in ClickHouse. Deployments are reported as active, staged, superseded, incomplete, metadata_missing, or physical_missing. A deployment is incomplete until its build has filled every table, so a build that is still running or that failed, for example because a model raised an error during replay, is incomplete.

deployment show <deployment-id> displays one deployment’s persisted status, roots, physical relations, missing relations, active bindings, and latest publication time. Both operations are read-only.

Diff

deployment diff <deployment-id> compares the active bindings with one retained deployment. deployment diff <from>:<to> compares explicit endpoints, where either endpoint may be active. It reports model presence, schema columns, physical availability, current row counts, and one of added, removed, changed, unchanged, or physical_missing for each logical relation. Diff is read-only.

Audit

deployment audit compares the staged deployment with what consumers read now, checks replay coverage and runs the SQL audits that apply, then reports ready, caution or not_ready:

• ready means the available evidence satisfies the configured checks and no error-severity SQL audit failed.
• caution means evidence is incomplete or warrants operator review.
• not_ready means a stronger negative signal or error-severity SQL audit failure was found.

The command does not accept --select. A successful command exits 0 even when the reported assessment is not_ready.

deployment promote does not check this result and will promote a not_ready deployment. Find out why it is not_ready before you promote it.

Promote

deployment promote points each stable tbl__* view at the deployment’s table. Each view switches atomically, but the views switch one at a time, not all together. It refuses a deployment built on an upstream model version that is no longer published; rebuild that model with sqt build --select <model> and promote the new build. It also refuses an incomplete deployment, by ID or with --latest. When a build fails, fix the failure, run sqt build again, and promote that build.

Rollback

deployment rollback --previous selects the distinct publication immediately before the active binding identity. deployment rollback <deployment-id> selects an explicitly retained publication. Both forms restore the complete set of stable bindings and require confirmation unless --auto-approve is supplied. --json requires --auto-approve.

Rollback only accepts successfully published deployments whose complete physical binding set is still available. If a stable view no longer points where SQLTide last left it, rollback refuses and changes nothing.

Rollback switches definitions and bindings. It is not point-in-time data recovery: retained streaming deployment tables can continue receiving rows after their original publication.

Show, diff, audit and promote take a deployment ID, or --latest for the most recently built deployment. promote --latest refuses when that deployment is already published or when more than one deployment is staged; then pass an ID from deployment list. Rollback takes an ID or --previous. Older deployments remain available for comparison, rollback, diagnosis, repair, and top-level sqt janitor cleanup.