dbt + Data Catalog: Do You Actually Need Both?

If you're an analytics engineer running dbt, you've probably had this conversation with your manager or a vendor: "You should really set up a data catalog." And your immediate reaction was "I already have one — it's called dbt docs generate."

Fair. dbt gives you real catalog features. I wrote about this in depth in dbt vs Atlan — the documentation, the DAG, the tests, the source freshness checks. These are not toy features. For a single dbt project with a small team, they genuinely work as a catalog.

But there's a specific failure mode I keep seeing, and it always starts the same way: someone asks a question that dbt can't answer.

The question dbt can't answer

Here's a real scenario. You maintain fct_monthly_revenue in dbt. It has tests, documentation, column descriptions. Solid model. One day, your data team needs to rename net_revenue to net_revenue_usd for clarity. Simple migration — update the model, update the YAML, run the tests. Green across the board.

Except three Looker dashboards, a Streamlit app, two Jupyter notebooks, and a Salesforce reverse-ETL sync all reference net_revenue by name. dbt has no idea any of those exist. The rename goes out, and you find out about the breakage from an angry VP on Monday morning.

dbt's lineage is model-to-model. It tells you that stg_orders feeds fct_monthly_revenue feeds mart_executive_summary. That's accurate and useful. But it stops at the warehouse boundary. Everything downstream — dashboards, apps, notebooks, syncs — is invisible.

