OpenMetadata Data Quality and Data Catalog

OpenMetadata data testing

OpenMetadata runs table and column tests such as row counts, freshness and custom SQL, compares tables with a table diff test, and supports data contracts that attach schema, quality tests and SLAs to an asset.

Compare: data contracts tools · data testing tools · data comparison tools

• SQL Table Tests: Native table-level tests include tableRowCountToEqual, tableRowCountToBeBetween, tableColumnCountToEqual, tableCustomSQLQuery, tableDataToBeFresh, tableRowInsertedCountToBeBetween, and tableDiff, all configurable via UI or YAML (docs).

• Table Comparison Tests: The tableDiff test compares two tables across different database services using keyColumns to match records and counts the number of mismatched rows against a configurable threshold (docs).

• Data Contracts: Data Contracts are a first-class entity: they define schema, quality test references, SLA guarantees (refresh frequency, latency, availability), and governance rules. Contracts have Draft, Active, and Deprecated statuses and are enforced via validation endpoints (docs).

• DataFrame Tests: No support for DataFrame or in-memory data testing documented; OpenMetadata targets warehouse and pipeline metadata rather than Spark/pandas DataFrames (docs).

• Unstructured Data Tests: No unstructured data testing (documents, images, free text) documented; the platform focuses on structured database and warehouse tables (docs).

• Data Diff: The tableDiff test returns an aggregate count of mismatched rows rather than surfacing individual differing records; no row-level diff capability is documented (docs).

• Inspect Failed Rows: No documentation found for viewing or navigating the actual rows that triggered a failing test; the incident manager docs focus on triage and resolution workflows rather than row-level inspection (docs).

OpenMetadata data observability

OpenMetadata profiles tables and columns and detects anomalies on profiled metrics, learning seasonal trends. Monitors are configured in the UI or in YAML and JSON files.

Compare: data profiling tools · data observability tools

• Data Profiling: The data profiler computes table-level metrics (row count, column count, DML operations) and column-level metrics (null count/proportion, distinct/unique counts, min, max, mean, median, sum, standard deviation, histogram, quartiles, IQR, nonparametric skew) for all connected database connectors (docs).

• Anomaly Detection: Anomaly detection continuously profiles data over time using ML to learn natural variation patterns including seasonal trends; it automatically generates incidents when deviations from learned baselines are detected. Typically requires ~5 weeks of profiling history (docs).

• Freshness Monitors: tableDataToBeFresh test monitors how long ago data was last updated. DML tracking (for BigQuery, Redshift, Snowflake) records ingestion timestamps, and the anomaly detection system monitors freshness deviations (docs).

• Volume Monitors: Row count tests (tableRowCountToEqual, tableRowCountToBeBetween) and the tableRowInsertedCountToBeBetween test monitor volume within a specified date/time range. Anomaly detection also learns expected row count patterns (docs).

• Schema Monitors: Schema modification events trigger observability alerts; the alert system explicitly lists schema modifications as a supported trigger type alongside data quality failures (docs).

• Field Monitors: Column-level tests (null count, uniqueness, value range, regex, value sets, statistical measures) and per-column profiling metrics (mean, median, stddev, histogram) provide field-level monitoring (docs).

• Distribution Monitors: The data profiler computes histogram, first/third quartiles, inter-quartile range, and nonparametric skew per column, enabling distribution-level monitoring through profiling metrics tracked over time (docs).

• Custom SQL Monitors: The tableCustomSQLQuery test lets users write arbitrary SQL with either ROWS (validates individual row results) or COUNT (validates aggregate count) strategies and configurable thresholds (docs).

• Partition-Based Monitors: The profiler supports partition-based data scanning with four partition types: TIME-UNIT (business timestamps), INGESTION-TIME (process timestamps), COLUMN-VALUE (categorical partitions), and INTEGER-RANGE, each with configurable interval and unit settings (docs).

• UI-Based Monitors: No-code test creation directly from the UI is a core feature; users configure table and column tests through form-based interfaces without writing YAML or code (docs).

• Monitors-as-Code: Tests can be defined in YAML or JSON config files with testDefinitionName and parameterValues, enabling version-controlled, code-based test definitions that can be deployed programmatically during data ingestion (docs).

• Segment Monitors: No GROUP BY or segment-based monitoring (evaluating metrics per distinct dimension value) is documented in the data quality or profiler documentation (docs).

• Window-Based Monitors: The tableRowInsertedCountToBeBetween test accepts a date/time range parameter but is not documented as a general-purpose time-window monitoring framework; no sliding or tumbling window monitor concept is described in the docs (docs).

• Pipeline Monitoring: Pipeline observability tracks execution status (success/failed/pending/aborted) and timestamps for pipelines that produce or consume tables, but dedicated tracking of job durations and schedule adherence is not explicitly documented for the open-source version (docs).

OpenMetadata incident management

OpenMetadata opens incidents when tests fail and tracks them through triage and resolution. It has no ticketing or on-call integrations.

• Alert Notifications: Observability alerts can be delivered to Email, Slack, Microsoft Teams, Google Chat, and Generic Webhooks. Triggers include data quality failures, schema modifications, pipeline failures, and metadata change events (docs).

• Incident Triage: The Incident Manager supports acknowledging issues, assigning responsibility to specific people or teams, logging the root cause, and setting severity — providing a structured triage workflow for each test failure (docs).

• Incident Resolution: Incidents can be marked as resolved with a required reason and comments; historical incident records with timelines, comments, and collaboration history are maintained as a troubleshooting reference (docs).

• Ticketing Integrations: Alert documentation lists Email, Slack, Microsoft Teams, Google Chat, and Generic Webhooks as the only notification destinations; Jira and ServiceNow ticketing integrations are not documented (docs).

