What dtm manages — and what it doesn't

dtm manages schemas, tables, and columns. It does not manage catalogs themselves.

Catalogs are a pre-condition, not a deliverable

Every catalog you reference in your project must already exist in the target workspace before dtm runs. dtm will never emit CREATE CATALOG, ALTER CATALOG, or DROP CATALOG statements.

Why

Catalog operations in Unity Catalog typically require elevated permissions (account admin or metastore admin) and have organisation-wide impact: storage roots, governance, lineage, access control. Putting them under dtm would either fail at runtime for most users or quietly take actions with wide blast radius. They're deliberately out of scope.

What this means for your project

• project.yaml declares the catalogs your project uses under targets.<target>.databases. These are pre-existing names — dtm doesn't create them.
• SQL files in your project's sql/ folder must only contain CREATE SCHEMA and CREATE TABLE (and equivalents). Do not add CREATE CATALOG files; they have no effect and will be flagged by parser warnings.
• dtm compare ignores catalog-level differences. If your statefile or live database has catalogs that aren't in the solution (or vice versa), no diff is emitted at the catalog level. Differences inside those catalogs (schemas, tables, columns) are still surfaced.

What dtm does manage

Object	Operations
Schema	CREATE, DROP
Table	CREATE, DROP
Column	ADD, DROP, ALTER (type, nullability, comment, default, ...)

Renames are intentionally not detected in v1 — a renamed object surfaces as Removed followed by Added.