Picture an analyst who needs to answer a simple question: how many active customers did we have last quarter? Before calculating anything, they first have to find where the customer data lives, which of several tables is the right one, what exactly active means, and whether that source can be trusted. Often, that search takes longer than the analysis itself — and ends with a message in the chat: does anyone know which is the correct customer table?
Multiply this by dozens of analysts and hundreds of tables and dashboards, and you have the daily reality of many data-driven organisations. The knowledge about where the data is and what it means lives in a few people's heads. When those people are busy, on holiday or leave the company, the knowledge goes with them. This is where the data catalog comes in.
A data catalog is, at its core, a searchable inventory of all of an organisation's data — but it is much more than a list. In this article we explain what a good catalog includes, how it differs from neighbouring concepts such as the data dictionary and governance, and how to roll one out in phases without falling into the trap of the catalog nobody uses.
What a data catalog is
A data catalog is a platform that centralises the information about an organisation's data — the so-called metadata, or data about data. Instead of storing the data itself, it stores what you need to know about it: where it is, what it contains, where it comes from, who is responsible, how reliable it is and how it relates to everything else. In practice, it works like the internal search engine for data: someone searches for active customers and finds the right table, with its business definition, its owner and its usage history.
The most useful analogy is a library. The books are the data; the catalog is the system that lets you find the right book without walking the shelves one by one. Without a catalog, each person rebuilds the map of the library in their own head — and none of those maps fully match a colleague's.
The invisible cost of hunting for data
The absence of a catalog rarely shows up as a line in the budget, but the cost is real. In many teams, analysts spend a significant slice of their time — common estimates point to around 30% — simply finding, validating and understanding data before they can use it. That time produces no decision; it is pure friction.
There is an even more insidious cost: distrust. When two people present different numbers for the same metric in a meeting, because they used different tables or definitions of active customer, the discussion stops being about the decision and becomes about which number is right. Each of those episodes erodes trust in the data and pushes people back towards gut feel. A catalog does not solve all of this on its own, but it attacks the root: a single, shared source of truth about what exists and what it means.
What a good data catalog includes
Not all catalogs are born equal. A genuinely useful catalog goes well beyond a list of tables and usually brings together:
- Technical metadata — table and column names, data types, schema, size and refresh frequency.
- A business glossary — the definition, in business language, of terms such as active customer, net revenue or margin, linked to the data that materialises them.
- Data lineage — the trail of where the data comes from and which transformations it went through, so you can gauge the impact of a change and trace the origin of an error.
- Ownership and stewards — who owns each dataset and whom to turn to when in doubt.
- Usage and popularity signals — which tables are queried most and by whom, a precious hint of which are actually reliable.
- Quality indicators — freshness, completeness and other signals that help decide whether that source can be trusted.
It is the combination of technical and business context that makes the difference. A catalog with only technical metadata is a glorified schema; it is the glossary and the lineage that make it useful to those who do not know the innards of the database.
Catalog, data dictionary and governance
These three terms appear together and get confused. A data dictionary is a structured description of a system's fields — names, types, descriptions. It is valuable, but static and usually limited to a single database. The catalog is broader and more dynamic: it spans several sources, adds business context, lineage, usage and quality, and is designed to be searched by many people.
Data governance, in turn, is the set of policies, roles and processes that define how data is managed, protected and used. The relationship is simple: governance sets the rules; the catalog is one of the tools that makes those rules visible and enforceable day to day. Having a catalog without governance is having a map with no road signs; having governance without a catalog is having rules that almost no one can look up.
Buy or build: the options
Broadly, there are three paths. The first is to adopt an open-source solution (there are mature catalog and metadata-management projects), attractive for its zero licence cost but demanding in implementation and maintenance effort. The second is a dedicated commercial platform, which brings rich features and support, at the price of a licence and some vendor lock-in. The third, increasingly common, is to use the catalog already built into the data platform the organisation runs, taking advantage of its proximity to the rest of the stack.
There is no universal answer. A small organisation, with few sources, can start with something simple — even a well-maintained sheet — and only later evolve. A large organisation, with sensitive data and compliance requirements, benefits from a robust solution with access control and automatic lineage. The mistake is choosing the tool before understanding the problem you want to solve.
How to roll out a catalog in phases
The temptation to catalog everything at once is the fastest route to failure. A catalog grows in layers. An approach that works starts by inventorying the priority sources — not all of them, only the tables and reports that underpin the most important decisions. Many platforms can automatically discover and import the technical metadata, giving you a first draft in little time.
The next phase is to enrich with context: assign owners, write the business definitions of the critical terms, and link each metric to the data that produces it. It is the most laborious step and the one that creates the most value, because this is where knowledge leaves people's heads and moves to a shared place. Then comes lineage and quality, so that whoever consults understands the origin and reliability. And finally — but planned from the start — adoption: embedding the catalog in people's workflow, so that consulting it is easier than asking in the chat.
Driving adoption and measuring value
The biggest risk of a catalog project is not technical; it is human. A catalog nobody uses is worse than no catalog, because it consumed effort and creates a false sense of order. Adoption is won by making the catalog useful and present: fast search results, reliable definitions, integration with the tools people already use, and a handful of internal champions who lead by example. It helps a great deal to start in a domain where the pain is obvious and to show a concrete win.
To measure whether it is working, look at signals such as the number of active catalog users, the share of critical datasets with an owner and a definition, the reduction in time to find the right source, and the drop in repeated questions of the which is the good table? kind. None of these metrics is perfect, but together they tell the story of a living catalog — or of one slowly dying.
Common mistakes to avoid
Some mistakes recur often. Trying to catalog everything at once, instead of prioritising what underpins decisions. Filling the catalog with technical metadata and forgetting the business context, leaving it incomprehensible to those who need it most. Not assigning owners, which turns the catalog into a graveyard of outdated information. And treating the catalog as a project with an end, when it is a product that needs continuous maintenance: new data appears, definitions change, and an outdated catalog loses the trust that took months to build.
Mini case: three definitions of active customer
A services company had a recurring problem in management meetings: depending on the report, the number of active customers varied significantly. On investigation, the reason was simple — there were at least three definitions in circulation, each materialised in a different table, and no one knew for sure which was official. The analysts, for their part, admitted to spending almost a third of their time hunting for and validating data before every analysis.
The company rolled out a catalog in phases. It started with the ten tables feeding the management reports, imported the technical metadata automatically, assigned an owner to each dataset, and wrote, in the glossary, a single agreed definition of active customer, linked to the correct table. Within a few months, the typical time to find the right source went from hours to minutes, meetings stopped arguing about which number was right, and report duplication fell visibly. The catalog created no new data; it gave order and trust to what already existed.
In practice
A data catalog is neither a luxury for large companies nor an IT project you do once and file away. It is the infrastructure that lets people find and trust data without relying on a colleague's memory. Start small, with the sources that underpin the decisions that matter most; invest in business context, not just technical metadata; assign owners from day one; and treat adoption as part of the work, not an automatic consequence.
The return does not appear on a single budget line, but it is felt across the whole organisation: less time lost searching, fewer arguments over which number is right, and decisions grounded in data that people actually understand. In a world where almost every company has more data than it can use, the advantage is no longer in having data — it is in being able to find it and trust it.
