OpenMetadata data quality and profiler configuration guide

How to configure OpenMetadata data quality and profiler settings

To configure OpenMetadata data quality and profiler settings, you decide three things for each high-value table: which tests run, how the profiler samples the data, and which owner receives the failure. Those choices determine whether owners trust the catalog or learn to ignore it. The situation usually looks the same. The catalog is live, owners expect tests they can rely on, the warehouse bill is climbing because profiling queries read more data than anyone planned, and alert channels fill with failures nobody can act on. Settings made once at ingestion rarely hold up as the estate grows, so treat this as a configuration decision that you revisit on a schedule.

The topic covers four connected areas. Data quality tests assert conditions on tables and columns, such as expected values, ranges, nulls or row counts, and their results are stored against the asset they describe. The profiler collects column statistics, and its sampling settings control how much of each table it reads. Freshness checks confirm that a table was updated within the window the business expects. Ownership routing connects each test and profile result to a person or team, so a failing check reaches someone who can fix it. Each area has its own settings, and a change in one often affects the others. A sampled profile, for example, can shift the statistics that a column test depends on.

This is harder than it looks for three reasons. First, profiling and many tests run real queries against source systems, so every setting has a compute cost, and on pay-per-query warehouses that cost is billed directly. Second, defaults change between releases. OpenMetadata 2.0.0, released on August 24, 2026, made Dynamic Sampling the profiler default, so a team that tuned settings on an earlier install may find that sampling behavior has changed after an upgrade. Confirm each default and setting name against the release you run, using the official documentation and release notes, before you copy any value into production. Third, the catalog will store failures that no one owns, and an unowned failure produces noise without action.

Routing requires decisions before the first scheduled run. Assign an owner to every tested table, decide which failures are blocking and which are informational, and agree who is notified and through which channel. Start with the tables that feed reports or regulatory extracts, then widen coverage once alert volume is understood. Ask your implementer to show the exact notification path in your release, including what happens when an owner leaves the company or a team has no named steward. As a check in a test environment (illustrative), force one failing test and confirm that the failure appears on the asset, reaches the named owner and does not trigger duplicate alerts.

OpenMetadata is released under the Apache License 2.0 and is maintained by Collate, which also offers commercial enterprise capabilities and premium support. The project supports data quality tests, profiling and freshness checks, so the configuration work in this section applies to a self-hosted installation. Confirm with Collate or the release notes which features your edition includes before you assume any of them. Record the release version in your configuration runbook so that later changes to settings can be traced to the defaults that applied at the time.

Which OpenMetadata components and settings this configuration touches

Data quality and profiling in OpenMetadata span several components rather than a single screen. The cards below map each part, the setting that controls it, and the check worth making before changes reach production. Read them together, because a change to sampling, test definitions or the scheduler shows up in results, alerts and warehouse query cost.

Profiler and sampling settings

The profiler runs inside ingestion workflows and decides how much of each table is read to compute column statistics. Sampling settings control how many rows are scanned, and therefore how much warehouse compute each run consumes. OpenMetadata 2.0 made Dynamic Sampling the profiler default, so confirm whether that default matches your cost limits and whether any tables need a fixed sample instead.

Data quality test definitions

Tests are the rules that assert expected behavior on tables and columns, such as null thresholds, value ranges or row counts. Each definition is stored in OpenMetadata and attached to an asset, so ownership of the rule matters as much as its logic. Review which tests were created in the UI and which came from code, and agree on who may edit thresholds.

Test execution and Great Expectations

Test execution depends on Great Expectations, which OpenMetadata uses as a dependency for running certain checks. Plan for its version before any upgrade, because OpenMetadata 2.0 requires migrating Great Expectations to 1.3 first. Confirm the installed version in each ingestion image, since custom images must be rebuilt against the new Python 3.12 base.

Freshness checks

Freshness checks test whether a table has been updated within an expected window, which is often the first signal that an upstream pipeline has stalled. The window depends on each source's refresh schedule, so set it per table rather than with one global value. Confirm which tables feed business reporting and start there.

Data quality results view

The results view is where test outcomes, failure history and profiler output are read by stewards and owners. Its usefulness depends on tests being tagged to the right domains and assets, so that failures can be filtered by team. Check that the people who will triage failures can open the view with the roles you have set in SSO or basic access.

