Skip to main content

Atlas Catalog

A server-indexed, searchable documentation browser for every model, source, seed, snapshot, exposure, metric, macro, and analysis in your dbt project. Browse descriptions, columns, tests, lineage, compiled SQL, warehouse stats, and coverage scores - all without downloading multi-MB manifest files.

The catalog is organized into four tabs:

  • Overview - your project's landing page, built from the __overview__ doc block
  • Browse - a searchable, filterable list of every node with a detail pane
  • Graph - a full, zoomable whole-project lineage DAG
  • Coverage - animated scorecards showing documentation and test coverage gaps
Atlas Catalog8 entries indexed
Search nodes...
dim_customersModel
fct_ordersModel
stg_paymentsModel
raw_ordersSource
weekly_revenueExposure
revenue_per_customerMetric
cents_to_dollarsMacro
ad_hoc_cohortAnalysis
dim_customers
Customer dimension with lifetime stats
HealthyLast run passed
12
Columns
8
Tests
92%
Coverage
Documentation coverage0%
Downstream
fct_orders

Why Atlas Catalog

Challenge with other toolsHow Atlas Catalog solves it
dbt docs serve requires downloading the full manifest to the browser, which is slow for large projectsServer-indexed: only the slice you need is fetched, so browsing is instant even for 5,000+ node projects
Only models and sources get docs pages; exposures, metrics, and macros are invisibleAll eight node types get first-class pages with type-specific detail views
No project-level landing page unless you view the raw __overview__ blockA dedicated Overview tab renders your project's doc block as a polished landing page
No whole-project lineage graph without downloading and parsing the full manifestA zoomable DAG graph is rendered server-side and viewable in both the catalog and the shared docs portal
Documentation coverage is invisible until someone runs a manual auditCoverage scorecard with animated rings shows doc/test gaps at a glance, broken down by schema and type
Fixing documentation gaps means switching to a code editor, writing YAML, re-generating docsOne-click "Document with Atlas" sends the undocumented model to Atlas AI for instant doc generation
Column lineage requires separate tooling or is unavailable entirelyColumn-level lineage is built into the node detail pane, computed on demand from compiled SQL
Docs go stale because they only reflect parse-time metadataWarehouse-aware metadata (real types, row counts, storage, source freshness) is ingested after every run
Sharing docs externally requires granting platform accessShare docs via tokenized links with public, password, or SSO access gates - no login needed for recipients

Project Overview

The Overview tab is the landing page for your project's catalog. If your dbt project includes a {% docs __overview__ %} block, its content is rendered here as formatted markdown with any nested {{ doc() }} references already resolved.

When no overview block exists, a summary card shows your project's total entry count and doc-block count so the page is never blank.

To add an overview, create a __overview__ doc block in any of your dbt project's docs files.

Searchable Node Index

The Browse tab lists every node with type-colored indicators:

  • Models, Sources, Seeds, Snapshots - your core data assets
  • Exposures - dashboards, notebooks, and ML applications
  • Metrics - semantic-layer metric definitions
  • Macros - reusable Jinja functions with arguments and source
  • Analyses - ad-hoc analytical queries

Full-text search filters the list as you type. A labeled, collapsible filter panel keeps the controls organized instead of a wall of unlabeled dropdowns, and lets you narrow the list by:

  • Type (model, source, test, semantic model, and the rest)
  • Schema and database
  • Layer: staging, intermediate, or marts
  • Health: healthy, caution, degraded, or unknown, each with a live count
  • Documentation and test status

The stats band at the top shows totals by type with animated coverage rings. Tests and semantic models are first-class, browsable entries alongside models and sources.

Click any node to open its detail pane.

Node Detail Pane

Each node's detail view shows:

Description and Metadata

  • Node description (from your YAML or schema files)
  • Materialization type, schema, database, and tags
  • Package name and file path

Columns

A sortable table of every column with:

ColumnSource
NameManifest
dbt typeManifest (parse-time)
Warehouse typecatalog.json (actual type in the database, e.g., NUMBER(38,0))
DescriptionManifest
TestsInline chips showing attached generic tests (not_null, unique, etc.)
Positioncatalog.json (ordinal position in the relation)

Warehouse Stats

After a dbt docs generate run, the detail pane shows live warehouse metadata:

  • Row count and storage size (bytes)
  • Adapter-specific extras (clustering key, last modified, partitioning) displayed as label-value pairs
  • These fields update automatically after every run, so your docs never go stale

Source Freshness

For source nodes, the detail pane shows:

  • Last loaded at timestamp
  • Freshness status (pass, warn, error) with a visual staleness indicator
  • Criteria (warn-after and error-after thresholds)
  • Freshness data comes from dbt source freshness runs and updates automatically

