AI-Ready

Catalog Is the Most Overloaded Word in Data. What Are You Actually Buying?

Thiru Arunachalam, Founder & CEO, WALT

July 23, 2026

Ask five vendors what a data catalog is and you will hear two completely different products described with total confidence. One vendor means a business-term inventory maintained for governance teams, like say Collibra. Another means the file-level index like AWS Glue that tells a query engine where the Parquet data physically lives.

Same word. Different software categories. Different buyers, different consumers, different failure modes.

The confusion exists because the industry has been tossing it around carelessly for a decade. As agents become the primary consumers of data, do these categories need to stay separate?

Let’s start by untangling the different software categories first.

1. The governance catalog: What data means

A governance catalog is an inventory of the enterprise's tables and columns, with business meaning, ownership, sensitivity classification, sometimes lineage. According to Gartner, these tools (like Alation or Collibra) help business users manage and enforce data governance policies across business and data management systems.

This is the catalog most CDOs met first, because governance was the first team with the budget to buy one. It was built for stewards, compliance officers, and audit trails.

The main downside is that it never sat in the critical path of the insight production pipeline. Data flows from OLTP systems through the medallion layers into Power BI or Tableau, and nothing in that pipeline has to consult the catalog to run. Dashboards render and analysts query whether the glossary is current or not. So the catalog became a stale inventory enforced by human discipline rather than by architecture. Schemas drift, business definitions evolve, the maintenance is manual, and the steward updating the glossary is always three sprints behind the pipeline that changed the schema.

2. The technical catalog: Where data lives

A technical catalog is the file-level index that stores the physical location of every table's data (which S3 bucket, which folder, which set of Parquet files) alongside schema, partitioning, and versioning. Its primary consumer is a compute engine, and almost nobody outside the data infrastructure team could describe what they do.

Without a technical catalog, Trino, DuckDB, Snowflake, and Databricks have no way to find the current version of a table or read it consistently.

In 2021, Unity Catalog was the first serious attempt to merge the technical and governance layers in one product. Databricks built it as a technical catalog, then folded in access control, lineage, and discovery. That move challenged incumbents like Collibra and Alation. Snowflake's Polaris (launched in 2024) and the Iceberg REST catalog protocol belong to this family.

Merged or standalone, this layer is now load-bearing for the entire open-table-format world (anything built on Iceberg, Delta, or Hudi), as illustrated in the image below.

A snapshot of what actually lives in the disk, with the entire modern lakehouse read path in one picture. Image by author.

A query engine cannot simply scan the directory, because a raw file listing cannot say which Parquet files belong to the current version of the table. So the engine must read the catalog, follow its pointer to the Iceberg or Delta metadata, open only the files that metadata lists, and then return rows.

So which catalog does your organization need?

Both. The shared name implies a choice, and there is no choice to make:

1. Governance catalog: Answers what this data means and who is allowed to use it. Built for people (stewards, auditors, regulators).

2. Technical catalog: Answers where this data lives and how a query engine reads it. Built for machines.

The two catalogs answer different questions for different consumers. Neither consumer can borrow the other's catalog. CDOs were sold two entirely different things under one word, often in the same quarter, sometimes in the same deck. Treating them as one procurement decision produces bad conversations and worse outcomes.

Even Unity Catalog merging the two questions isn’t enough partly because of its reach. It holds strongest inside one vendor's perimeter, while most enterprise estates span multiple environments. And partly because of what actually merged: access control, lineage, and discovery, the enforcement side of governance moving in with the where. The meaning side, the business definitions and metric logic that glossaries were supposed to hold, never made the move. It was going stale even in the standalone catalogs, and a merger cannot fix a layer that was never really owned.

That’s meaning (i.e., context): the governance catalog documents meaning but cannot keep it current, and the technical catalog only stores locations and schemas, never meaning.

For years, humans patiently and painstakingly filled that crack, but that’s something agents cannot do.

So what’s the fix? To understand that, let’s take a step back and revisit the first principles: the reason catalogs came into existence.

Back to first principles: 3 things analytics always needs

Strip away vendor names and every analytics stack, in every era, has required three answers to deliver useful results:

1. Where the data physically sits: Solved by the technical layer (Polaris, AWS Glue, Unity Catalog, the Iceberg REST catalog).

2. What the data means: Solved by the semantic layer (ontology, semantic definitions, metric registry, data context graph).

3. Who owns it and who may use it: Solved by the governance layer (and enterprise catalogs like Collibra, Alation, tools overseeing IAM, classification, policy, etc.)