Notification and ownership routing

Failures reach people only if notification rules and asset owners are set correctly. Ownership decides who receives an alert for a given table, and an empty owner field usually means alerts go unanswered. Test the full path with a deliberately failing test on a non-production asset, and confirm that the destination channels and owner assignments match your escalation policy.

Ingestion scheduler and programmatic management

The ingestion scheduler runs profiling and tests on the cadence you configure, so its schedule is the main driver of load on sources. Tests can also be created and changed through the REST APIs and the Python SDK, which suits version-controlled rule sets but adds a second path that must be reviewed. Confirm which team owns the scheduler and whether changes go through code review.

Which sampling, test and routing choices fit your warehouse and team

This table compares sampling, test scope, freshness trigger and alert routing choices in OpenMetadata data quality and profiler configuration. Read each row for when the option fits and what it adds in warehouse query load, alert volume, maintenance and steward time. The main takeaway is that sampling and test scope drive most of the query cost, while routing decides whether alerts get acted on.

Decision	Option	Operational cost	Choose it when
Profiling scope	Full-table profiling	Reads every row on each run, so warehouse query load grows with table size and schedule frequency.	Small or critical tables where exact counts and distributions matter and the warehouse has spare capacity.
Profiling scope	Sampled profiling with Dynamic Sampling	Default profiler behavior in 2.0. Lower query load, but metrics are estimates and skewed tables need sample review.	Large tables where trend metrics are enough and query cost is a constraint.
Test level	Table-level tests	Fewer checks per table, so fewer alerts and less steward review, but failures are harder to trace to one column.	Row counts, volume checks and broad completeness across many tables.
Test level	Column-level tests	More checks to triage and more upkeep when schemas change. Failures point to the affected field.	Keys, nulls, ranges and accepted values on columns that feed reports or models.
Freshness checks	Scheduled freshness checks	Queries run on the test schedule, so detection can lag by up to one interval. Simple to operate and predictable in load.	Daily or batch loads where a fixed check window is acceptable.
Freshness checks	Event-driven freshness checks	Needs pipelines to signal loads to the catalog, so alerts are timelier but depend on reliable event wiring. Confirm which triggers your version supports.	Frequently changing tables where lag matters and your pipelines can emit load events.
Failure routing	Owner-based routing	Alerts reach the asset owner, so ownership must stay current and domain teams carry steward maintenance.	Domains with clear owners who can act on failures without a central step.
Failure routing	Central data quality team queue	One triage point with less alert noise for owners, but a possible bottleneck and extra staff time per incident.	Few stewards, or regulated reporting where one team must sign off on fixes.

Build sequence for OpenMetadata profiler and data quality configuration

This sequence takes an OpenMetadata installation from a working ingestion connection to tuned data quality and profiler runs that data owners act on. Each step closes with a check the platform team can confirm before moving on. The result is a small, owned set of tests and schedules that keeps warehouse query cost predictable.

