What Is Metadata? Definition, Types, and Examples for Data Teams

Ask a data engineer what metadata is and you’ll probably get some version of “it’s data about data.” The phrase is accurate, but it doesn’t tell you much about what metadata looks like in a warehouse, a pipeline, or a dashboard, or why so many data problems trace back to it.

In practice, metadata is the record that makes a data asset usable. A table without metadata is a grid of values. With metadata, you know what each column means, when the table last refreshed, which job produced it, and who to ask when the numbers look wrong. That record sits underneath every data catalog and context platform, and AI agents now depend on it just as much as people do.

What is metadata?

The National Information Standards Organization (NISO) defines metadata as structured information that describes, explains, or locates a resource, or makes that resource easier to retrieve, use, or manage. That definition is more useful than “data about data” because it names the jobs metadata does. Carnegie Mellon University Libraries goes further, calling the shorthand too vague to be useful on its own.

For a data team, the difference between data and metadata is easiest to see in a single table. Take fct_orders, an orders fact table in a cloud data warehouse:

• Data: the rows themselves, such as order IDs, customer IDs, order amounts, and timestamps
• Metadata: everything that describes those rows, such as the schema, column descriptions, owning team, last refresh time, the dbt model that builds the table, and the dashboards that read from it

However, the line between the data and metadata isn’t fixed. For example, query logs are data to a team analyzing warehouse costs and metadata to a team working out which tables matter most. Pipeline run history works the same way. Whether something counts as metadata depends on what it describes and who’s using it.

Much of this metadata isn’t written by hand: Warehouses, orchestrators, transformation tools, and BI platforms generate it as a byproduct of doing their jobs. People add the layer systems can’t infer, such as what a metric means or which table is the approved source for a report.

Three types of metadata: traditional categorization

The most widely cited taxonomy comes from library and archive practice, where formal metadata standards first took shape.

NISO distinguishes three main types of metadata:

1. Descriptive metadata identifies a resource and helps people find it. In a data context, that means metadata elements like names, descriptions, tags, and keywords.
2. Structural metadata describes how the parts of a resource are organized and relate to each other, such as tables within a schema or columns within a table.
3. Administrative metadata supports managing a resource over time, including its creation date, who can access it, how long to retain it, and where it came from.

This framework holds up, even though it was really designed for books, archives, and digital collections. However, data teams tend to sort metadata by the questions they need answered, which leads to a slightly different set of categories.

The types of metadata data teams work with

In a modern data stack, metadata usually falls into technical, operational, and business categories, with lineage connecting all three. The table below shows each type for fct_orders and how it maps to the classic taxonomy.

Type	Question it answers	Example for fct_orders	Closest classic type
Technical	What is this, and how is it built?	Column names, data types, partition key, storage location	Structural
Operational	Is it healthy and current?	Last refresh time, row count, quality check results, query frequency	Administrative
Business	What does it mean, and who owns it?	Column descriptions, the glossary term “net revenue,” owning domain and team	Descriptive
Lineage	Where did it come from, and what depends on it?	Source tables, the dbt model that builds it, downstream dashboards	Administrative (provenance)

Technical metadata

Technical metadata describes the physical shape of a data asset. It covers schemas, column names, data types, primary and foreign keys, partitioning, file formats, and storage location. Most of it comes directly from the data repository that stores it, whether that’s a warehouse, a lakehouse, or an operational database. Engineers rely on technical metadata to write correct queries and to catch breaking changes, such as a column that switched from integer to string.

Operational metadata

Operational metadata describes what happens to a data asset over time. It includes pipeline run history, refresh times, row counts, data quality check results, and usage patterns like how often a table gets queried and by whom. Operational metadata is how you tell whether a table that was correct last week is still correct today.

Business metadata

Business metadata connects data to what it means for the organization. Column descriptions, business glossary terms, metric definitions, domains, and ownership all belong here. A data element like a column named amt tells you almost nothing on its own. Business metadata tells you it holds order value in USD, net of discounts, and that the finance data team owns it.

Governance signals such as sensitivity classifications and access policies cut across all three categories. A PII tag carries business meaning, and access controls often depend on it.

Lineage

Lineage is metadata about relationships. It records which upstream sources feed a table, which transformations shaped it, and which downstream tables, dashboards, and models depend on it. Lineage lets you trace a broken dashboard back to a failed job, or check what will break before you change a column. Learn more about data lineage in data governance.

Where does metadata come from?

Metadata accumulates across the whole data stack, and each layer contributes something different:

• Source systems and warehouses expose schemas, data types, table sizes, and access logs.
• Orchestration and transformation tools produce run history, job dependencies, and the transformation logic behind each table.
• BI tools show which dashboards and reports read from which tables.
• Query logs capture how people actually use data, including common joins, standard filters, and the tables they reach for most.
• People contribute descriptions, glossary definitions, ownership, and the institutional knowledge no system records on its own.

