THE DATA CATALOG

PORT :46101 · dvt docs generate + dvt docs serve · READ-ONLY

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 columnsevery relation is cataloged from its own engine's information schema — types as the engine reports them, across all your connections at once.
  • cross-engine lineagethe 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 docsdescriptions from your yml files, rendered exactly as dbt users expect — this is still the dbt docs experience underneath.
  • one theme with the suitelight 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 changesrenames, new models, new connections — dvt docs generate refreshes the catalog; the api-portal and the catalog both read its output.
  • the navbar names the appthe catalog says DATA CATALOG; the full product name lives on the hub — each app names itself.
  • read-only by designthe 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).