What dbt gives you (and it's more than people credit)

Let's be specific, because dismissing dbt's catalog features would be dishonest:

Schema documentation. schema.yml descriptions are version-controlled, PR-reviewed, and collocated with the transformation logic. This is genuinely better than a wiki page that rots within weeks.

models:
  - name: fct_monthly_revenue
    description: "Monthly revenue by customer segment. One row per segment per month."
    columns:
      - name: net_revenue_usd
        description: "Gross revenue minus refunds and chargebacks. USD."
        tests:
          - not_null

DAG lineage. Every ref() call generates automatic lineage. No configuration, no agents crawling your warehouse — just accurate model-to-model dependency tracking.

dbt Explorer. Column-level lineage, full-text search, test results, freshness signals. If you're on dbt Cloud, this is a real catalog UI for dbt-scoped metadata.

Tests as documentation. A not_null + unique test on order_id tells downstream consumers that the column is a reliable primary key. Tests are both quality gates and implicit documentation.

Source freshness. dbt source freshness tells you whether upstream loads are current — metadata that directly affects how much you trust downstream numbers.

This is a legitimate feature set. The gap isn't that dbt's catalog features are weak. The gap is that they're scoped exclusively to dbt.

What dbt doesn't see

dbt is a transformation tool. It knows everything about your transformations and nothing about the rest of your data stack. Specifically:

Dashboards. Which Looker explores query mart_customer_ltv? Which Tableau workbooks pull from fct_monthly_revenue? dbt has no idea, because dashboard metadata lives in Looker and Tableau — not in your dbt repo.

Notebooks and data apps. That Jupyter notebook your ML engineer runs every Tuesday against dim_products? The Streamlit app your ops team uses to track fulfillment? dbt doesn't catalog them. They're downstream consumers with no representation in the DAG.

Ad-hoc queries. Your data warehouse has query logs showing which users and services hit which tables. That's real usage metadata — it tells you which models are critical and which are dead weight. dbt doesn't ingest warehouse query history.

Non-dbt sources. Your warehouse probably has tables that never touch dbt. Fivetran syncs, CSV uploads, application database replicas, event streams. If it's not declared in a sources.yml file, dbt pretends it doesn't exist.

Cross-tool lineage. The full picture isn't just model-to-model. It's Kafka topic to Airflow DAG to raw table to dbt model to warehouse view to Looker dashboard to Slack alert. dbt covers one segment of that chain.

Privacy classification. Which columns contain PII? Which tables are subject to GDPR deletion requirements? dbt has no opinion. It's a transformation tool, not a governance tool.

The real gap: impact analysis across the stack

This is where the "do I need both" question gets concrete. Impact analysis — "if I change X, what breaks?" — is only as good as the scope of your lineage.

With dbt alone, you can answer: "If I change stg_orders, which dbt models are affected?" That's useful during development.

With a full catalog, you can answer: "If I change stg_orders, which models, dashboards, notebooks, syncs, and apps are affected?" That's useful before you push to production.

The difference matters most when things go wrong. Column renames, schema migrations, deprecating a model — these are the moments where incomplete lineage costs real time. I've watched teams spend entire days tracking down broken dashboards after a "simple" dbt refactor, manually searching through Looker repos and Slack history. A catalog with cross-tool lineage turns that day into a five-minute query.

dbt's semantic layer vs a catalog's semantic layer

dbt's MetricFlow lets you define metrics in YAML alongside your models — revenue = sum(amount) where status = 'paid'. These definitions are version-controlled and queryable through the dbt Semantic Layer API. It's a good system for teams that already live in dbt.

But a metric definition in a YAML file and a metric definition in a governed catalog serve different purposes. The YAML file is for the data team. The catalog entry is for the analyst who searches "revenue" and needs to find the canonical definition, see which dashboards use it, understand who owns it, and verify it hasn't drifted from the underlying data.

These are complementary, not competing. The best setup imports dbt metric definitions into the catalog and extends them with governance context — ownership, classification, usage analytics, drift detection. We wrote a full breakdown of how this works across tools in Best Semantic Layer Tools 2026.

When you don't need a catalog

Not everyone does. Skip the catalog if:

• You're a solo analyst or a team of two working in one dbt project against one warehouse. You can hold the full picture in your head.
• You have a single downstream consumer (one BI tool, no notebooks, no apps). The "what uses this" question has one answer.
• Your dbt project has fewer than 30 models and nobody has ever been surprised by a breaking change downstream.

In this world, dbt docs plus a disciplined sources.yml practice is enough. Adding a catalog creates maintenance overhead that outweighs the value.

When you've outgrown dbt-as-catalog

The signals are specific:

You can't answer "what breaks if I rename this column" without manual investigation. You've had a downstream breakage that dbt's DAG didn't predict. New analysts spend their first week asking "where do I find X" and the answer is a table dbt doesn't know about. You have more than one BI tool. You have notebooks, Streamlit apps, or reverse-ETL syncs that consume warehouse tables. More than three people touch the data regularly.

Any two of those, and you're carrying risk that a catalog eliminates.

Fastero's approach: import from dbt, extend beyond it

This is where I'll be direct about what Fastero does, because it's built for exactly this gap.

Fastero imports your dbt project — models, tests, sources, lineage, metric definitions — and extends the catalog beyond dbt's boundaries. The data catalog auto-discovers tables across all your connected sources (not just the ones dbt knows about), catalogs dashboards and notebooks, tracks column-level lineage across the full stack, and classifies columns for privacy governance.

The dbt import isn't a one-time snapshot. It syncs, so your dbt documentation stays current in the catalog without manual effort. And Fastero's catalog connects to external systems through DataHub, OpenMetadata, and Unity Catalog adapters — so if you already have metadata infrastructure, it integrates rather than replaces.

The practical pitch: connect your warehouse, point Fastero at your dbt project, and in about 15 minutes you go from "dbt DAG lineage" to "full-stack lineage with impact analysis, privacy classification, and a searchable catalog that covers everything — not just your models."

The decision framework

Ask yourself two questions:

Can you answer "what breaks downstream" for any model change? If yes, dbt is your catalog. If no, you need lineage that extends beyond dbt.

Can a new team member find any data asset by searching one place? If they need to check dbt docs, then Looker, then ask in Slack, then grep a notebook repo — you have a discovery problem that dbt alone can't solve.

If either answer is no, the cost of a catalog is less than the cost of the next broken dashboard or the next week a new hire spends navigating tribal knowledge.

Try Fastero free — import your dbt project, auto-discover everything dbt can't see, and get full-stack lineage in 15 minutes. No credit card required.