Because metadata lives in so many places, each tool holds only a partial view. The warehouse knows the schema but not the business definition. The BI tool knows the dashboard but not the upstream job that failed at 3 AM. A data catalog brings those fragments together so people can search and understand them in one place.

Why metadata goes stale

Metadata describes systems that change constantly. Schemas evolve, pipelines get restructured, owners move teams, and metric definitions get revised. Every change can leave a description, tag, or ownership record pointing at something that’s no longer true.

Stale metadata can do more damage than missing metadata. When a table has no description, people know to ask someone. When a table has an outdated description, people trust it and build on it. The same risk applies to any system that reads metadata automatically.

That’s why metadata is most useful when it’s collected continuously from the systems that generate it, rather than documented once and left alone. Keeping metadata accurate at scale takes proper metadata management.

Why metadata matters for data teams

Much of the everyday friction on data teams traces back to metadata. Good metadata supports:

• Discovery: Finding the right table without posting in Slack and waiting for someone who remembers
• Trust: Checking freshness, quality, and certification status before using a table in a report
• Debugging and impact analysis: Tracing a bad number upstream to its source, or seeing every downstream asset before changing a schema
• Governance and compliance: Knowing where sensitive data lives, who owns it, and how data access is controlled

These uses overlap more than separate tools suggest. When a dashboard breaks, the question “what produced this, and is it healthy?” requires lineage, quality signals, ownership, and business context at the same time. That overlap is why data lineage and data catalogs work best as parts of the same system.

Why metadata is important for AI agents

AI agents that work with enterprise data face the same questions an analyst does, but they can’t lean over and ask a colleague. An agent writing SQL needs to know which table is authoritative, what a column means, whether the data is current, and whether it’s permitted to use that data. Metadata is how the agent finds out.

DataHub’s guide, 10 Principles of Enterprise Context Platforms, describes technical and operational metadata as the foundation of the context agents need. A business definition tells an agent what a column is supposed to mean. Technical and operational metadata tells the agent whether the data behind that definition passed its latest quality check, whether the pipeline feeding it ran successfully, and whether its schema changed recently. Without that foundation, an agent can deliver a confident answer built on the wrong data.

Pinterest offers a public example: Its data platform team built an analytics agent that helps analysts discover tables, find reusable queries, and generate SQL from natural language. To make that work, the team enriched historical SQL queries with glossary terms, table descriptions, and metric definitions from DataHub. The Pinterest customer story reports that the Analytics Agent became the company’s most-used internal agent, with 10x the usage of the next agent. Pinterest Engineering has published a detailed account of the architecture.

Data leaders increasingly treat this layer as AI infrastructure. In the State of Context Management Report 2026, 83% of IT and data leaders agree that agentic AI can’t reach production value without a context platform. A context platform unifies technical metadata with business knowledge and documentation, so agents get the same governed, current context people rely on. Learn more about context engineering.

Metadata is how data explains itself

Metadata is the working record of what your data is, where it came from, and whether it can be trusted. Data teams have relied on that record for years to find, debug, and govern data. Now that AI agents use the same data as the people around them, keeping metadata accurate and current matters more than ever.

FAQs

What is metadata, and what are some examples?

Metadata is structured information that describes data so people and systems can find, understand, and use it. Common examples in a data stack include table schemas, column data types, column descriptions, table owners, last refresh times, data quality check results, and lineage showing which jobs and dashboards connect to a table.

What is the purpose of metadata?

The purpose of metadata is to make data usable without inspecting the data itself. Metadata helps people and systems find the right data, understand what it means, judge whether it’s current and trustworthy, and control who can access it. For data teams, metadata also supports debugging, impact analysis, and compliance.

Which best defines metadata?

The most precise definition describes metadata as structured information that describes, explains, or locates a resource, or makes it easier to retrieve, use, or manage. “Data about data” is the common shorthand, but it leaves out what metadata does. For data teams, metadata answers what an asset is, where it came from, and whether to trust it.

What are the three main types of metadata?

The three main types of metadata are descriptive, structural, and administrative. Descriptive metadata identifies a resource, structural metadata describes how its parts are organized, and administrative metadata supports managing it over time. Some frameworks also list preservation metadata separately, which records what’s needed to keep a resource usable long term. Data teams often use a parallel set of categories instead: technical, operational, and business metadata, with lineage connecting them.

What’s the difference between data and metadata?

Data is the content itself, such as the rows in an orders table. Metadata describes that content, such as the table’s schema, owner, refresh time, and lineage. The line can shift depending on use. Query logs, for example, are data to a team analyzing warehouse costs and metadata to a team studying which tables matter most.

What’s the difference between metadata and metadata management?

Metadata is the information that describes data assets. Metadata management is the area of data management focused on collecting, organizing, governing, and maintaining that information across an organization so it stays accurate and useful as systems change. Learn more in DataHub’s guide to metadata management.