The catalog always overlays the latest freshness result for each source, drawn from your most recent scheduled or on-demand freshness check. You do not have to hunt for the run that produced it. Whenever a job checks source freshness, the catalog reflects the new status.

Compiled SQL

View the rendered SQL for any model, with syntax highlighting. Useful for understanding what dbt actually sends to your warehouse after resolving refs, macros, and Jinja.

Lineage

Model-level upstream and downstream dependencies are shown inline. Click any linked node to navigate to its detail view.

Exposure Details

Exposure nodes display type-specific fields:

  • Type (dashboard, notebook, ML model, application)
  • URL linking to the external asset
  • Maturity level
  • Owner name and email
  • Dependent models listed as upstream lineage

Metric Details

Metric nodes show:

  • Metric type and label
  • Expression (the calculation formula)
  • Filter conditions
  • Upstream semantic model linkage

Macro Details

Macro nodes include:

  • Arguments table with name, type, and description for each declared argument
  • Macro source - the full Jinja body with syntax highlighting

Governance Metadata

When your project uses dbt's governance features, the detail pane surfaces them so consumers know how a model is meant to be used:

  • Contract - a badge when the model declares an enforced contract, signalling that its column names and types are guaranteed
  • Access - the model's access level (public, protected, or private), so it is clear which models are safe for other teams to reference
  • Group - the owning group a model belongs to
  • Version - the model version, with an "outdated" indicator when a newer version exists so you can steer consumers to the latest one
  • Deprecation date - a clear sunset date when a model is scheduled to be retired

These fields stay hidden for models that do not use governance, so the pane stays clean for everyone else.

Project DAG Graph

The Graph tab renders a full, zoomable whole-project lineage graph. Unlike dbt docs serve, the graph layout is computed server-side from the ingested manifest, so the browser never parses multi-MB artifacts.

Key capabilities:

  • Longest-path layered layout - nodes flow left to right, grouped by dependency depth
  • Zoom, pan, and minimap - navigate large graphs with standard controls
  • Search - find and center any node by name
  • Type-colored nodes - each node type has a distinct color matching the Browse list
  • Click-to-inspect - clicking a node opens its full detail pane inline beside the graph, without navigating away
  • Shared portal support - the same graph is available in the no-login docs portal via share links

When a project is too large, the graph shows the closest neighbors and displays a "showing N of M nodes" indicator.

Focused Lineage

Instead of taking in the whole graph at once, focus on a single node's neighborhood. Pick a node as the anchor and choose how many hops of upstream and downstream lineage to show. The graph redraws to just that neighborhood, so tracing how one model connects to its sources and consumers stays readable even in a large project. Focus mode works the same way on the authenticated graph and in the no-login docs portal.

Hide-Layer Filters

Large graphs often carry layers you do not need in a given view. Hide-layer filters let you exclude nodes by tag, file path, schema, or type so the graph shows only what is relevant. For example, hide staging models to see just marts, or hide tests to focus on data flow. You can also multi-select specific models to hide, or use Hide this model directly on a node to drop it from the view without building a filter expression. The filters apply in both Browse and Graph, and are carried into share links, so a link opens with exactly the view you curated.

Model Health, Performance, and Recommendations

Each model carries an at-a-glance health verdict so you can spot trouble without opening every node:

  • A colored dot marks each model healthy (green), caution (amber), degraded (red), or unknown (gray)
  • The last run status is shown inline, so you know whether a model built cleanly on its most recent run
  • Health counts appear in the filter panel, so you can jump straight to everything that needs attention

Open a model to see its performance history: the execution time of each recorded run, so you can see whether a model is trending slower over time and catch a regression before it becomes a problem.

Where dbdeux can suggest an improvement (for example a missing test, an absent description, or a model that has been slow across recent runs), it surfaces a recommendation on the node, turning the catalog from a passive reference into an active checklist for keeping your project healthy.

Custom References (Annotations)

Attach arbitrary metadata to any catalog node or individual column. References are user-curated attributes that live outside your git-managed schema YAML, so anyone on the team can add context without opening a pull request.

stg_customers - References
Object References
Requirement Link🔗jira.example.com/browse/DATA-1234link
Data Owneranalytics-eng@company.comtext
SLARefreshed daily by 06:00 UTCtext
+ Add reference

Column References
ColumnLabelValueType
customer_idPIIContains personal identifiertext
emailClassificationwiki.example.com/data-classification#emaillink

How it works

  • Click Add reference on any node's detail pane to create a new label-value pair
  • Pick a value type so the reference renders correctly:
    • Link: a clickable URL (e.g., a Jira ticket, wiki page, or dashboard)
    • Email: a click-to-mail address for the owner or on-call contact
    • Date: a formatted date (e.g., a review or deprecation date)
    • Code: monospace text for identifiers like a ticket key or commit SHA
    • Text: plain notes
  • Add free-form tags to group and categorize references
  • Search and filter references by label, value, or tag to find them quickly on busy nodes
  • Each reference shows its provenance: who added it and when
  • References are scoped per project and tied to the node's unique identifier, so they survive manifest re-ingestion
  • Column-level references work the same way: in the columns table, each column has its own "Add" control

