What is a data catalog and what is it really for?
Every week, in some data team in some medium or large company, someone spends two hours looking for where a field in a report comes from. They ask the engineer, the engineer asks the analyst, the analyst looks at the transformation code and finds four different versions. A well-implemented data catalog eliminates this problem. This article explains what it is, how it works and, above all, why most implementations fail within six months.
What is a data catalog
A data catalog is a centralised tool that registers, organises and makes accessible the metadata of all an organisation's data assets: tables, fields, pipelines, dashboards, APIs, machine learning models and any other information asset that the organisation uses to operate or decide.
The function of the catalogue is to answer four questions that today, without it, require an investigation:
- What exists? Inventory of all available data assets.
- What does it mean? Business definition, context and classification of each data item.
- Where does it come from? Lineage: origin, transformations applied and journey to the point of consumption.
- Who is responsible and can I use it? Owner, sensitivity classification and access policy.
Data catalog vs business glossary: the differences
These three terms are often used interchangeably, but they are not the same. Confusion between them generates wrong expectations and projects that don't deliver what they promised.
Data catalog
Technical layer: records physical data assets — tables, fields, pipelines, models — with their technical metadata (data type, nullability, update frequency, lineage). In tools like OpenMetadata or Collibra, this layer is populated automatically via connectors to data platforms: Snowflake, Databricks, BigQuery, dbt.
Business glossary
Business layer: defines what each concept means for the organisation. What an active customer is. How net income is calculated. What the company understands by operational incident. This layer is maintained by Data Stewards, not engineers, and requires validation and approval by Data Owners.
Why a data catalog is essential for the AI Act
Article 10 of the AI Act requires that training datasets for high-risk AI systems have documented origin, transformations, selection criteria and quality metrics. A data catalog with automated lineage is the most sustainable way to keep this documentation alive without depending on manual intensive work. Without a catalog, Article 10 becomes a Word document that someone updates once and no one touches again.
How a data catalog works internally
Understanding how a catalog works technically helps make better decisions about which tool to choose and how to implement it. The main components of any modern catalog are:
Connectors and automatic metadata ingestion
The catalog connects directly to data platforms — Snowflake, Databricks, BigQuery, dbt, Airflow, Power BI, Tableau — and automatically extracts technical metadata: schemas, data types, update frequency, record volume and technical lineage between tables and pipelines.
Search and discovery engine
The main value of the catalog for the end user is being able to search. Search by table name, business concept, owner, sensitivity classification or any combination. The most mature tools add semantic search.
Data catalog tools in 2026
| Tool | Type | Best for | Cost |
|---|---|---|---|
| OpenMetadata | Open source | Teams in cloud with modern stack | Free (self-hosted) / Paid SaaS |
| Apache Atlas | Open source | Hadoop/Hive legacy environments | Free (self-hosted) |
| dbt Docs | Open source / integrated | Data engineering teams using dbt | Free |
| Microsoft Purview | Enterprise / SaaS | Microsoft Azure ecosystem | Included in Azure / pay-per-use |
| Collibra | Enterprise | Large corporations with complex governance | High (enterprise license) |
| Alation | Enterprise | Organisations with strong data culture | Medium-high |
How to implement a data catalog that doesn't die in three months
The most frequent failure pattern in data catalog implementations is always the same: the tool is installed, an initial metadata load is done, it's presented in a management meeting and three months later no one uses it because no one has time to maintain it. To avoid this pattern, the order of implementation matters as much as the chosen tool.
Step 1: define the initial scope — don't try to catalog everything
The most common mistake is trying to catalog all the organisation's data from day one. The result is an endless project that never reaches production or arrives with metadata so superficial that it adds no value. Start with the three to five most critical domains for the business — the ones that generate the most questions, the ones that feed management reports, the ones that support AI systems — and do them well before expanding.
Step 2: automate technical metadata ingestion from day one
Configure the connectors with your data platforms before writing a single line of manual description. Technical metadata — schemas, types, lineage — must flow automatically. If the catalog base depends on manual work, it is condemned. With OpenMetadata and Snowflake, this initial configuration can be done in less than a day.
Step 3: assign Data Stewards with real time before launch
The catalog needs people responsible for enriching and maintaining business metadata. These people must have allocated time — not residual time — and clear criteria for what is expected of them. Without Data Stewards with a mandate, the catalog is a technical inventory without context that no one uses.
Step 4: integrate the catalog into existing workflows
A catalog that lives on a separate URL that no one remembers to visit is a dead catalog. The catalog must be where people work: in Power BI Service datasets with visible descriptions, in dbt models with documentation generated automatically on each deploy, in access request tickets with a link to the asset sheet. Adoption doesn't come from internal communication campaigns; it comes from making the catalog the path of least resistance to finding information about the data.
Step 5: measure adoption and make it visible
Define adoption metrics from the first month: catalog coverage by domain (percentage of assets with business description), number of weekly searches, number of assets with assigned owner, time since last metadata update. Publish these metrics on a dashboard visible to the team and management. What isn't measured isn't maintained.
What's your Data Governance maturity?
Free assessment with your priority gaps, plus the self-assessment quiz and savings calculator on the Data Governance path.