A data catalog is a searchable index of every data asset an organisation holds — tables, columns, reports, dashboards, pipelines — enriched with what each one means, where it came from, who owns it and how sensitive it is. It does not store your data. It stores metadata about your data, and it harvests most of that metadata automatically from the systems you already run.
The clearest analogy is a library catalog. The library holds the books; the catalog tells you what exists, where it is shelved, what it is about and whether you may borrow it. Remove the catalog and the books are still there — just unfindable at any useful scale.
Most large organisations are operating without one. They have thousands of tables, several hundred reports, and the location of anything important stored in the memory of four or five long-serving analysts. That works until one of them leaves.
The problem a catalog solves
The symptom is always the same, expressed in slightly different words:
"We have three reports showing revenue and they disagree. Nobody can tell me which one is right."
Underneath that sentence sits a specific, mechanical failure. Three teams built three pipelines against overlapping source tables, each applied a slightly different definition of the metric, and none of the differences was recorded anywhere. The reports are all correct given their assumptions, and the assumptions are invisible.
This produces a set of downstream costs that most organisations absorb without ever measuring. Gartner puts the average annual cost of poor data quality at $12.9 million per organisation; research from MIT Sloan Management Review with Cork University Business School frames the same problem as 15–25% of revenue lost annually where data quality is seriously degraded. Industry surveys consistently find engineers and analysts spending as much as half their time fixing data issues rather than producing anything new.
Concretely, the money leaves through five doors:
- Analysts spend the majority of their time locating and validating data rather than analysing it. Every new question restarts the archaeology.
- Schema changes break things unpredictably. An engineer drops a column that looks unused. It fed a quarterly regulatory submission through two intermediate views.
- The same logic is rebuilt repeatedly because nobody knew it already existed.
- Regulatory questions take days to answer, and the answer is a reconstruction from memory rather than evidence.
- AI projects stall at the data stage. A model grounded in data of unknown provenance is a liability rather than an asset — and this is now the most common reason organisations start governance work at all.
A catalog does not fix these by itself. It makes them visible and addressable, which is the precondition for fixing them.
The three layers of metadata
"Metadata" collapses three genuinely different things. Keeping them separate is the difference between a catalog that works and one that produces confusion.
Technical metadata — what the system says
Schemas, table and column names, data types, nullability, keys, row counts, partitioning, storage size, last-modified timestamps.
This layer is harvested automatically. A connector reads the system's own dictionary and refreshes on a schedule. No human should type technical metadata, and a catalog implementation where humans are typing it has been configured wrong.
Technical metadata answers what exists.
Business metadata — what the organisation means
Definitions, ownership, classification, criticality, retention, applicable regulation.
This layer cannot be harvested. It exists only in people's heads until someone writes it down, and it is where the real work of a catalog programme happens. CUST_STAT_CD = 'A' is technical metadata. That this means an active customer, defined as one with at least one transaction in the trailing ninety days is business metadata, and it took a meeting to establish.
Business metadata answers what it means and who is accountable.
Operational metadata — what actually happened
Pipeline run history, freshness, quality check results, query volumes, who accessed what and when.
Harvested, like technical metadata, but from execution systems rather than schemas. It answers is this current, is it healthy, and does anyone actually use it — the last of which is how you discover that a third of your reports have not been opened in a year.
Active metadata — metadata that does something
The newer term, and the one the analyst market has converged on. Active metadata is metadata that is not merely stored and displayed but fed back into systems to trigger action: alerting an owner when a source schema changes, blocking a pipeline when a quality rule fails, propagating a sensitivity label from a source column to every downstream copy.
When Gartner refreshed its Magic Quadrant for Data and Analytics Governance Platforms for 2026 — a category it created in January 2025 — active metadata, machine-learning automation and AI agents were weighted more heavily than in the first edition, alongside a widened scope covering unstructured data, analytics models and data products. The direction of the market is that governance should be continuous and automated rather than a documentation exercise performed once a year.
Data lineage: where the number came from
Lineage is the traced path of data from origin to destination, through every transformation on the way.
The distinction that matters commercially is between two granularities.
Table-level lineage says: this report reads from these four tables. Useful for impact analysis at a coarse level. Insufficient for an audit.
Column-level lineage says: the net_exposure figure in this report is computed from positions.notional minus collateral.value, where collateral.value is itself derived from a currency conversion applied to collateral.amount_local using the rate in fx_rates.close. That is an answer to a supervisory question.
The other distinction that matters is how lineage is produced.
Hand-drawn lineage — an architect draws the flow in a diagramming tool or the catalog's UI. It is accurate on the day it is drawn and decays immediately, because pipelines change and diagrams do not. Within a year it is actively misleading, which is worse than absent.
Parsed lineage — the catalog reads your actual SQL, stored procedures, ETL definitions and BI semantic layers, and derives the graph from the code that is really running. It updates when the code updates.
Only parsed, column-level lineage is worth building a compliance position on. When evaluating catalogs, this is the single most differentiating technical capability, and the one where marketing language diverges most from what the product does. Test it against your own transformation code, not against the vendor's demo dataset.
Lineage pays for itself in three places: impact analysis before a schema change, root-cause analysis when a number looks wrong, and evidence when a regulator asks how a figure was produced.
The business glossary
The glossary is where an organisation writes down what its own words mean.
It sounds trivial. It is consistently the hardest and highest-value part of a catalog programme, because it is the point where governance stops being a technical exercise.
A glossary entry is a business concept — Active Customer, Net Exposure, Chargeable Transaction — with an approved definition, an owner, and links to every physical column that implements it. That linkage is what makes it more than a document: an analyst looking at CUST_STAT_CD sees the approved definition attached to it, in context, at the moment they need it.
Two things reliably go wrong.
The glossary is built in isolation from the data. A well-written set of definitions that links to nothing physical is a PDF with extra steps. The value comes entirely from the binding between concept and column.
Definitions are drafted rather than decided. Someone writes a reasonable definition of active customer, circulates it, receives no objections because nobody read it, and publishes. Six months later two departments are still using different numbers. A definition that has not survived an actual argument between the parties who disagree is not a definition; it is a proposal.
Budget for the arguments. They are the product.
The multilingual case
In an organisation running Azerbaijani, Russian and English systems side by side, a glossary must model one concept with multiple language labels — not maintain three parallel glossaries.
The distinction is structural and hard to retrofit. müştəri, клиент and customer are three labels on one concept, and every physical column in all three systems binds to that single concept. Three separate glossaries produce three separate governance regimes that will diverge.
Check this capability explicitly during evaluation. Several catalog products assume a single working language and offer translation as a UI feature rather than a data model, which is not the same thing at all.
Data catalog vs data dictionary vs metadata repository
These get used interchangeably and are not the same.
Data dictionary — scope is one system or one database. Populated manually, usually as a document. Its audience is developers.
Metadata repository — scope is technical metadata across many systems. Populated by automated harvest. Its audience is data engineers.
Data catalog — scope is all three metadata layers across all systems, plus lineage, glossary, classification and workflow. Populated by automated harvest with a curated business layer on top. Its audience is analysts, stewards, engineers and risk functions alike.
A data dictionary describes one database's structure. A catalog spans the estate, adds meaning and provenance, and is designed for people who are not developers. If your "catalog" is only readable by engineers, it will not change how the business works.
The catalog as the grounding layer for AI
The strongest current argument for a catalog is not compliance. It is that enterprise AI does not work without one.
An AI agent asked what was net exposure at quarter end has to resolve three things a human analyst resolves tacitly: which table is authoritative, what the metric means here, and whether this user is permitted to see it. Those are exactly the three things a catalog holds — ownership, definition and classification — and exactly the three things absent from a raw connection to a database.
This is why Gartner's finding that over 40% of agentic AI projects will be cancelled by the end of 2027 for reasons including inadequate risk controls is really a governance statistic. An agent that cannot say where its answer came from cannot be approved for production, and an organisation without lineage cannot make it say so.
What a catalog will not do
Setting this out prevents the most common disappointment.
It will not clean your data. It will show you that a column is 40% null. Fixing that is a project, and the catalog does not do it.
It will not decide anything. It will surface that four customer tables exist. Deciding which is authoritative requires a person with authority.
It will not create ownership. Assigning an owner is a management act. The catalog records the outcome.
It will not adopt itself. The most common failure mode of a catalog programme is a fully populated catalog with no users. Adoption is a change-management problem — embedding the catalog in existing workflows, in onboarding, in the definition of done for a new pipeline — and it is where a programme lives or dies.
How a catalog is deployed
Typical sequence, four to eight weeks to first value in a scoped domain:
- Install. On-premise, in your own environment, for organisations that require it. The catalog needs a database of its own and network reachability to the systems it will read.
- Connect. Read-only credentials to source systems. This is where security review concentrates, and the honest answer to the standard question is that the catalog reads structure and statistics, not row-level content, and copies nothing. Mature platforms ship large connector libraries for this reason — OvalEdge lists more than 170 pre-built native connectors covering legacy databases, reporting systems and cloud services alike.
- Harvest. Technical metadata and lineage populate automatically. This is the first moment the organisation sees the true size of its estate, and it is usually larger than anyone said.
- Profile. Statistics per column — distributions, null rates, distinct counts, format patterns — which drives automated sensitivity classification.
- Curate. The human phase: glossary, ownership, classification review. Scope it to the assets that matter.
- Operate. Quality rules, access workflows, change alerts, and the routines that keep the catalog current.
Steps 1–4 are largely mechanical. Step 5 is where programmes slow down, and the way through it is narrow scope rather than more effort.
Do you need one?
Reasonable heuristics. If three or more apply, the answer is yes.
- More than ten source systems feeding analytics or reporting.
- Recurring disagreement about which of several numbers is correct.
- A regulator who asks how figures are produced.
- Analysts spending more time finding data than using it.
- Schema changes that break things nobody predicted.
- An AI or analytics initiative that has stalled on data quality or provenance.
- Key knowledge held by a small number of individuals.
Below that threshold — a handful of systems, one team, everyone in one room — documentation discipline is often enough, and a catalog is overhead.
Key points
- A catalog indexes metadata about your data. It never stores or copies the data itself.
- Technical and operational metadata are harvested automatically; business metadata is created by people, and that is where the work is.
- Active metadata — metadata that triggers action rather than sitting in a page — is what the 2026 analyst market now expects of a governance platform.
- Only parsed, column-level lineage is defensible in an audit. Hand-drawn lineage decays into misinformation.
- The glossary's value comes from binding concepts to physical columns, and from definitions that have survived a real disagreement.
- Multilingual organisations need one concept with many labels, not many glossaries. This is not retrofittable cheaply.
- A populated catalog with no users is the standard failure. Adoption is the hard part.
Yukon Labs implements OvalEdge on-premise for banks and government institutions in Azerbaijan. If you want the estate mapped before committing to a platform, the data governance assessment produces that in four to six weeks. For the wider programme context, see data governance in Azerbaijan.