DataQ
Get Started
Open source · MIT · self-hosted

The data-quality
control plane

An engineering-first, extensible place that connects your quality checks to the pipelines that load the data, the assets it lands in, the incidents a failure opens and the AI agents your team works with — on infrastructure you run.

Explore the live demo
Snowflake · Databricks Unity Catalog · Apache Iceberg · PostgreSQL · MySQL / MariaDB · Trino · SQL Server (Azure SQL, Synapse, Fabric) · Amazon Athena · Amazon Redshift · Google BigQuery · ADLS Gen2 & Fabric OneLake · AWS S3 (and any S3-compatible store) · Google Cloud Storage — watching Azure Data Factory, Airflow and dbt.
The DataQ monitoring dashboard: asset health, data-integrity score, pass rate, quality trend and per-suite performance

From a bad load to a fixed one

Each step below is in the product today. DataQ is a data-quality platform with an emerging observability layer: it watches what you point it at, and the tables of any warehouse connection you switch automatic coverage on for.

  1. Detect

    A pipeline finishes and the bound suite runs, or a schedule fires. Freshness, volume, schema-drift, anomaly and value checks find the load that never arrived, arrived half-empty or changed shape.

  2. Explain

    The result carries the measured value, the expected range and a redacted sample of failing rows. Bring your own LLM and it drafts a root-cause narrative from that evidence.

  3. Impact

    A failing check opens an incident on the asset it hit, and lineage from dbt, OpenLineage or the warehouse shows which downstream tables may be affected.

  4. Gate

    A pipeline stage can ask DataQ for the verdict before it publishes. DataQ answers; your DAG decides whether to continue.

  5. Remediate

    The owning team is alerted once, acknowledges the incident, fixes the data, and re-runs the suite to confirm before resolving it — from the UI, the API or an AI agent over MCP.

Everything between a bad load and a bad decision

Eight kinds of check, three orchestrators, every alert de-duplicated, and one assistant-ready interface — on infrastructure you run.

Checks that catch real incidents

Freshness, volume and schema-drift monitors notice a load that never arrived, arrived half-empty or changed shape. Twenty-five vetted Great Expectations types, custom SQL with a live dry-run, anomaly detection on a learned baseline with weekly and yearly seasonality, aggregate bands on a column's statistics, PII-drift detection and cross-dataset comparison cover the rest. Switch on automatic coverage for a warehouse connection and its tables get baseline checks without anyone writing them.

orders · freshness
pass
orders · status in set
critical
orders · amount in range
warn

Runs when the pipeline does

Azure Data Factory, Airflow and dbt tell DataQ when a load finishes; the suite runs right after a success and the result is correlated to that pipeline run. Failures alert without running checks on nothing. A pipeline stage can also wait for the verdict and decide whether to go on. Cron schedules cover everything else.

Alerts the right team, once

Microsoft Teams, Slack, email and webhooks, routed by severity and configured per suite. A broken check reports when it breaks and when it gets worse — not on every run.

Assets & lineage
Every table and file DataQ knows about, health rolled up per asset, lineage pulled from dbt, your catalog or the warehouse, incidents anchored where they hit.
Built-in assistant
Bring your own LLM: suggest checks from a column profile, turn a question into validated SQL, and get a root-cause narrative on a failing run.
Open to your AI tools
56 MCP tools expose the same actions to Claude, Copilot and Cursor — every one honest about what it cannot see, none of them touching a credential.
Secure by design
Workspace roles times per-suite grants, three sign-in modes, credentials in Key Vault, Secrets Manager or OpenBao, failing rows redacted, a compliance pack for GDPR, CCPA and HIPAA reviews, and no usage telemetry unless an admin opts in.
Runs where your data lives
Reference stacks for Azure Container Apps and AWS ECS, a Helm chart for your own Kubernetes, a one-command Docker stack for evaluation, no vendor lock-in behind any seam.
Documented like a product
Tutorials with screenshots and clips, a generated reference for every check type, endpoint and tool, forty-plus decision records, and pages your assistant can read as Markdown.
Built with accessibility in mind
Every screen of the app is scanned for serious accessibility violations in light and dark themes on every change, colour contrast is held to WCAG ratios, severity and run status carry a text label or pattern as well as colour, and core navigation works from the keyboard.

