Kindly fill up the following to try out our sandbox experience. We will get back to you at the earliest.
A business glossary defines what a term means and the business owns it. A data dictionary describes fields and engineering owns it. A data catalog indexes both.
Updated on
A business glossary is the business record of what a term means. A data dictionary is the engineering record of what a field contains. A data catalog is the index that finds both. The glossary answers what we mean by revenue, the dictionary answers what the column orders.net_amount stores, and the catalog answers where either of them lives.
The pair that trips teams up is the glossary against the dictionary, because both look like lists of definitions. They differ on who decides. A glossary term changes when finance changes its mind about what counts as an active customer. A dictionary entry changes when an engineer alters a column. Same word, different authority.
| Business glossary | Data dictionary | Data catalog | |
|---|---|---|---|
| What it records | The business meaning of a term | The technical structure of a field | An inventory of every data asset |
| Who owns it | The business, through a named term owner | Engineering, through the team that owns the table | Both, usually a governance lead with platform support |
| Who reads it | Analysts, finance, product, compliance, anyone in the company | Engineers and analysts writing queries | Anyone looking for data |
| Unit of entry | A term, such as active customer | A column, such as orders.net_amount | An asset, such as a table, a model or a dashboard |
| What it is the authority for | What counts, and what does not | What is stored, and in what form | What exists, and where |
| What triggers a change | A business decision | A schema change or a migration | A new source, asset or connection |
| Where the content comes from | Written by people who own the term | Mostly generated from the schema, then described | Crawled automatically from connected sources |
| Rough size | Tens to low hundreds of terms | Thousands of fields | Everything the warehouse and the BI tool contain |
Read that table down the ownership row and the rest follows. The three artifacts are not competing products to choose between. They answer three different questions and they break in three different ways, which is the part the rest of this article is about.
A business glossary is a list of the terms a company uses and what each one means, written in the language the business already speaks rather than in the language of the warehouse. It gives departments that report on the same thing a single wording to agree on, which is why it is usually the first artifact a governance program produces.
A glossary entry carries four things: the term, one sentence that defines it, the person accountable for that definition, and a link to the data that produces it. An entry missing any of the four is a note, not a glossary term.
The business owns it. Each term has a named owner, and that owner sits on the side of the company that lives with the consequences of the definition. Finance owns revenue. Sales operations owns qualified lead. Customer success owns churn. The data team hosts the glossary, keeps it connected to the warehouse and chases entries that have gone stale, but it does not get to decide what an active customer is.
This is the point most glossary projects get wrong. A data engineer writes all the definitions because the engineer is the one holding the tool, nobody in the business ever reads them, and the glossary becomes a second set of definitions competing with the ones people use in meetings. If you cannot name a person outside the data team for every term, you have written a dictionary and called it a glossary.
The glossary is the authority for meaning, and for nothing else. It settles what counts as churn, which accounts sit in the enterprise segment, and whether a refund reduces revenue in the month of the sale or the month of the refund. It says nothing about which table holds the number or what type the column is, because a question about storage has an answer in the dictionary.
A working rule: a term needs a single named owner and a definition that fits in one sentence. If the definition needs a paragraph with exceptions in it, you are usually looking at two terms that deserve separate entries, such as gross revenue and net revenue, rather than one term with a footnote.
The benefits follow from those features rather than from the artifact existing. Teams talking about the same metric use the same wording, so fewer numbers have to be reconciled after the fact. Data definitions stay consistent across reports, which shows up as better data quality without anyone touching a pipeline. New joiners learn the company vocabulary from a page rather than from six months of meetings.
The abstract version of this advice is easy to agree with and hard to act on, so here is a finished entry. The point is how little it contains.
| Field | Value |
|---|---|
| Term | Active customer |
| Definition | An account with at least one paid transaction in the previous 90 days. |
| Business owner | Head of Revenue Operations |
| Data steward | Analytics engineering, customer domain |
| Calculation logic | Counted on transaction date, not invoice date. Refunded transactions still count. |
| Linked assets | dim_customer, fct_transaction, the Monthly Revenue dashboard |
| Status | Approved, last reviewed 12 August 2026 |
| Synonyms | Live customer, paying customer |
Everything in that entry is a decision somebody in the business made. None of it is technical. The linked assets row is the one people skip and the one that does the work, because it is what lets a reader move from the word to the number without asking anyone.
The walkthrough above shows the same entry being built in Decube: the glossaries, categories and terms hierarchy on the left, data owners and business owners assigned to a term so questions have an address, custom attributes holding the calculation logic, and the linked assets tab showing which tables carry the term.
A data dictionary describes the fields in your data. For each column it records the name, what the column holds, the data type, the allowed values, and the table and source system it sits in. Where a glossary is written, a dictionary is largely generated: most of its content already exists in the schema and the work is describing it, not inventing it.
Because it operates at field level rather than concept level, a dictionary is an order of magnitude larger than a glossary. A company with 80 glossary terms will typically have several thousand dictionary entries. If your glossary is bigger than your dictionary, the glossary is being used as a dictionary and the terms in it are probably column names.
Engineering owns it, specifically the team that owns each table. The description of a column is written by whoever is accountable for the pipeline that fills it, because they are the only people who know what actually ends up in it as opposed to what was intended. The business contributes in one place only, which is confirming that a field described as the revenue field carries the number the glossary term calls revenue.
A dictionary that is maintained by hand goes stale within a quarter, because schemas change faster than anyone updates a document. The maintainable version is generated from the warehouse metadata on a schedule and enriched with descriptions, so a new column appears in the dictionary undescribed rather than not appearing at all. The field level detail, including what a data dictionary should contain, with examples and a template, is a subject of its own.
This is what a detailed data dictionary gives an organization, and what each part of it is actually for.
| Feature | Benefit |
|---|---|
| Detailed Field Descriptions | Says what each column holds in words, so an analyst does not have to infer the meaning from the column name and guess wrong. |
| Consistent Data Types | Records the type and the allowed values, so a join, a filter or a cast behaves the way the person writing the query expects. |
| Relationship Mapping | Records which keys join to which table, so a reader can follow the data across the model without opening the definitions of the tables. |
| Source System and Owner | Names the system a field comes from and the team accountable for it, so a question about a suspicious value has an address to go to. |
| Classification | Flags a field as personal or otherwise sensitive, so the same record serves an engineer writing a query and a privacy review looking for exposure. |
This is the question that most often gets asked and least often gets answered directly, so here it is in one sentence. A business glossary defines a term, a data dictionary describes a field. A glossary entry exists because people disagree about what something means. A dictionary entry exists because a column exists.
| Business glossary | Data dictionary | |
|---|---|---|
| Unit of entry | A business term, such as active customer | A column, such as customers.last_order_at |
| Who writes it | A business owner, reviewed by the data team | Generated from the schema, described by the engineer who owns the table |
| The question it answers | What do we mean by this? | What is stored here? |
| What triggers a change | A business decision | A schema change or a migration |
| Who it is written for | Anyone in the company | Anyone writing a query |
| Rough size | Tens to low hundreds of terms | Thousands of fields |
| How you know it is broken | Two teams report different numbers for the same metric | An analyst has to ask in Slack what a column means |
| Where it usually lives | A governance or catalog tool the business can reach | Generated from warehouse metadata, surfaced in the catalog |
The two are related but they are not layers of the same thing, which is the usual misreading. A glossary term can map to several dictionary fields, and a dictionary field can carry no glossary term at all, which is the normal case for the majority of columns in a warehouse. The link between them is the piece worth building: a term with the fields that produce it attached is the only version of a glossary that survives contact with a real reporting question.
A data catalog is the inventory of what data an organization has. It crawls connected sources and lists the tables, views, models, dashboards and pipelines that exist, with the metadata that makes each one findable: where it came from, who owns it, when it last updated, and how it is classified. Where the glossary holds meaning and the dictionary holds structure, the catalog holds the inventory and the pointers between the other two.
The gains are practical. More of the company can find data without asking an engineer, which is the whole argument for a catalog. A compliance reviewer can see what exists and how it is classified without a discovery exercise. Access requests start from a named asset with a named owner rather than from a description of a table someone half remembers.
These two get confused because a catalog contains dictionary style metadata. The difference is scope. A dictionary describes the fields inside a table. A catalog inventories the tables, models and dashboards themselves, and points at the dictionary entries underneath each one. Put another way, the dictionary is what you read once you have found the asset, and the catalog is how you found it.
That pair deserves more room than a page about the glossary should give it, so we treat it in full in our comparison of a data catalog and a data dictionary, and the wider question of how a catalog manages metadata in our data catalog and metadata management guide. This page stays on the glossary.
Every page on this topic says the three artifacts complement each other. Almost none of them say what actually goes wrong when one is missing, which is the part that tells you whether to spend money. Here are the three cases and a test for each.
The symptom is that the definition of active customer is approved and published, and nobody can produce the number. The glossary says what the company means. Without a dictionary underneath it, no entry says which column carries it, so analysts pick the field whose name looks closest and two of them pick differently. The glossary passes an audit and changes nothing in a report.
The test: pick five approved terms and ask which table and which column produce each one. If you cannot answer for three of the five, the glossary is unlinked and the fix is to attach assets to terms before writing any more terms.
The symptom is that every column is documented and the monthly numbers still disagree. A dictionary can tell you that orders.net_amount is a decimal in United States dollars excluding tax. It has no way to record whether a refund belongs in the month of the sale or the month of the refund, because that is a business decision rather than a property of the column. With nowhere to record it, the decision gets made again in every meeting and differently each time.
The test: ask two teams to write the definition of your headline metric on separate sheets without conferring. Different sentences means the dictionary was never the missing piece and a glossary is.
The symptom is a search that returns forty tables with plausible names and no way to choose between them. A catalog inventories what exists. Meaning comes from the glossary and structure from the dictionary, so without them a catalog is a list of asset names with a search box attached, and adoption falls away inside the first quarter after rollout.
The test: search your catalog for your headline metric using the business word rather than a table name. If the top result is a table rather than a defined term with an owner and linked assets, the catalog has nothing to point at.
The differences reduce to authority. The glossary is the authority for what a term means, the dictionary is the authority for what a field holds, and the catalog is the authority for what exists and where. When a page describes all three as documentation, the reader has no way to tell which one to consult, and every one of them ends up half maintained.
The relationships run one way. The catalog is populated automatically from the sources and generates most of the dictionary as a by product. The glossary is written by people and then attached to what the catalog found. A term points down to fields, a field points up to the term it helps produce, and the catalog holds both ends. That chain is the part worth building, and it is also the part that is missing in most implementations, which run all three as separate documents that never reference each other.
Integration is worth something specific rather than in general. Linked together, a person can start from a business term, see the definition and its owner, follow the link to the tables that produce it, read the field descriptions in the dictionary, and check when the data last updated, without leaving the tool or messaging anyone. That path is the one measurable outcome of the three artifacts existing together.
It also runs backwards, which is where the compliance value sits. Starting from a column flagged as personal data, a reviewer can see which glossary terms depend on it and which reports use those terms, which is the same chain a regulator asks for. Handled as one linked set, the answer is a query. Handled as three documents, it is a project. That chain is also what a data governance program has to produce before any policy written on top of it can be enforced.
Choose by the symptom you actually have rather than by which artifact sounds most complete.
For a mid market team on a warehouse such as Snowflake, the sequence that holds up is this. Connect the warehouse to a catalog first, so the dictionary populates itself from the information schema instead of being typed by hand and going stale. Then write glossary terms for the metrics that appear in the board pack and nowhere else to begin with, twenty at the outside. Give each term a named business owner. Link each term to the table and column that produce it, and treat an unlinked term as unfinished. Only then widen the glossary to the second tier of metrics.
The order that fails is the common one: writing a glossary in a spreadsheet before anything is connected. It produces a document with no assets attached, no way to tell when a definition has drifted from the data, and no owner who feels responsible for it because nothing in the reporting stack depends on it.
Decube runs all three in one platform, which is what makes the links between them hold rather than decay. The catalog connects to the warehouse and populates the dictionary automatically, so field names, types and lineage arrive without anyone typing them, and a new column shows up undescribed rather than not showing up.
The business glossary and data dictionary software sits on top of that. Glossaries, categories and terms are organized in a hierarchy the business can navigate, each term carries a data owner and a business owner, custom attributes hold calculation logic or reporting cadence, approval workflows control changes to a definition, and a linked assets view shows exactly which tables carry a term. That last piece is the one that decides whether a glossary gets used.
Governance policy, classification and column level lineage run over the same metadata, so a term, the field behind it and the pipeline that produced it form one chain rather than three tools that have to be reconciled. For teams in regulated sectors, the same chain is what produces evidence when a regulator asks which reports depend on a given sensitive field.
If you want to see what a linked glossary looks like against your own warehouse rather than in a demo dataset, request a demo and bring the metric your teams argue about most.
The three artifacts are easy to tell apart once you stop asking what each one contains and start asking who decides. Meaning is a business decision and belongs in the glossary. Structure is a property of the data and belongs in the dictionary. Existence is a fact about the estate and belongs in the catalog. Every argument about which tool to buy is really an argument about which of those three questions is currently going unanswered in your company.
For most teams the unanswered one is meaning, which is why the business glossary is usually the right place to start and why it is the artifact most often built badly: written by the data team, unlinked to any asset, and abandoned within two quarters. A glossary with owners attached and tables linked underneath is a different object entirely, and it is the one that stops two teams reporting different numbers for the same metric.
A business glossary defines a term, and a data dictionary describes a field. A glossary entry such as active customer records what the business means, who owns that meaning, and which data produces it. A dictionary entry such as customers.last_order_at records the column name, its data type, its allowed values and the table it sits in. The glossary changes when the business makes a decision. The dictionary changes when someone alters a schema. A company will usually have tens to low hundreds of glossary terms and several thousand dictionary fields.
A business glossary holds meaning and a data catalog holds inventory. The glossary answers what a term means and who decided that, in the language the business uses. The catalog answers what data exists and where it lives, by crawling connected sources and listing every table, model and dashboard with its owner, its freshness and its classification. Most catalog products include a glossary feature, which is why the two are often confused, but they answer different questions and they are owned by different people: the business owns the glossary, while the catalog is jointly owned by a governance lead and the platform team.
A data glossary, also called a business glossary, is a list of the terms a company uses and what each one means, written in business language rather than technical language. A finished entry has four parts: the term, a definition of one sentence, a named owner who is accountable for that definition, and a link to the data assets that produce the number. An entry missing any of those four is a note rather than a glossary term.
A worked entry looks like this. Term: active customer. Definition: an account with at least one paid transaction in the previous 90 days. Business owner: Head of Revenue Operations. Calculation logic: counted on transaction date, not invoice date, and refunded transactions still count. Linked assets: dim_customer, fct_transaction and the Monthly Revenue dashboard. Status: approved, with a review date. Synonyms: live customer, paying customer. Everything in that entry is a decision the business made, and the linked assets row is the one that decides whether anyone uses it.
A corporate data dictionary is a single dictionary covering every source system in the organization rather than one per database or one per team. It records, for each field, the column name, what it holds, the data type, the allowed values, the source system, the team accountable for it and any sensitivity classification. At enterprise size it has to be generated from warehouse metadata on a schedule rather than maintained by hand, because schemas change faster than anyone updates a document, and a hand kept dictionary goes stale within a quarter.
A product data glossary is a business glossary scoped to product and usage terms rather than to finance terms: activation, active user, session, feature adoption, trial conversion and the like. The rules are the same as any glossary. Each term needs a single named owner in the product or growth organization, a definition of one sentence, and a link to the events or tables that produce it. Product terms drift faster than finance terms because instrumentation changes with every release, so a review date on each term matters more here than anywhere else.
The difference is scope. A data dictionary describes the fields inside a table, down to column names, types and allowed values. A data catalog inventories the assets themselves, the tables, models, dashboards and pipelines, and points at the dictionary entries underneath each one. The dictionary is what you read once you have found the asset, and the catalog is how you found it. Most catalog products generate the dictionary automatically from connected sources, which is why the two are often described as one thing.
The features that matter are access without a paid data tool seat, search that works on the words the business uses including synonyms, a named owner on every term, links from each term to the assets that produce it, and version history with an approval step. The benefits follow from those features rather than from the glossary existing: fewer numbers to reconcile because teams use the same wording, more consistent definitions across reports, a place to send a disputed definition, and new joiners learning the company vocabulary from a page instead of from six months of meetings.
A data catalog searches on business words rather than only table names, keeps comments, questions and ratings next to the asset itself, collects metadata automatically from connected sources on a schedule, and maps lineage between assets so an engineer can see what breaks if a table changes. The gains are that more of the company can find data without asking an engineer, a compliance reviewer can see what exists and how it is classified without running a discovery exercise, and access requests start from a named asset with a named owner.
They complement each other through links rather than through coexistence. The catalog is populated automatically from connected sources and generates most of the dictionary as a by product. The glossary is written by people and then attached to what the catalog found. A term points down to the fields that produce it, a field points up to the term it serves, and the catalog holds both ends. The measurable outcome is that a person can start from a business term, read the definition and its owner, follow the link to the tables behind it, read the field descriptions and check when the data last updated, without leaving the tool or messaging anyone.
Connect Snowflake to a catalog first, so the dictionary populates itself from the information schema instead of being typed by hand. Then write glossary terms only for the metrics that appear in the board pack, twenty at the outside. Give each term a named business owner outside the data team. Link each term to the table and column that produce it, and treat an unlinked term as unfinished. Only then widen to the second tier of metrics. The order that fails is writing the glossary in a spreadsheet before anything is connected, because it produces a document with no assets attached and no way to tell when a definition has drifted from the data.
The glossary is usually the first artifact a governance program produces and the one the rest depends on. Policy is written about terms, so classification, retention and access rules need agreed definitions before they can be applied to anything. It also produces the evidence chain a regulator asks for: starting from a field flagged as personal data, a reviewer can see which glossary terms depend on it and which reports use those terms. Handled as one linked set, that answer is a query. Handled as three separate documents, it is a project.
First step to AI Readiness
Table of Contents
Sneak peek from the data world.
Bring lineage, quality, governance, and AI together in one platform—so your teams and AI agents can act with confidence.
_For%20light%20backgrounds.svg)
.svg){kind=small}
.webp)