A data lead at a mid-sized insurer told me her catalog adoption was sitting at 4% of the eligible user base, eleven months after a six-figure rollout. “And I’m being generous about who’s eligible,” she added. This is, in my experience, well within the normal range. The data catalog category has a structural adoption problem, and it’s getting worse rather than better as the underlying tools have grown more sophisticated.

The numbers from practitioner surveys are roughly consistent year over year. The Eckerson Group catalog research, the various analyst pulses, and the conversations any of us have with peer data leaders all converge on a similar picture: most enterprise catalogs run at 5%–15% monthly active usage among the population they’re meant to serve. A few outliers hit 30% or more. A long tail languishes below 5% and, eventually, gets quietly retired or replaced with the next vendor’s product.

Why the obvious explanations are wrong

The story most catalog programs tell themselves about low adoption is some version of: the users aren’t data-mature enough, the metadata isn’t complete enough, or the integrations to source systems aren’t deep enough. So the program spends another year ingesting more lineage and curating more glossary terms. Adoption stays flat.

The reason this doesn’t work is that the diagnosis is wrong. Users don’t fail to adopt catalogs because the catalog is incomplete. They fail to adopt because the catalog isn’t where their work happens.

Think about the actual analyst workflow at any reasonable-sized company in 2026. They spend most of their day in the BI tool, the SQL client, the notebook, the chat tool where colleagues share queries, and increasingly the AI assistant that’s helping them write SQL. The data catalog, in most deployments, is none of those places. It’s a separate web application that they have to remember to go visit, find a search bar, type something into, and then context-switch back. The friction is invisible to whoever procured the catalog. It is overwhelming to whoever’s meant to use it.

What’s working in mid-2026

The deployments I see breaking through to genuine adoption have stopped trying to be a destination and started being an embedded service. That’s a meaningful architectural shift.

Concretely: catalog metadata flowing into the SQL editor as inline annotations on table and column names. Catalog ownership and freshness signals appearing as side-panel context in the BI tool. Catalog descriptions being injected into the prompt context of the AI SQL assistant so the model understands what cust_v2_final actually represents. The user doesn’t visit the catalog. The catalog visits them.

The catalogs that have invested most heavily in this — both the established vendors and the newer entrants — are showing meaningfully better usage numbers, sometimes 4x to 6x what they were getting from the destination-app model. The signals on this are messy because vendors define “active user” differently, but the directional pattern is unmistakable to anyone in the practitioner community.

The other thing that’s working is shrinking the scope of what the catalog tries to do. Early-2020s catalog projects often had goals like “single source of truth for all enterprise metadata across all data assets.” That was always going to fail. The successful 2026 deployments tend to be scoped to a specific use case — analyst self-service, regulatory data lineage, AI training data documentation — and grow outward from there.

The role of AI, briefly

There’s a fashionable claim that AI is going to fix the data catalog problem by auto-generating descriptions and surfacing the right asset based on natural-language queries. The honest version is more nuanced. Auto-generated descriptions help on the margin, but they’re confidently wrong often enough that without a curation step they actively erode trust. Anyone who’s seen an LLM hallucinate a column description that contradicts the actual business logic knows what I mean.

A team I respect at Team400, a Sydney-based AI consultancy, put it well in a recent client engagement: the AI is useful for triage, not for authority. It can surface candidate descriptions, flag stale metadata, and propose links. A human still has to confirm. That’s a different operational model than “the AI runs the catalog,” and it’s the one that’s actually working.

What to do if your catalog is at 6%

A few practical moves that have worked for catalog programs I’ve watched recover.

First, stop measuring catalog success in catalog activity. Measure it in the workflows the catalog is supposed to support. Time to find a trustworthy table. Number of failed analyst self-service attempts per quarter. Whether new analysts can answer their first question without asking a senior. These are the numbers that matter and they’re the numbers that justify continued investment.

Second, do the integration work. If your catalog has a Slack or Teams integration, deploy it and configure it. If it has a SQL editor plugin, install it. If it has an API the AI assistant team can call, expose it. Most of this work is unglamorous but it’s where the user-experience yield is.

Third, pick three high-value asset domains and do them properly rather than trying to catalog everything at the same depth. The DAMA-DMBOK still has reasonable guidance on this, and the DAMA International framework documentation gets occasionally over-criticised but its emphasis on stewardship being a real role rather than a side-of-desk task remains correct.

The data lead at the insurer I started with has spent the last quarter rebuilding her catalog program around the BI tool integration rather than the catalog UI. Her usage numbers are starting to look different. She still hasn’t told her vendor’s account manager that she stopped pushing people to the catalog UI. The numbers are going up, which is the only thing the steering committee was looking at. Whatever works.