Confirm release and ingestion image Python version
The platform team confirms which OpenMetadata release is running and which Python version its ingestion images use. OpenMetadata 2.0 moved ingestion images to Python 3.12 with Apache Airflow 3.3.0, so any custom ingestion image built for an earlier release must be rebuilt before profiler jobs run. If Great Expectations tests are in use, migrate them to version 1.3 first, since that is a breaking change in this release. Done when the ingestion container reports Python 3.12 and a test connection to one warehouse service succeeds.
Set profiler sampling defaults by source and tier
The data platform lead sets the profiler sampling configuration for each database service, then adds overrides for tier-one tables that need a different sample size. OpenMetadata 2.0 made Dynamic Sampling the profiler default, so the team should confirm whether that default suits each warehouse before accepting it. Sampling is the main lever on warehouse query cost, so record the chosen approach for each source in the configuration log. Check: a profiler run on one large table reports the sampling method it used, matching the recorded setting.
Define a small set of tier-one tests
Data stewards write a short list of table and column tests for tier-one assets only, such as row count bounds on a key table, non-null checks on identifiers and uniqueness checks on primary keys. A small set keeps each failure traceable to a clear owner and keeps query cost bounded. Teams that keep test definitions in version control can create them through the REST API or the Python SDK, while others can use the user interface. Check: run the suite against a recent load and confirm every test returns either a pass or a failure with a documented cause.
Configure freshness checks against load schedules
Engineers record the expected load time for each tier-one table from the upstream pipeline schedule, then configure freshness checks to fail when data is older than that window. The windows should come from the schedule recorded in the orchestrator, and they should account for month-end or holiday loads that run late. Confirm the orchestrator and the ingestion scheduler use the same time zone before setting any window. Check: pause one non-critical load in a test environment and confirm the freshness check fails during the next scheduled run.
Assign owners and route failure notifications
Each tier-one table and its tests receive a named owner, usually a data steward or domain lead, through the ownership fields on each asset. Failure notifications are then routed to that owner's channel, with a named secondary contact for escalation outside working hours. Confirm the alert rules for test results point to these owners and not to a shared mailbox that nobody watches. Check: trigger one deliberate failing test in a sandbox and confirm the named owner receives the notification within the expected run cycle.
Schedule profiler runs outside peak warehouse hours
The platform engineer sets the ingestion schedule for profiler and test jobs so they run in an off-peak window agreed with the BI and finance teams that use the warehouse. Stagger jobs across sources so they do not all start at the same moment, which spreads the query load. Check the run history after the first cycle to confirm each profiler job started and finished inside the agreed window, and record any job that overran for review.
Review two weeks of results and tune thresholds
After the schedules have run for the first two weeks, data stewards review every failed and noisy test with the table owners. Loosen thresholds that fire on expected seasonal variation, tighten those that missed a genuine problem, and record each change with its reason. Remove any test that no owner can act on. Check: a signed-off change log is attached to each tier-one asset and the next review date is set on the owner's calendar.

How profiler sampling changes warehouse query cost

Profiling is the part of OpenMetadata data quality configuration that spends warehouse money. The profiler runs aggregate queries against each profiled table in the source warehouse: row counts, null counts, distinct counts, minimum and maximum values, and value distributions per column. On a warehouse that bills by bytes scanned or by compute time, a full scan of a large, wide table is paid for on every run, and the cost grows with both row count and column count. The same profiler schedule can be negligible on a small dimension table and expensive on a high-volume event table. Before enabling profiling across connected services, estimate which tables will dominate the load and confirm the billing model with your warehouse provider.

Four settings change that load: sampling, table selection, scheduling and test scope. Sampling reduces the number of rows the profiler reads from each table. Table selection, configured through the ingestion filters for each service, decides which assets are profiled at all. Scheduling controls how often the same tables are rescanned, and a daily profile of a table that changes once a month repeats work for no gain. Test scope matters because each data quality test on a table can issue its own query, so a long suite on one large table adds reads even when the profile itself is sampled. Ask your engineers to list the expected queries per table, the schedule for each and the tests attached to it before rollout.

Dynamic Sampling is the profiler default in OpenMetadata 2.0, according to the 2.0 release notes. Treat that default as a starting point and verify it before accepting it. Upgrading an existing 1.x install can change profiling behavior on tables that were already configured, so compare results before and after the change. On your largest tables, check which sample size the profiler selects, how long each run takes, how many warehouse credits or bytes each run consumes, and whether row counts and null ratios match a full scan on the same table at a fixed point in time. Record these results in your rollout notes so the team can explain the configuration later to data owners and reviewers.

Sampling trades accuracy for cost. A smaller sample reads less data, but the statistics it produces are estimates, and the estimates are least reliable for skewed columns and for values that occur rarely. Tests built on sampled statistics can miss rare-value issues. For example, a status code that appears in a very small share of rows may not appear in the sample at all, so a rule that flags unknown codes passes even though the production table contains them. The same risk applies to duplicate keys and to sparse columns that carry compliance flags. Sampling is therefore a poor fit for checks where a single bad row is the failure you care about, even when it is cheap for every other check on the same table.

What drives effort and cost in data quality and profiler work

This table lists the factors that change how much work an OpenMetadata data quality and profiler rollout takes and what it costs to run. Read each row as a driver, its effect on effort, and the practical step that keeps it contained. Use it to shape the scope you request in a quote.

