What Is a Data Catalog? When You Need One

At a Glance

A data catalog is a searchable inventory of an organization’s data assets and what they mean. Tables, columns, dashboards, models and pipelines, each with a definition, an owner, a freshness signal and a trail back to where the numbers came from.

The problem it solves is mundane and expensive. Somebody needs the revenue number. There are four tables with revenue in the name, two of them deprecated, and the only person who knows which one is right is on holiday. That question, repeated across a team, is where a surprising share of an analytics team’s week goes.

A catalog answers it without a human in the loop. That’s the whole pitch, and it’s a good one, provided the definitions inside it are true. A catalog full of stale definitions is worse than no catalog, because people trust it for a while before they stop.

What a Data Catalog Does

Four jobs, in rough order of how much value they deliver.

Discovery. Search across every table, view, dashboard and model in the platform, the way you’d search a codebase. Find the four revenue tables, see which one is used by 30 downstream dashboards and which one nobody has queried in eight months.

Meaning. Attach a business definition to a technical object. orders.net_amount is not self-explanatory. Net of what? Refunds, discounts, VAT, all three? The catalog is where that answer lives once instead of in six people’s heads.

Ownership. Every domain has a named owner who is accountable for its definitions. This is the field most teams leave blank and the one that decides whether the catalog survives.

Trust signals. Freshness, quality test results, deprecation flags, lineage back to the source. Enough for an analyst to decide whether to use a table without asking anyone.

Most catalogs also carry access requests, glossary terms, and some form of usage analytics. Useful extras on top of the four jobs above.

Catalog vs Data Dictionary vs Metadata Repository

These three get used interchangeably and they aren’t the same thing.

The distinction that matters in practice: a dictionary and a repository describe what the data is. A catalog also describes what it means and whether you should trust it. That second half can’t be automated, which is why catalogs need owners and the other two mostly don’t.

Catalog vs Lineage vs Observability

These three overlap enough that vendors now sell all three in one product, which makes the boundary harder to see rather than easier.

• A data catalog answers what exists and what does it mean. It’s an inventory with definitions.
• Data lineage answers where did this come from and what breaks if I change it. It’s a dependency graph.
• Data observability answers is it healthy right now. It’s monitoring: freshness, volume, schema drift, distribution shifts, alerts.

You can have any one without the others. In a mature platform they feed each other: lineage populates the catalog’s trust signals, observability decides whether a catalog entry shows a green tick or a warning, and the catalog gives both of them a place to be seen by people who don’t read Airflow logs.

If you’re choosing where to start, start with the catalog only if discovery is the pain. If the pain is “things break silently and we find out from the CFO”, observability comes first.

What Goes Into a Catalog

The parts that get populated automatically, and the parts that don’t.

Collected automatically by crawling the warehouse, the orchestrator and the BI tool:

• Schemas, tables, columns, data types
• Row counts, last-modified timestamps, storage size
• Query logs and usage frequency
• Column-level lineage, where the tools can parse it
• Dashboard and report dependencies

Written by humans, and this is the whole game:

• Business definitions for the tables and columns that carry meaning
• Domain owners
• Deprecation notices and the pointer to the replacement
• Certified or verified flags on the handful of tables that are the source of truth
• Glossary terms and how they map to physical objects

Automated metadata is free and mostly useless on its own. Knowing a column is a NUMERIC(18,2) last updated at 04:12 doesn’t tell you whether it includes VAT.

When You Need One, and When You Don’t

You probably need one when more than one of these is true:

• More than roughly 8 people query the warehouse regularly
• More than 200 or 300 tables, or you genuinely don’t know the number
• New analysts take longer than a week to find the right tables on their own
• The same “which table should I use” question reaches the data team more than a couple of times a day
• You’re in a regulated environment and need to show where a reported figure came from

You probably don’t when:

• The whole platform is 40 tables and two people who built all of them
• Your transformation layer is dbt and the model documentation is already current, in which case dbt docs may be enough for another year
• Nobody has agreed to own definitions yet, which is the next section

That last exclusion decides the outcome. Without named owners, you pay a platform bill every month for a bookmark.

Why Catalogs Go Stale

Most data catalogs stop being trusted within a quarter. The tool installs fine. Metadata flows in. Three months later half the definitions are wrong, the ownership fields are blank, and lineage is broken on exactly the tables that matter most.

The order of operations decides which way it goes. Teams that succeed name the domain owners before procurement, not after deployment. One client, a 10-person data team, did it that way: a named owner for each warehouse area (product, finance, growth, ops), each committed to keeping definitions current, and only then the tool. Six weeks to deploy, Slack “where is this data” questions down about 80%, analytics turnaround from 2 weeks to 3 days.

The catalog worked because the documentation had owners before the platform existed. The platform was where that documentation lived.

The practical test before you sign anything: name the owner of every domain out loud. If you can’t, the catalog will go stale regardless of vendor.

A second, smaller failure mode is cataloguing everything. A platform with 2,000 tables doesn’t need 2,000 curated definitions. It needs 50 certified ones covering the objects that feed reporting, and automated metadata on the rest.

Picking One

The market splits roughly three ways, and what you already run usually decides the answer before any feature comparison does.

Commercial platforms - Atlan, Alation, Collibra. Strongest curation and governance workflows, the best UI for non-technical users, and priced accordingly. Worth it when the audience extends beyond the data team.

Open source - DataHub, OpenMetadata, Amundsen. Capable and free of licence cost, and they will consume engineering time you should count honestly. A reasonable choice when you have a platform engineer with capacity and a preference for owning the stack.

Warehouse-native - Databricks Unity Catalog, Google Dataplex, Snowflake’s own object tagging and Horizon features. Least friction if you’re single-platform, because governance and access control live in the same place as the metadata. Awkward the moment a second platform appears. See Snowflake vs BigQuery vs Databricks for how that single-platform assumption tends to hold or break.

Whatever you pick, weight two things above features: how well it reads your existing stack without custom connectors, and how little effort it takes an owner to correct a wrong definition. A curation workflow that takes six clicks won’t be used.

Related Reading

• What Is Data Lineage? - The dependency graph a catalog leans on
• What Is Data Governance? - Where ownership and definitions come from
• What Is Data Quality? - The trust signals a catalog surfaces
• Data Platform Architecture - Where the catalog sits in the stack
• TOGAF Data Architecture - Metadata management as a TOGAF building block
• Most Data Catalogs Go Stale Within a Quarter - The owners-first procurement order
• Data Observability and the Data Catalog - Why the two categories keep merging

Last updated: 15 September 2026