sqt rename-project

Preview a project rename for the selected target:

sqt rename-project storefront
sqt rename-project storefront --target prod

The default is a dry run. It prints the configuration edit, the Kafka consumer groups that stay the same, the number of manifests to copy and the number of project role assignments to move, and writes nothing to the warehouse or the project config. As with every command, a few legacy migrations can still run: connecting renames legacy _streambuild_* metadata tables to _sqltide_*, opening a configured control store that has never been initialized creates its tables, and a legacy .streambuild/ state directory is moved to .sqltide/.

Apply the rename explicitly:

sqt rename-project storefront --apply

--apply does not prompt. It runs these steps in order:

1. Copies the target’s manifest history from the old name to the new one under the target mutation lock, so sqt destroy keeps finding relations recorded before the rename.
2. Moves project role assignments, active and revoked, from the old name to the new one in the control store.
3. Edits sqltide_project.toml in place: sets name and, when a managed Kafka source uses the default consumer group, adds consumer_group_identity set to the old name. Comments and formatting are kept.

The configuration is edited last, so a failure leaves the old name working, and running the same command again completes the rename. Steps that already ran are not repeated: manifests already copied are skipped and assignments already moved are not moved again.

The command refuses to run when:

• the new name equals the current name, is empty or blank-padded, or contains ${
• a build or other run holds the target mutation lock
• the target already records manifests for the new name that did not come from the old name
• both names hold the same active role assignment for the same user, role and target scope
• the rename would change any Kafka consumer group
• a managed Kafka table on the target already consumes as a different consumer group than the project declares, which sqt plan reports as consumer group drift; resolve that first, for example by restoring the name or consumer_group_identity the live tables were created with

Options

Option	Purpose
NEW_NAME	The new project name
--apply	Apply the rename; without it the command is a dry run
--from OLD_NAME	Complete a rename on another target after sqltide_project.toml already carries NEW_NAME
--target	Named project target whose warehouse history is copied
--database	Target database override
--control-store-url	Account control store; defaults to SQLTIDE_CONTROL_STORE_URL, then the project’s .sqltide/control.db when it exists
--project-dir, --host, --port, --username, --password, --vars	As for other commands

Projects with several targets

Each target has its own warehouse, and usually its own UI host and control store. The first run renames the project on one target and edits the configuration; every other target then completes the rename with --from:

1. On one target, rename and commit the configuration change:

   sqt rename-project storefront --target dev --apply

2. On each other target, typically on that target’s own host so its control store is used, complete the rename from the committed configuration:

   sqt rename-project storefront --from shop --target prod
   sqt rename-project storefront --from shop --target prod --apply

With --from, the command leaves sqltide_project.toml unchanged. It checks that the target’s Kafka consumer groups stay the same, copies the target’s manifest history from OLD_NAME, and moves the control store’s role assignments from OLD_NAME, under the same lock, dry-run default, conflict rules and idempotence as the first run. The target may already have been built under the new name: its own new manifests are kept and the old history is merged in, so sqt destroy sees both. It refuses when NEW_NAME is not the name the configuration carries, when the configuration is still named OLD_NAME (run without --from first), when OLD_NAME equals the new name, when nothing on the target records OLD_NAME (a mistyped name, or a target never built under it with no grants in this control store), or when the history of OLD_NAME does not look like this project’s: a consumer_group_identity that differs from OLD_NAME, or a newest OLD_NAME manifest that shares no pipeline with the project. The last check keeps another project’s history in the same database from being merged in, where sqt destroy would treat its pipelines as retired ones of this project.

Until a target is completed, it keeps its manifest history under the old name, so sqt destroy there does not see relations recorded before the rename. The first run’s output lists the targets still to complete.

Role assignments move for the whole control store a run uses. When several targets share one control store, the first run moves every target’s grants, and UI users of targets still running the old configuration lose those grants until the targets get the renamed configuration. Role assignments are keyed by project name only, so two projects with the same name in one shared control store cannot be told apart.

Restart a running sqt dev server after a rename. See Renaming a project for what a rename changes.