Driver	Why it changes effort or cost	How to keep it down
Tables and columns in scope	Every profiled table and column adds profiling runs, storage for results and review time for test thresholds. Column-level tests multiply quickly.	Start with business-critical tables tied to named owners. Profile columns that feed reports or models before profiling everything.
Warehouse size and query pricing	Profiling and tests run queries against the warehouse, so compute and per-query charges recur with every scheduled run.	Use sampling and dynamic sampling defaults, limit full scans, and confirm with your warehouse team which compute pool the ingestion user runs on.
Number of sources and connector types	Each source needs its own credentials, network path, connector version and regression checks, and each connector type behaves differently for profiling.	Group sources by connector type, onboard one type at a time, and confirm each connector's profiler and test support in your release.
Count and complexity of tests	Simple null or range checks are cheap to write. Custom SQL tests, cross-table comparisons and tests run through external frameworks add authoring, runtime and maintenance work.	Prefer built-in test definitions where they fit. Keep custom SQL tests few, documented and reviewed when schemas change.
Freshness schedule variety	Each distinct schedule needs its own pipeline entry, alerting expectations and sometimes its own warehouse load window.	Standardize on a small set of schedules, such as hourly, daily and weekly, and map each table to one of them.
Owning teams and notification channels	Failures must reach a named owner. More teams and channels mean more routing rules, more ownership mapping and more alert triage.	Assign ownership at domain or table level, send failures to one channel per team, and set severity so only blocking failures page people.
Environments (dev, test, production)	Each environment has its own sources, connections, test definitions and schedules. Changes must be promoted and checked in each one.	Keep test definitions in version control, promote them through environments, and limit production profiling to approved tables and windows.
Compliance evidence needs	Assessors may ask for test history, owner records, threshold change logs and proof that failures were acted on. Retaining this evidence adds storage and documentation work.	Agree the evidence list before build, export results on a fixed cadence, and keep ownership and threshold changes traceable. DeployOpen prepares evidence but auditors issue any assessment.

How the setup differs on bare metal, Kubernetes and air-gapped networks

On bare metal, the OpenMetadata server, database, search service and ingestion workers run on hosts you manage directly. Profiling and test jobs draw on the same machines that serve the catalog, so host layout is a planning decision made before installation. The documented prerequisites are Java 21, MySQL 8.0.42 or later or PostgreSQL 15 or later, and Elasticsearch 9.x or OpenSearch 3.x.

Key points:

Server minimum: 2 vCPUs, 4 GB RAM and 20 GB storage for the OpenMetadata server.
Database and search: each needs at least 2 vCPUs, 2 GB RAM and 30 GB storage, per the documented minimums.
Production sizing: the minimums are a starting point. Confirm the sizing for your profiling load with a trial run on a representative table.
Ingestion workers: confirm whether workers run on the server host or on separate hosts, and size each host for its jobs.
Source access: open outbound connections from the worker host to each warehouse, BI tool and pipeline system, and scope firewall rules per source.

Scheduler resilience: on a single host, a host failure stops freshness checks until it is recovered. Confirm how job state survives a restart and whether missed runs are retried automatically.

Check the sizing and the restart behavior with your own sources before you set production schedules.

How to verify that data quality tests fire and fail safely

Confirm that tests fire, fail and report correctly before anyone relies on them to route work to a data owner. Start with a deliberately broken test on a non-production table that the named owner recognizes. For example, add a uniqueness test to a column you know contains duplicates in the non-production copy. Run it and confirm the result is recorded with a failed status, the expected severity and the correct table and test name. Then confirm the named owner received the alert. Keep the test name, table, run time and recipient together so the evidence can be reused in an assessment or internal review.

Next, test freshness and profiling against conditions you control. Pause the upstream load for a table that has a freshness check, wait past the expected update window, and run the check. It should fail and show the last update time it observed. Resume the load and confirm the check passes on the following run, so you know the failure clears and is not stuck. For the profiler, run a profile on a large table with the sampling settings you configured, then compare the sample size and row counts in the output with what you set. Dynamic Sampling is the profiler default in OpenMetadata 2.0, so confirm whether your configuration overrides it and check the exact setting names in the release you run.