See it in action

Real screens from the seeded demo workspace — the same ones in the tutorials.

A ten-second tour: dashboard, assets, connections, suites, results.
A suite with four checks, their data-quality dimensions, and the pipeline triggers panel
A suite: connection, target, checks with their dimension, triggers.
A run: per-check status, measured metric and observed value; a critical check has opened an incident
A run: per-check status, the measured metric, an opened incident.
The assets tree grouped by source with per-table health
Assets: every table and file, health rolled up per source.
Assistant: generate a curated set of checks for the suite from data insights.
Connection cards for Unity Catalog, ADLS Gen2, AWS S3 and Snowflake, plus Airflow and Azure Data Factory orchestration, each with its credential and environment status
Connections: every source and orchestrator, one connection manager.

Walk through the demo

These screens come from the Docker stack's demo profile: a sample PostgreSQL shop warehouse with deliberate defects, already connected and run when you first sign in. The read-only demo in your browser uses a different recorded sample workspace, so it shows other tables and suites.

Run the demo profile Open the read-only demo
  1. The monitoring dashboard after first sign-in: two monitored assets, shop.shop.customers and shop.shop.orders, both failing; data quality by dimension with Completeness, Consistency, Timeliness, Uniqueness and Validity bars, and Accuracy and Integrity listed as not covered
    1. Sign in to results. Both demo tables already need attention, and the dimension bars show which kinds of quality are failing and which nothing checks yet.
  2. The Shop orders (demo) suite on the Demo warehouse (PostgreSQL) connection, targeting shop.orders, with the first of its eleven checks listed with their engine and quality dimension and snooze, disable, edit and delete actions
    2. One suite, eleven checks. Shop orders covers value rules, custom SQL, freshness, volume, an aggregate, schema drift and anomaly detection. Its hourly schedule, triggers and alerting sit further down the same page.
  3. A run of Shop orders (demo) with 4 of 11 checks passed; the failing check Customer email looks like an email is expanded to its metric history and a failing-rows sample in which order_id 77 is shown and customer_email reads redacted
    3. A failed check, with evidence. Expanding a failing check shows its history and a sample of the failing rows. The email column is masked because DataQ classified it as personal data; the order id stays visible so you can find the row.
  4. The trend drawer for the anomaly check Row count is normal: the z-score per run sits near 2 and then rises past the fail line at 3 on the last run, and below it the row count runs inside its learned band until the last run drops out of it
    4. An anomaly, against its learned band. The row-count check's trend: each run's z-score against the warn and fail lines, and the row count against the band it learned. For this capture, rows were added between runs and then removed. On a fresh demo the check waits for five runs before it scores.
  5. The asset page for shop.shop.orders on demo-warehouse:5432: connection reachable, data quality failing, an asset health score of 70.5 broken down by dimension, and Accuracy and Integrity listed as not covered
    5. The table, not just the suite. The asset page rolls every suite on shop.orders into one health score by dimension and names the dimensions nothing checks yet.
  6. 6. Ask your assistant

    Connect Claude, Copilot or Cursor to /mcp/ (keep the trailing slash) with a personal access token and ask “what is failing on shop.orders, and why?” The assistant works through the same MCP tools as the rest of the product, with your permissions. For example:

    list_incidents     what is open, and on which asset
get_incident       the failing result and its evidence
trigger_suite_run  re-run the suite once the data is fixed

    It never sees a connection credential, and each tool says what it cannot see.

    Set up an assistant

Ready to elevate your data quality?

Open source, MIT licensed, self-hosted — one docker compose up to evaluate, OpenTofu for Azure or AWS to run it for real.

Get Started Installation Guide Read the Docs