THE DATA CATALOG
dbt docs, taught to see past one adapter. Where stock dbt catalogs only the default target, dvt docs generate walks every connection in your profile — Postgres, Oracle, Snowflake, buckets, all of them — and produces one catalog: every model, source and column, engine-stamped, with lineage across the whole graph.
Commands
dvt docs generate # build the cross-engine catalog into target/ dvt docs serve # host it on :46101 (standalone works fine) dvt serve # or as part of the suite
dvt docs serveis fully supported standalone — dbt parity is a promise, not a suggestion. The ⌂ HUB button in the navbar probes the hub and only appears when it's actually running, so a standalone catalog shows no dead chrome.
What you get
- engine-stamped columns — every relation is cataloged from its own engine's information schema — types as the engine reports them, across all your connections at once.
- cross-engine lineage — the graph doesn't stop at an engine boundary: a gold model on Databricks traces back through DuckDB compute to its Postgres and MySQL sources.
- model and source docs — descriptions from your yml files, rendered exactly as dbt users expect — this is still the dbt docs experience underneath.
- one theme with the suite — light and dark follow the same cookie as the hub, portal and scheduler — toggle once, every app agrees. The light mode is the calm grey pair, never white.
Good to know
- regenerate after structural changes — renames, new models, new connections — dvt docs generate refreshes the catalog; the api-portal and the catalog both read its output.
- the navbar names the app — the catalog says DATA CATALOG; the full product name lives on the hub — each app names itself.
- read-only by design — the catalog never writes anything anywhere; it's safe to expose internally when your team needs shared documentation (see the enterprise page for the hosting posture).