• On-Call Integrations: PagerDuty and Opsgenie are not listed among the supported alert notification destinations; only Email, Slack, Teams, Google Chat, and Generic Webhooks are documented (docs).

• Alert Feedback: No explicit alert feedback mechanism (e.g., marking an alert as expected/not anomalous to train future thresholds) is documented in the incident manager or anomaly detection docs (docs).

OpenMetadata data quality analytics

OpenMetadata shows test results on data quality dashboards.

• Data Quality Dashboards: A Data Quality health dashboard displays total tests run with pass/fail/aborted counts, per-table test status summaries, and time-filtered report views for monitoring quality trends (docs).

• Incident Resolution Metrics: Incident Manager provides per-incident workflow (assignee, status, RCA, timeline) as a 'troubleshooting handbook' but no MTTD/MTTR dashboard, incident volume trends, or resolution-rate-by-team reporting (docs).

• Data Health Scores: No explicit data health score metric (a composite numerical score for an asset or domain) is documented; the quality tab shows pass/fail counts but not a derived score (docs).

OpenMetadata data lineage

OpenMetadata extracts lineage automatically from databases, pipelines and dashboards, at table and column level, with impact analysis.

Compare: data lineage tools

• Table-Level Lineage: Table-level lineage is automatically extracted from data warehouses and dashboards, and can also be configured manually via the UI or created programmatically through the Python SDK (docs).

• Column-Level Lineage: Rich column-level lineage is supported, extractable automatically from warehouse query history and editable manually through the UI (docs).

• End-to-End Lineage: Lineage spans databases, pipelines, and dashboard entities, connecting sources to transformations to BI consumers across the full data stack (docs).

• Impact Analysis: Impact analysis is explicitly described as a core lineage benefit; the platform shows data traceability and how upstream changes propagate to downstream dependencies through the lineage graph (docs).

OpenMetadata data governance

OpenMetadata's catalog, glossary, classification and data products cover data governance.

Compare: data catalog tools · open-source data governance tools · data stewardship tools · data classification tools

• Data Catalog: Data discovery and cataloging is the core purpose of OpenMetadata, with 80+ connectors across databases, pipelines, dashboards, messaging, and ML models; assets include rich metadata, ownership, tags, domains, and a business glossary (docs).

• Data Classification: Auto-Classification workflow classifies database columns by sensitivity category using column-name regex scanning and NLP-based entity recognition on sample data (docs).

• Data Products: OpenMetadata natively supports Data Mesh with Domains and Data Products as first-class entities (with owners, SLAs, quality metrics), and Data Product is a top-level Explore filter usable in Data Quality parameters (docs).

• Data Catalog Integration: OpenMetadata is itself a data catalog; no documentation found for pushing quality metadata out to a separate external catalog system (Atlan, Alation, Collibra, etc.) (docs).

OpenMetadata LLMOps

• AI Observability: No LLM or AI model observability (tracking LLM call quality, hallucination rates, prompt performance) is documented (docs).

OpenMetadata workflows

OpenMetadata has a REST API, a Python SDK, webhooks, an MCP server and a dbt integration, so you can manage tests and metadata from code.

• Scheduling: Test suite pipelines and profiler workflows are deployed with a configurable schedule via the UI; the platform uses Apache Airflow as its pipeline scheduler (docs).

• Webhooks: Generic Webhooks are a supported alert destination for observability events including data quality failures, schema modifications, and pipeline status changes (docs).

• REST / GraphQL API: A comprehensive REST API covers all metadata entities, data quality test definitions/suites/cases, governance, lineage, and discovery operations (docs).

• MCP Server: MCP Server ships installed and enabled by default, exposing a Semantic Search Tool for natural language vector search over metadata, with OAuth 2.0 / personal access token / bot JWT authentication and connection guides for Claude Desktop, Cursor, VS Code, Claude Code, and Goose (docs).

• Python SDK: The openmetadata-ingestion Python package provides a typed SDK for creating, updating, and querying all metadata entities including tables, databases, ML models, and test cases via pydantic-validated classes (docs).

• dbt Integration: OpenMetadata ingests dbt artifacts to extract models, SQL queries, lineage, test configurations and results, descriptions, tags, ownership, and tiers from both dbt Core (via cloud storage) and dbt Cloud (via direct API) (docs).

• CI/CD Integrations: No dedicated CI/CD integration or pipeline quality gate is documented; dbt artifacts from CI/CD workflows can be ingested, but this is metadata ingestion rather than a quality gate (docs).

OpenMetadata AI agents

OpenMetadata writes tests from plain-language prompts and ships an MCP server, so AI agents can search and use its metadata. AI agents and chat are in Collate, the managed version.

• Natural Language Test Generation: Same AI capability (AskCollate/Collate AI, built on OpenMetadata) generates data quality test cases from a natural-language prompt rather than only from unprompted profiling (docs).

• AI Chat Assistant: The MCP documentation covers connecting external assistants such as ChatGPT or Claude to OpenMetadata metadata; no built-in chat assistant is documented (docs).

• Automated Test Generation: No automated AI-powered test suggestion or auto-deployment of quality monitors is documented in the open-source version; test creation requires manual UI or YAML configuration (docs).

• AI Issue Triaging: Automated AI-driven issue triaging is not documented for the open-source version; AI-powered features (AskCollate, AI Agents) are exclusive to Collate, the managed commercial version of OpenMetadata (docs).

• AI Issue Resolution: Automated AI-driven resolution suggestions are not documented for the open-source version; AI capabilities (AI Studio, AI SDK) are listed as Collate-exclusive features (docs).