Then confirm that a failed profiler job does not block other tables. Include a table with a known problem in the same ingestion run, such as a connection your test source cannot reach or a column type the profiler does not handle in your environment. Confirm the job reports as failed, while the other tables in that run still complete and update. Also confirm that a test that errors out does not pass silently. It should show an error or aborted status in the run history for that test. Check the run history itself, since a summary view can show green when tests were skipped. Compare the number of tests scheduled with the number executed and reported.

Finally, check notification delivery and the owner's view as one end-to-end path. Follow a single failure from the test result to the alert: the message should reach the channel or address configured for the owner, name the table and test, and link back to the result. Test each notification channel separately, because one may work while another fails silently. Then sign in as the owner through your identity provider or a test account with the same role, and confirm the failing test appears with the same status and timestamp. Record the accounts used and any gaps, and ask your team or implementation partner to confirm which notification types and owner views your release supports.

How to control access to source credentials and quality results

Profiling and quality tests need read access to your sources, a bot identity inside OpenMetadata and, in some cases, the ability to see sample rows. Each control below narrows one of those paths so that a compromised connector, an over-broad role or an edited test has limited reach.

Dedicated ingestion service account

Run profiling and test execution under a dedicated service account owned by the platform team. If the person who created a connection leaves, scheduled runs should keep working without that person's login. Check who holds the account's password or token, where it is stored, and whether its activity is logged separately from human sessions so that profiler runs can be told apart from manual changes.

Least-privilege source read access

Grant the profiler only the read rights it needs. Profiling reads table metadata, column statistics and, when sampling, row data, so the source role needs select access on the in-scope schemas and no write, DDL or administrative rights. Confirm with each source vendor which privileges its profiling and sampling queries require, test the role against a non-production copy, and document the grant list so reviewers can compare it with the connection's configured scope.

Connector credentials and bot tokens

Keep source passwords, key files and the OpenMetadata bot token in a secrets manager, and keep them out of ingestion workflow files stored in version control. Set a rotation schedule for the bot token and rotate it after any staff change. Before rotating, confirm that scheduled ingestion and profiler jobs pick up the new value, and confirm with your OpenMetadata version how each connector references secrets, since configuration formats can change between releases.

Restricting test edits and disables

Limit rights to edit or disable data quality tests to the stewards who own each table. A disabled test quietly removes a control, so changes to thresholds, filters and enabled status should trace back to a named person. Review which roles and teams hold data quality permissions, and check that failure notifications still reach the table owner after any test has been changed.

Protecting sensitive sample data

Profile results can display sample values, so profiling a column that holds personal or financial data may expose those values to anyone who can view the table. Use classifications to mark sensitive columns, then decide whether sampling should skip them or limit what is displayed. Confirm that sample visibility follows the same access rules as the table itself, and verify the result by signing in as a user who lacks access to those columns.

Planning the ingestion identity under SSO

Plan the ingestion identity separately when SSO is the only login method. OpenMetadata's security documentation covers the supported SSO providers and does not allow multiple authentication mechanisms at once, such as SSO combined with basic authentication. Once basic login is switched off, scheduled profiler and test jobs still need a machine identity, so confirm how the bot token authenticates before you disable human basic logins.

Can our own team configure OpenMetadata data quality and profiling?

Do we need outside help to set up OpenMetadata tests?

Often no, but platform setup is the smaller share of the work. OpenMetadata offers a user interface, REST APIs and a Python SDK, so an engineer comfortable with those can define tests and profiler settings in-house. The harder part is agreeing what "correct" means for each table: acceptable null rates, valid value ranges, expected refresh times and who receives each alert. Teams that already run their own warehouse and orchestration tooling usually find the configuration manageable. Teams without a named platform owner, or without time to maintain tests as schemas change, tend to stall. Consider outside help when you want the scope settled in writing before work starts.

What makes the cost of profiling and quality setup go up or down?

The main drivers are the number of tables and columns in scope, how many warehouses and sources are connected, how many tests each asset needs, and how many people must review results. A broad profiling run touches more data than a targeted one, so scope has a direct effect on warehouse spend. Most engagements are fixed-scope, so the quote follows from a written list of assets, sources, test types and alert channels. One-time work includes connector setup, the first profiling tuning and the initial test definitions. Recurring work includes reviewing failures after schema changes, adjusting thresholds and onboarding new sources. Ask any provider to price these separately so you can see what recurs.