Common uses

LabelTypeExample value
Requirement LinkLinkhttps://jira.example.com/browse/DATA-1234
Data OwnerTextanalytics-eng@company.com
SLATextRefreshed daily by 06:00 UTC
PII ClassificationLinkhttps://wiki.example.com/data-classification
Deprecation NoticeTextReplaced by stg_customers_v2 after Q3

References are visible to anyone browsing the catalog (including via share links in read-only mode) and editable by any project member with write access.

Column-Level Lineage

For each output column of a model, Atlas Catalog traces which upstream columns it derives from. The lineage is computed on demand from the model's compiled SQL using dialect-aware parsing, so it works across all supported warehouses.

This helps with:

  • PII tracking: Follow sensitive columns through your entire pipeline
  • Impact analysis: Know exactly which output columns are affected when you rename or remove an upstream column
  • Debugging: When a metric looks wrong, trace the specific column back to its source

If parsing is incomplete (e.g., complex dynamic SQL), partial results are shown with an "approximate" indicator rather than failing.

Coverage Scorecard

The coverage view provides three animated ring charts showing your project's documentation health:

  • Node documentation % - what fraction of models/sources have descriptions
  • Node test % - what fraction have at least one test
  • Column documentation % - what fraction of columns across all nodes have descriptions

Breakdown by Schema or Type

Below the rings, a per-slice breakdown shows dual progress bars (documentation and testing) for each schema or resource type. This makes it easy to spot which corner of your project needs attention.

Gap Lists

Drill into three categories:

  • Undocumented - nodes with no description at all
  • Partially documented - nodes that have descriptions but some columns lack them
  • Untested - nodes with zero tests

Each row includes a "View" link to jump to the node and a "Document with Atlas" button that sends the node to Atlas AI for one-click documentation generation.

Ask Atlas in the Catalog

Atlas is available directly inside the catalog. Open the chat panel from a node and ask questions grounded in that exact node: what a model does, where a column comes from, what depends on it, or how to document it. A visible context chip shows which node the conversation is grounded in, so you always know what Atlas is reasoning about, and it never silently answers about the wrong model. The chat is scoped to the catalog's selected project, so answers stay grounded in the project you are actually browsing.

When you use Document with Atlas on an undocumented model, it opens this in-catalog panel and generates a description without sending you to the editor. The generated documentation is written back into a shared, folder-level schema file (_<folder>_models.yml) so a folder's models are documented together in one place, rather than scattering a separate YAML file next to every model.

Sharing Catalog Docs

Share your project's documentation externally with stakeholders who do not have a platform account:

Access Modes

ModeHow it works
PublicAnyone with the link can view (default)
PasswordViewer enters a passphrase once; only its hash is stored
SSOOnly signed-in members of your organization can access

Email Sharing

After generating a link, use the built-in email composer to send it directly to stakeholders. The email includes a branded template with a direct link to the docs portal.

Docs Portal

Recipients see a read-only documentation portal with the full catalog: searchable node list, descriptions, columns, tests, and lineage. No login required for public and password-gated links. Any focused-lineage view and hide-layer filters you set are preserved in the link, so recipients open the exact view you intended.

Share links resolve correctly for projects that live in a shared workspace, so a catalog you share from an organization workspace opens for its intended audience rather than failing to authorize.

How It Compares

CapabilityAtlas Catalogdbt docs / ExplorerOther tools
Browsing speedInstant (server-indexed, paginated)Slow for large projects (full manifest download)Varies
Node type coverageAll 8 types: models, sources, seeds, snapshots, exposures, metrics, macros, analysesModels and sources onlyVaries
Project overviewRendered __overview__ doc block with resolved refsRaw markdown blockNot available
Whole-project DAGServer-rendered, zoomable, with inline detail paneClient-rendered (downloads full manifest)Separate tools
Coverage scoringBuilt-in with animated scorecards and gap listsNot availableRequires separate tooling
One-click doc fix"Document with Atlas" sends to AI for instant generationManual YAML editingManual
Column lineageBuilt-in, dialect-aware, on demandNot available in dbt docsSeparate paid tools
Warehouse metadataRow counts, storage, types, freshness - auto-updatedRequires separate dbt docs generate and manual viewingVaries
External sharingTokenized links with public/password/SSO gates, including overview and graphNot availableRequires platform access
Freshness trackingInline staleness indicator with pass/warn/errorSeparate dbt source freshness commandSeparate monitoring
Custom referencesAttach arbitrary label-value annotations (links, text) to any node or columnNot available