Data catalog

What is a data catalog?

A data catalog is a central, searchable inventory of the data assets in an organisation: tables, views, dashboards, reports, files, APIs, data products, and sometimes machine learning features or models.

The catalog does not usually store the data itself. It stores metadata about the data: where it lives, what it means, who owns it, how fresh it is, which columns it has, which downstream reports use it, which quality rules apply, and who is allowed to access it.

Without a catalog, data assets hide in separate systems: Snowflake, Microsoft Fabric, SQL Server, Databricks, SharePoint, Power BI, spreadsheets on a network drive. A new analyst rebuilds a dataset because they cannot find the one that already exists. A manager sees two dashboards with similar names and no clue which one is trusted.

A catalog is the place people start before building another report, training another model, or exporting another list.

What information belongs in a data catalog?

Technical metadata
Table names, columns, data types, primary keys, foreign keys, partitions, refresh time, size, and source system. Much of this can be scanned automatically.

Business metadata
Plain-language definitions, descriptions, examples, and business rules. A field called active_customer_flag is not enough. The catalog should explain what an active customer means.

Ownership
Who owns the dataset? Who is the data steward? Which team answers questions or fixes issues? Ownership turns the catalog from a list into an operating model.

Lineage
Where did the data come from, what transformed it, and which reports or models depend on it? Lineage helps with audits, impact analysis, and incident response.

Quality signals
Freshness, row counts, null rates, uniqueness, accepted values, failed checks, or quality scores. A useful catalog tells people whether the data is healthy, rather than merely that it exists.

Classifications
Sensitivity labels, personal-data flags, retention rules, regulatory tags, and access policies. These help governance teams apply the right controls.

Business glossary versus catalog

A business glossary defines terms. A data catalog inventories assets. They work best together.

The glossary says: Active customer means a customer with at least one paid order in the last 90 days. The catalog links that definition to the column, table, measure, dashboard, or semantic model where the term is implemented.

If the glossary is separate from the catalog, definitions stay abstract. If the catalog has no glossary, technical names stay unclear. The bridge between the two is where trust grows.

Data catalog versus data governance

A data catalog is a tool and a practice for discovery. It answers: what data do we have, where is it, what does it mean, and who owns it?

Data governance is broader. It includes policies, roles, decision rights, quality expectations, access rules, retention, privacy, and change management.

The catalog is the map. Governance is the set of rules for using the territory. A catalog without governance becomes a search engine with no accountability. Governance without a catalog becomes policy that nobody can apply because nobody knows where the data is.

Modern platforms often combine both. Microsoft Purview Unified Catalog, OpenMetadata, Collibra, Atlan, Alation, and similar tools mix cataloging, glossary, lineage, ownership, quality signals, and governance workflows in different ways.

Active and passive catalogs

A passive catalog is filled manually or refreshed only now and then. It may be useful at launch, but it goes stale quickly if teams keep creating tables and reports outside the process.

An active catalog is connected to the data estate. It scans sources, reads usage, captures lineage, receives quality results, and updates metadata as systems change. It can flag schema changes, stale assets, missing owners, unused reports, or quality failures.

The more active the catalog, the more likely people are to trust it. The more manual it is, the more discipline you need from stewards and engineers.

How to start small

Do not begin by cataloging everything. Begin with the assets people already argue about.

1. Pick five to ten critical datasets or reports.

2. Add owners and stewards.

3. Write plain-language descriptions and glossary links.

4. Capture lineage from source to report where possible.

5. Add basic quality and freshness checks.

6. Show users where to search and how to request changes.

A small catalog with trusted assets is more useful than a giant catalog full of empty descriptions.

What to watch out for

Empty pages
A catalog with table names but no descriptions, owners, or context is just another technical list. Users will open it once and leave.

No stewardship
Metadata ages. Someone must maintain definitions, approve changes, handle questions, and clean up abandoned assets.

Tool-first governance
Buying a catalog does not decide who owns customer data, what quality means, or who may see personal data. Those decisions have to exist in the organisation.

Too much automation without context
Scanners can find columns. They cannot always explain why a table exists, which KPI it supports, or why one definition won over another.

Poor adoption
People will not use a catalog just because it exists. Put catalog links in Power BI, SQL tools, pull requests, onboarding, Teams or Slack, and incident workflows so the catalog appears where people already work.