How long does it take to reach stable data quality alerts?

No single duration applies across environments, so ask for a timeline tied to your own assets. Stability depends on how long the first profiling runs take, how much threshold tuning the data owners need, and how often upstream loads change shape. A typical path moves from a small pilot set of critical tables, to a first full run, to tuning tests that fire too often or too rarely, and then to routing alerts to owners who act on them. Alerts are stable when owners trust the false positive rate enough to respond. Plan for at least one tuning cycle after the first full run. Ask for milestones and acceptance criteria in writing.

What do data owners and warehouse admins need to provide?

Data owners decide what good data means: expected ranges, allowed nulls, freshness deadlines and which failures need immediate action. They also confirm ownership in the catalog, because alerts route to the owner recorded there. Warehouse admins provide a service account with read access to metadata and sampled data, a defined compute resource for profiling, and approval for query windows. Security teams should review what sample data leaves the source and where results are stored. Confirm the exact privileges with your warehouse vendor, since required grants differ by platform. Without these inputs, tests get written against assumptions and then ignored.

How do we limit warehouse query cost during the first profiling run?

Start with a narrow scope: a short list of critical tables instead of the whole warehouse. Review the sampling settings before running anything. OpenMetadata 2.0 made Dynamic Sampling the profiler default, so check how that setting behaves on your largest tables. Run the first profile in a window agreed with the warehouse admin, on a dedicated compute resource with a spend limit where your platform offers one. Exclude partitions and columns that do not need profiling. Check the query count and data scanned after a small run before expanding scope. *Illustrative example:* a team profiles twenty critical tables first, reviews the cost, and then adds the next group.

What should a written scope for this work include?

A written scope should name the exact sources, tables or domains in scope, the test types for each asset, such as completeness, validity and freshness, the profiler settings and sampling approach, and the alert channels and owners. It should separate what the provider configures in OpenMetadata from what your team must supply, and list exclusions such as custom connectors or upstream data fixes. Ask for deliverables, acceptance criteria, a tuning period, the handover format, and who runs the first full profile and approves its query cost. Ask how changes after sign-off are priced, so the scope stays checkable as requirements change.

Does this work include ongoing support after go-live?

Initial configuration and ongoing support are separate decisions. After go-live, tests need review when schemas change, connectors are upgraded or new sources arrive. DeployOpen offers ongoing support and upgrades as retainers, which is a separate agreement from the initial scope. Ask whether a proposal includes post-handover support, what response expectations apply, and who maintains test definitions once your team takes over. If your rollout predates OpenMetadata 2.0, ask how its breaking changes are handled, including migrating Great Expectations to 1.3 before upgrading.

How DeployOpen scopes, builds and hands over data quality configuration

DeployOpen configures OpenMetadata data quality tests, profiler sampling and freshness checks inside your own infrastructure, using the platform's documented features. We start from the tables and owners that matter most, then build, test and document the configuration so your team can run it after handover.

How we scope

Agree in writing which tables, columns and data domains receive quality tests and freshness checks
Record which warehouse connectors and profiler settings are in scope for the engagement
Name the data owners who will receive failure notifications and confirm their routing paths
Confirm how sampling and profiling will limit warehouse query load before any configuration starts

How we build

Configure data quality tests and freshness checks against agreed tables in a non-production environment first
Tune profiler sampling so warehouse query cost stays within limits your data platform team sets
Verify test results against known good and deliberately broken sample data before enabling alerts
Document each test, its threshold, its owner and the reason it exists for later review

How we hand over

Deliver a written configuration record listing every test, schedule, sampling setting and alert route
Walk your platform and data owner teams through how failures are triaged and who acts on them
Provide reusable configuration exports so changes can be reviewed and restored in your own version control
Confirm with your team that alerts reach the intended owners before closing the engagement

How we support

Ongoing support, upgrades and continuous testing are available as a retainer after handover
Review quality test coverage and profiler settings when new connectors or domains are onboarded
Check configuration compatibility when upgrading OpenMetadata releases, including Dynamic Sampling defaults in 2.0
Confirm with your team which support scope, response expectations and review cadence apply under the retainer

OpenMetadata data quality and profiler configuration