Google's Knowledge Catalog has been renamed four times. Data Catalog, then Dataplex Catalog, then BigQuery universal catalog, then Dataplex Universal Catalog, and now Knowledge Catalog, as of 10 April 2026. The API, gcloud and IAM roles still all say "dataplex". If you land on a page that mentions Dataplex and wonder whether you're reading something out of date, you're probably not. That's just the product's fifth name in four years.
I spent some time looking through the different sections of Knowledge Catalog, checking each one against Google's current documentation and testing it live rather than assuming the docs were right.
Writing good descriptions and adding context to your data used to be a nice-to-have. With AI now doing more of the actual querying, it directly affects whether an agent gets the answer right, which is a big part of why this was worth the time.
The nine sections, ranked by usefulness rather than by console order
| Section | What it's for | Best suited to |
| Glossaries | Writing down what a word means, once | Any team, and worth doing early |
| Data profiling and quality | Noticing when a table stops behaving | Teams who can justify the per-run cost |
| Data products | Requesting access without asking a person | Large organisations with many data producers and consumers |
| Cloud Storage discovery | Turning a bucket of files into tables | Anyone with data still sitting in files rather than tables |
| Connectors | Finding databases outside Google Cloud | Teams with databases living outside Google Cloud |
| Metadata types | Tagging tables so they're searchable | Large, decentralised data estates with many teams tagging independently |
| Data domains | Filing datasets into named boxes | Large organisations split across many teams and projects |
| Manage lakes | The old storage side half of the product | Legacy Dataplex lake setups, nobody starting fresh |
| Data Catalog (deprecated) | The previous product's remains | Nobody. It's deprecated |
A few findings from that list are worth spelling out.
Domains, metadata types and lakes are all built for data scattered across dozens of projects and teams who can't ask each other questions directly. If you already tag and describe tables through a transformation layer like Dataform or dbt, most of that job is already done there: version controlled, reviewed in a pull request, rewritten on every build and visible directly in BigQuery.
A data domain can hold a dataset once. Any one dataset belongs to exactly one domain, so domains can't map onto departments, because most datasets get read by several teams. They only work if you file a dataset by who maintains it, not by who uses it.
In data profiling and quality, a scan can report "Succeeded" even when your data fails every check it ran. Succeeded here means the scan itself completed. It says nothing about whether the data passed. Nothing stops when a check fails: you get counts and a score, not the failing rows, and the result only shows on the table itself if you tick Publish.
Cloud Storage discovery creates real, queryable tables over a full set of files, not samples. Point it at a bucket and someone can query two years of history through the resulting tables on day one. Those tables arrive with no description, no owner and no explanation of what they mean. The meaning still has to be added separately, by a person.
The old Data Catalog is dead. It still shows a data loss banner, but the shutdown already happened back in June, so there's nothing left to lose and nothing worth setting up here. Policy tags, which control column-level access in BigQuery, are a separate feature and still active.
Five things true of every section
It's one place to look up what data exists, what it means and whether it can be trusted.
It only describes data. Nothing in it moves, cleans, joins or fixes anything: it points at data that lives somewhere else.
Nothing writes itself. Every genuinely useful entry in it was typed in by a person. BigQuery insights can help here. The product gives you the filing structure and the search box, not the content.
Most of it stays invisible where you actually work. You won't see it in BigQuery, Dataform or Looker Studio unless you deliberately open Knowledge Catalog and search for it. Table and column descriptions are the one exception, because they don't actually live in the catalog. They're stored directly on the table itself in BigQuery, so they show up in the BigQuery console, in Dataform, in Looker Studio and through pretty much any connection into that data, AI included. Everything else you write in Knowledge Catalog stays inside Knowledge Catalog unless someone goes looking for it there specifically. I'll get into what that means for AI in more depth in the next post.
Only one section costs money: data profiling and quality, charged per run, with no free tier.
The one rule for what goes in a glossary
Glossaries are the section worth starting with, and the rule for what belongs in one is simple: if two reasonable people on the team would give a different answer today, write it down. If everyone already agrees, leave it out.
A glossary that tries to define everything becomes a dumping ground nobody maintains, and a stale glossary is worse than no glossary at all, because people keep trusting it after it stops being true.
A few examples of the kind of terms worth putting in a glossary: Client, Engagement, SOW, Active Client, Utilisation Rate, Monthly Revenue, Billable Hours. Each one earns its place for the same reason: different teams can drift into different definitions of it, and neither definition is wrong on its own.
Active Client is the clearest example. Finance might mean invoiced in the last 90 days. Sales might mean an open deal or recent contact. Delivery might mean a currently active contract. None of the three answers is wrong. The problem is only ever knowing which one someone means when they ask.
There's a second reason a term can earn its place in a glossary, and it matters most once AI is involved: everyone on the team can agree on what a word means, while nothing in the data itself says so anywhere.
Take "an hour" of work. Nobody argues about what that means. But an AI reading the raw data has no way to know that hours are recorded in a system like Harvest rather than somewhere else, that the column holding them isn't actually called "hours", or that credit-based work, fixed-fee work and managed-service work all need to be counted as hours too, even though they're billed differently. A person picks all of that up just by being around the business long enough. A model never will, unless someone writes it down.
The first rule, above, is about disagreement between people. This second rule is about knowledge that lives in someone's head rather than in the data. Both are reasons to write a term down, and I'll come back to why the second one matters more once AI is doing the querying, in the next post. How to make an AI agent accurate in BigQuery
That's the descriptive picture: what's in Knowledge Catalog, what each part is for, and which of the nine sections are worth setting up versus leaving alone. The next post is about something narrower and, I think, more useful: what actually makes an AI agent accurate when it's querying your BigQuery data, and where a glossary really sits on that list.