A stack missing any one of the three fails in a predictable way.

- Miss the technical answer and queries return errors or read stale snapshots.

- Miss the semantic answer and queries return numbers that are technically correct and completely wrong, the five-versions-of-revenue problem every data leader knows by name.

- Miss the governance answer and the first audit finding writes itself.

Every stack needs all three. Some vendors sell just one of the three and market it as "the catalog," which is where the confusion started and why it persists.

What has changed in the agent-first era

Today, the three orthogonal capabilities mentioned earlier live in three different products, run by three different teams, updated on three different cadences.

The technical catalog updates on every commit. The governance catalog updates when a steward gets to the ticket. The semantic definitions update whenever someone remembers the YAML file exists.

A human analyst papers over this fragmentation with tribal knowledge. An autonomous agent has no such context. a16z's analysis of the data agent market reached the blunt version of this conclusion: "data and analytics agents are essentially useless without the right context."

Does it still make sense to keep the two types of catalog separate, or should they fuse into a single graph that the agent can reason against in one hop? Ultimately, every agent needs a single, verifiable answer: this data lives at address X, means Y, and I am permitted to use it for Z.

The case for a single graph that agents can query in one hop

A working hypothesis for the next few years: the semantic and technical layers converge into one graph, and governance becomes a property embedded in that graph rather than a product standing beside it. Address, meaning, and permission resolve in a single lookup.

That converged structure is what a data context graph aspires to be. This graph holds the ontology, the canonical metric definitions, the entity relationships, and the lineage, while referencing the technical layer for physical truth and carrying policy as enforceable metadata.

Two clarifications matter here. Firstly, this is a virtual layer with context about your data rather than the data itself. Your Glue or Polaris catalog keeps serving engines, and your Collibra investment gets read and amplified. Convergence describes how meaning gets served to a consumer: no rip and replace is required.

Secondly, the reason the governance catalog goes stale is that humans maintain it by hand. The graph only stays converged if something rebuilds and revalidates it continuously, every night, against every schema change. That maintenance loop is the work of an autonomous data engineer.

What does this mean for CDOs procuring in 2026?

Stop treating "buy a catalog" as one decision. Break it into three, and put each question to every vendor in the room:

1. Do we have a technical catalog strategy that works with open table formats (Iceberg, Delta, Hudi) across every place our data lives (including multi-cloud environments)?

2. Do we have a meaning strategy (a data context graph) that outlives any platform we happen to be on? Does something maintain it automatically as schemas and definitions drift?

3. Do we have a governance strategy that stays enforceable as data flows across systems? Also, can an agent hitting your data resolve permission in the same hop as meaning?

Vendors who sell any one of these three and call it "the catalog" are answering a third of the question, at best. That’s fine, as long as everyone in the room knows which third.

One more test worth adding: Ask each vendor what happens to their layer when a source system renames a column at 2 AM. The answer separates a living graph from a documentation archive.

What if you already own a governance catalog like Collibra?

Keep it. A Collibra or Alation deployment holds years of stewardship: approved definitions, ownership records, sensitivity classifications. Treating that as a sunk cost would waste the most expensive part, the human judgment already encoded in it.

The data context graph connects to it bidirectionally. WALT's crew of autonomous data engineers harvests what your catalog already knows, fills in what it never captured (the entity relationships, the metric logic, the live lineage), and writes new definitions back in human-readable form for your stewards to approve.

Your catalog stops being a stale inventory and instead, becomes a governed input to a layer that finally sits in the read path.

What if you were about to buy one?

A standalone governance catalog buys you documentation plus a permanent maintenance obligation. We’ve already traced how that ends: outside the critical path, enforced by discipline, three sprints behind the schema.

Invest instead in constructing the layer your agents will actually read. WALT's autonomous data engineers build the data context graph (ontology, knowledge graph, semantic layer) in days, revalidate it nightly against every schema change, and serve it to any agent over MCP.

You get the meaning layer working from week one, without adding one more manually maintained inventory to the stack.

Separate the where, the what, and the who

The word catalog has been doing more harm than good in enterprise data conversations for a decade. It let two different products blur into one budget line, and it let a critical layer, meaning, go unowned because everyone assumed the other catalog covered it. Separate the where, the what it means, and the who owns it. Instead, ask which of them agents actually need, and the next decade of data infrastructure starts to look very different.

If you want to see what a continuously maintained data context graph looks like on top of the stack you already own, see how WALT works, or book a demo and we’ll walk you through it against your own schemas.