Data Dictionary vs Business Glossary: What's the Difference, and Why They Drift

If you’ve been handed both a “data dictionary” and a “business glossary” and can’t quite say where one ends and the other begins, you’re not alone — the terms get used interchangeably, and plenty of teams maintain one while calling it the other. They’re genuinely different artifacts, though, and the difference explains a frustration almost every data team eventually hits: both documents drift out of date, and nobody’s sure which one to trust.

Here’s the comparison, and then the part nobody puts on the slide — why they drift, and what actually stops it.

Two artifacts, two audiences

A data dictionary describes your schema in technical terms. It’s the catalog of what physically exists: table names, column names, data types, nullability, keys, constraints. Its audience is the people who build against the database — engineers, analysts, report writers. A row in a data dictionary reads like cust_no · VARCHAR(20) · PK · not null · customer identifier.

A business glossary defines your organization’s language, independent of any one system. Its audience is the business: what does “Customer” actually mean here — a person who has paid, or anyone who has registered? What counts as an “Active Account”? A glossary entry is a term plus, above all, a definition — the agreed meaning — and it’s meant to be vendor- and table-neutral. This is the artifact the data-governance world (DAMA-DMBOK, and tools like Collibra, Alation, and Microsoft Purview) treats as a first-class deliverable.

The one-line version: a data dictionary tells you what the database has; a business glossary tells you what your words mean. You need both, because a column named cust_no is useless to a new analyst who doesn’t know that “customer,” here, excludes trial accounts.

Why they drift apart

Notice what’s true of both definitions above: they’re usually kept somewhere other than the schema itself.

The data dictionary is often a spreadsheet, or a wiki page, generated once and then maintained by hand. The moment someone runs a migration — adds a column, renames one, changes a type — the dictionary is wrong and nobody updated it. This is the classic failure: the dictionary describes the database as it was the day someone last cared.

The business glossary is worse off, because it lives even further from the code — in a governance platform, or a Confluence space, owned by a different team than the one writing migrations. The glossary says “Customer Number: the unique identifier assigned to a customer at registration.” The database has a column cust_no. Nothing connects those two sentences. No tooling checks that the column called cust_no actually implements the term “Customer Number,” or that its definition still matches. The link is a human’s memory, and memory doesn’t survive re-orgs.

So the real problem isn’t “which artifact do I need.” It’s that both are copies of information whose source of truth is elsewhere — and copies rot. The dictionary is a copy of the schema. The glossary is a copy of intent that never got attached to the schema at all.

The question worth asking

Instead of “data dictionary or business glossary,” ask: where does a term’s definition live, and is it the same place the column is defined?

If the answer is “different documents, different tools, different owners,” you’ve already accepted drift — you’re just choosing how often to reconcile it. If the answer is “the same place,” drift has nowhere to start.

That reframing is what a model gives you, and it’s the layer we build Sqemo around. Instead of a physical schema plus two documents about it, you keep one logical model: business terms (“Customer”, “Customer Number”, “Order Date”), each carrying its own definition, with physical names (CUST, CUST_NO, ORD_DT) generated from a glossary and naming rules rather than typed by hand.

In that setup the two artifacts stop being separate:

• The data dictionary is just an export of the physical side of the model — always current, because the model is the schema, not a description of it.
• The business glossary is a view over the same model: every distinct term, its definition, the domain and type it resolves to, and every place it’s used. Change a definition once and it’s the definition everywhere that term appears — because the definition is attached to the term, not copied into a doc.

And because the term and its physical name are the same object, the connection the wiki-plus-glossary setup was missing is structural. npx sqemo-mcp lint can fail a pull request when a physical name drifts from what the standard says it should be — the check the two-document world can’t run, because in that world nothing knows that cust_no is supposed to be “Customer Number.”

This mirrors how the international metadata standard ISO/IEC 11179 frames it: data-element names (Part 5) and their definitions (Part 4) belong to the same registry entry, not to separate systems — and it’s the shape Sqemo’s word / term / domain dictionaries take.

Where a real catalog still wins

Honesty check: collapsing the two into a model is the right move when your problem is “the definitions and the schema keep drifting apart.” It is not a replacement for an enterprise data catalog, and if that’s what you need, use one.

A model scoped to your ERD doesn’t give you cross-system lineage (which report consumes which column, three hops back), stewardship workflows (proposal, approval, certification of a term across a whole company), policy and access governance, or a glossary that spans dozens of source systems you don’t model in one place. Collibra, Alation, and Purview exist for that scale, and they earn their price when data governance is an org-wide program with dedicated owners.

The gap they don’t fill well is the everyday one: a single team, one or a few databases, who just want their schema and its meanings to stop disagreeing. For that, a separate governance platform is heavy machinery aimed at a bigger problem — and the glossary in it still isn’t connected to the columns your engineers actually ship.

So which do you need?

A traditional data dictionary is enough if: you have a schema, definitions rarely matter beyond the technical, and you’re disciplined about regenerating the doc from the live database (generate it — don’t hand-maintain it).

A full governance platform (Collibra / Alation / Purview) is the right tool if: data governance is a funded, org-wide program — lineage across systems, stewardship workflows, policy enforcement, dozens of sources.

A model that carries both is the fit if: you’re a team who keeps rewriting the same “what does this mean” doc and watching it drift from the schema — and you’d rather the dictionary and the glossary be two views of one source than two documents about it.

Trying the third option costs nothing and takes a schema you already have: open the app — no signup, your project is a local file — import your SQL or DBML, and the Definitions view is populated from it. Add definitions once; export the dictionary and the glossary whenever an auditor asks.