SQLMesh Data Quality: Data Observability and Audits

Does SQLMesh have data quality checks?

SQLMesh has audits, and audits are tests rather than monitoring. An audit is a SQL query that should return zero rows, attached to a model and run after that model executes. The built-in library is genuinely broad, covering not_null, unique_values, accepted_values, accepted_range, string and regex checks, and statistical audits including z_score, stddev_in_range, chi_square and kl_divergence. By default SQLMesh halts plan application when an audit fails so potentially invalid data does not propagate further downstream. The gap is structural rather than a missing feature. Audits only run when a model runs, so a pipeline that quietly stops firing is a pipeline that is never checked, and on incremental by time range models the documentation states that audits are only applied to intervals being processed, not for the entire underlying table. Nothing inside SQLMesh watches a table between runs, and that is exactly where freshness and volume failures live.

Last updated September 2026

// COMPARE

Side by side

SQLMesh data quality compared

Swipe to see all columns →

Approach	What it catches	What you operate	Documented limit
Built-in audits	Rule violations you predicted, on the rows the run just wrote: nulls in a required column, a duplicate key, a value outside an accepted range	One audit per rule per model, plus threshold maintenance as the data grows	Audits validate the output of a model after every run, so they only execute when the model executes. On incremental by time range models, audits are only applied to intervals being processed, not for the entire underlying table
Statistical audits	Distribution movement measured against a parameter you supply, through z_score, stddev_in_range, mean_in_range, chi_square and kl_divergence	A statistical parameter chosen and re-tuned for every column you care about	The threshold is a constant you set, not a baseline learned per table. It does not adapt to seasonality, growth, or a Monday that legitimately looks different from a Sunday
Blocking and non-blocking audits	A blocking audit stops the plan before bad data spreads. Appending _non_blocking to the audit name lets the run continue and reports the failure instead	A severity decision for every audit you attach to every model	Halting the plan protects downstream tables and also stops the load, so the choice is binary per audit. Failures surface through the run and the sqlmesh audit command rather than through an on-call routing layer
A model with no audits attached	Nothing at all	Nothing, which is the problem	Silent by default. Audits are opt in per model, so coverage tracks whichever tables an engineer thought to protect, and new models arrive unchecked unless somebody remembers
Coalesce Quality, formerly SYNQ	Anomaly detection on SQLMesh models, from the team that built the deepest SQLMesh-native integration in the market	A Coalesce subscription alongside your SQLMesh project	Quality is bundled with Coalesce Transform rather than sold on its own, and the meter counts actions, where an action is a successful node execution, a catalog asset refresh, or a monitor refresh. Monitors therefore draw from the same pool as transformation work
Warehouse level monitoring, this product	Freshness, volume, schema change and distribution on the tables SQLMesh writes, measured against a learned baseline for each table	A read only warehouse user, and a decision about which tables are allowed to page somebody	Watches Snowflake, BigQuery, Databricks and Redshift, which are four of SQLMesh's supported execution engines. It reads the warehouse rather than your SQLMesh project, so model level metadata stays in SQLMesh

Positioning and pricing models are summarized in good faith from each vendor's public pages, September 2026. Verify current terms with the vendor.

// CAPABILITY

What you get

What warehouse monitoring adds underneath SQLMesh

An audit that never runs never fails

This is the single most important thing to understand about SQLMesh audits, and it is not a criticism of SQLMesh. Audits are documented as validating the output of a model after every run. That coupling is deliberate and it makes audits fast and cheap. It also means the audit system inherits the scheduler's failure modes. If an upstream extract pauses, if a cron entry is removed during a migration, if a credential expires over a long weekend, or if a model is simply excluded from a plan, then no model runs, no audit runs, and every check reports nothing rather than reporting a problem. The table sitting in your warehouse is now a day stale, a week stale, or frozen at quarter end, and the audit suite is perfectly green because it was never invoked. Freshness monitoring inverts that logic: it asks how long it has been since this table last changed and compares the answer to what normal looks like for this table, which is a question that gets asked whether or not your pipeline had a good night.

Audits check the interval, monitoring checks the table

The SQLMesh documentation is precise about this: for incremental by time range models, audits are only applied to intervals being processed, not for the entire underlying table. That is the correct engineering decision, because re-auditing a five billion row table on every hourly run would be ruinous. The consequence is worth stating plainly anyway. Your uniqueness audit proves the key is unique within today's partition. It does not prove the key is unique across the table, so a backfill that replays a batch, or a late arriving correction that duplicates a record from three weeks ago, passes every audit on the way in. Whole-table properties need a whole-table view, which is what a monitor that profiles the table itself provides, on a schedule that has nothing to do with when the model last ran.

A threshold you typed in 2025 is not a baseline

SQLMesh gives you real statistical audits, and z_score, kl_divergence and chi_square are more than most transformation frameworks ship. Each one still needs a number from a human. Somebody decides that a z-score above three is suspicious, or that a mean should stay between two values, and that judgment is frozen the day it is written. Real tables do not cooperate. Volume triples after a launch, so the old accepted_range fires every night until an engineer widens it and stops reading it. Traffic halves in late December, so the check that should have caught a genuine outage says nothing because the threshold was widened in March. Learned baselines move with the table, model day of week and seasonality, and adapt without a pull request, which is the difference between a check that stays useful for two years and a check that gets muted in month three.

The warehouse is the layer that did not change hands

Ownership in this part of the stack has moved twice in the last eighteen months, and both moves landed on SQLMesh teams. Fivetran acquired Tobiko Data, the company behind SQLMesh and SQLGlot, on September 3, 2025, and Fivetran also completed its merger with dbt Labs on June 1, 2026, so a single vendor now stands behind both major transformation frameworks. Then on March 10, 2026, Coalesce acquired SYNQ, which had built the most thorough SQLMesh-native observability integration anyone shipped, and relaunched it as Coalesce Quality inside the Coalesce platform. None of that is a scandal and all of it is normal market consolidation. It does mean that if you tie your data quality signal to whichever tool sits closest to your transformation framework, you are re-running a procurement decision every time somebody signs a term sheet. Tables in Snowflake, BigQuery, Databricks and Redshift are the one part of this picture that did not get acquired, and monitoring that reads them read-only survives whatever happens above.

// 4 STEPS

How it works

From connected to caught

01

Keep the audits you already have

Nothing here argues for deleting audits. Blocking audits on primary keys and required columns are the cheapest data quality control that exists, and stopping a plan before bad rows propagate is worth far more than an alert after the fact. Keep them, and stop expecting them to answer questions about tables they never look at.

02

Connect the warehouse read only

Point the platform at the Snowflake, BigQuery, Databricks or Redshift account SQLMesh writes into with a read-only role. It profiles every table it can see and builds a baseline for freshness, row volume, schema shape and column distributions, including the models nobody attached an audit to. No SQLMesh configuration changes and no model file edits.

03

Let the two systems cover different failures

Draw the line by question. Did this run write rows that violate a rule I can state is an audit, and it should block. Did this table update at all, did volume move outside its normal band, did a column type change, did the null rate on a field jump is a monitor, and it should page. Teams that try to force one system to answer both questions end up with either an audit suite nobody maintains or an alert channel nobody reads.

04

Route by severity, not by volume

Send freshness and volume breaks on revenue tables to PagerDuty, send everything else to a Slack channel, and group related failures into one incident so a single upstream break does not fire forty separate alerts. Column level lineage on the warehouse tells you which downstream models and dashboards are affected before anyone asks.

Which data observability tool is best for SQLMesh?

The honest answer in 2026 is that the SQLMesh-native option changed owners and the practical option is warehouse-level. SYNQ built the deepest SQLMesh integration in the market, resolving models to their physical table locations across snapshots so that monitors could follow SQLMesh virtual data environments, and deploying monitors from SQLMesh model tags. Coalesce acquired SYNQ on March 10, 2026 and relaunched it as Coalesce Quality. Coalesce publishes its pricing, and the structure matters more than the number: Quality is bundled with Coalesce Transform rather than sold separately, the Starter tier is listed at 150 dollars per user per month billed annually with up to four Transform users and 15,000 actions per month, and an action is defined as a successful node execution, a catalog asset refresh, or a monitor refresh. For a team that chose SQLMesh precisely so it would not be inside somebody else's transformation platform, buying observability that arrives bundled with a competing transformation product is a strange shape, and the shared action pool means every extra monitor competes with pipeline runs for the same budget. The alternative is to monitor the warehouse rather than the framework. SQLMesh runs on ClickHouse, Databricks, DuckDB, Fabric, MotherDuck, MSSQL, MySQL, Postgres, Redshift, RisingWave, Snowflake, Spark and Trino, and whichever of those you use, the models land as tables. A platform that watches those tables for freshness, volume, schema and distribution covers every model whether or not it carries an audit, keeps working when a run does not happen, and does not need to understand SQLMesh internals to notice that a table stopped updating. The trade is real and worth stating: warehouse-level monitoring does not read your SQLMesh project, so it will not map an alert back to a model name or a virtual environment for you. What it will do is tell you a production table is wrong, which is the thing that wakes people up.

The three failures SQLMesh audits structurally cannot catch

Start from what audits are, then the boundary draws itself. An audit is a query that should return zero rows, run against the output of a model after that model executes. First, a run that does not happen. No execution means no audit, so a paused ingestion job, an expired warehouse credential, or a model dropped from a plan during a refactor produces silence rather than an alarm, and silence is indistinguishable from success on a dashboard. This is the failure mode that costs teams the most, because it is invisible for exactly as long as nobody looks. Second, whole-table properties on incremental models. Audits on incremental by time range models are applied only to the intervals being processed, so uniqueness, referential integrity and totals are proven for the slice and assumed for the rest, which is how a replayed batch or a late correction slips past a green suite. Third, changes that are legal but wrong. A vendor starts sending amounts in cents rather than dollars, a nullable column starts arriving fully populated with a default, a categorical field gains a new value nobody has heard of, or a join begins silently dropping ten percent of rows. Every one of those satisfies not_null, satisfies unique_values, and satisfies accepted_values if the value was in the list. Catching them means comparing today's distribution to this table's own history, which is a monitoring question rather than an assertion, and it is the question that learned baselines exist to answer.

What happened to SQLMesh, SYNQ and the tooling around them

Two acquisitions reshaped this corner of the stack and both are worth knowing before you pick a monitoring vendor. On September 3, 2025, Fivetran announced it had acquired Tobiko Data, the open source transformation company behind SQLMesh and SQLGlot. On June 1, 2026 Fivetran completed its merger with dbt Labs, which puts both dominant transformation frameworks under one roof. Separately, on March 10, 2026, Coalesce announced the acquisition of SYNQ and the launch of Coalesce Quality, folding the leading SQLMesh-native observability product into the Coalesce data operating layer alongside Coalesce Transform and Coalesce Catalog. SQLMesh itself remains open source and the projects continue, so none of this is a reason to move off SQLMesh. The practical lesson is narrower and it is about coupling. Tooling that lives inside the transformation layer inherits that layer's corporate history, and over eighteen months the SQLMesh ecosystem absorbed two ownership changes that a team using it had no say in. Monitoring that connects to the warehouse read-only is coupled to Snowflake, BigQuery, Databricks or Redshift instead, which is a dependency you already accepted and one that is considerably harder to acquire out from under you.

SQLMesh column level lineage, and where the warehouse fills the gap

SQLMesh understands your SQL properly. It parses models with SQLGlot rather than templating strings, which is why it can work out column level relationships inside the project and why it knows which models a change actually affects. That is real lineage and it is one of the strongest arguments for the framework. The limit is the project boundary. SQLMesh knows how a column flows from one model to another because it can read both models. It does not know what happens to that column after it leaves the project: which BI dashboards read the final table, which reverse ETL sync pushes it into a CRM, which notebook a data scientist points at it, or which table an entirely separate team built on top of it without telling you. Warehouse-side column level lineage is built from query history rather than project files, so it sees every consumer that touched the column regardless of which tool issued the query. The two are complementary, and the practical value shows up during an incident. SQLMesh lineage answers which models need rebuilding. Warehouse lineage answers who is currently looking at the wrong number and needs an email in the next ten minutes.

What SQLMesh data quality costs once you count everything

SQLMesh audits carry no license fee, which makes the total cost easy to underestimate. The real line items are engineering time and warehouse compute. Every model needs somebody to decide which audits apply, write them, and revisit the thresholds when the business changes, and that maintenance never ends because the data never stops moving. Audits also run as queries on your warehouse, so a broad audit suite on wide tables shows up as Snowflake credits or BigQuery slot time whether or not it ever finds anything. On the commercial side, Coalesce publishes a Starter tier at 150 dollars per user per month billed annually, capped at four Transform users and 15,000 actions per month, with Enterprise at 100,000 actions and custom pricing, and Quality is included rather than sold separately. Tobiko Cloud, the commercial service from SQLMesh's original authors, describes a platform fee plus pay-as-you-go consumption and does not publish a dollar figure, so budgeting it requires a sales conversation. This product publishes its price: 99, 299 and 799 dollars a month, with a 14 day trial and no card required. That is deliberate, because a monitoring bill that only appears after a discovery call is a monitoring bill you cannot compare, and comparability is most of what a buyer actually needs.

// FAQ

Questions buyers ask

SQLMesh data quality FAQ

What is the difference between SQLMesh audits and data observability?

Audits are assertions you write and SQLMesh runs after a model executes, checking the rows that run just produced against rules you defined. Data observability profiles tables on its own schedule, learns what normal freshness, volume, schema and distribution look like for each one, and alerts when reality drifts from that baseline. Audits catch the failures you predicted; observability catches the ones you did not, including a run that never happened.

Does SQLMesh monitor data freshness?

No. There is no freshness audit in the built-in library, and there structurally cannot be a useful one, because audits run after a model runs. A freshness check only means something when it can fire while nothing is running, which is precisely the situation SQLMesh audits cannot observe. Freshness has to be measured against the table itself, by comparing the last update time to what is normal for that table.

Can I use SQLMesh audits and a data observability platform together?

Yes, and that is the arrangement most teams end up with. Keep blocking audits on keys, required columns and known business rules so bad rows never propagate through a plan. Add warehouse monitoring for freshness, volume, schema drift and distribution across every table, including the models nobody wrote an audit for. Neither replaces the other, and the platform does not require any change to your SQLMesh project.

Which data observability tools work with SQLMesh?

SYNQ built the deepest SQLMesh-native integration, resolving models to physical tables across virtual environments and deploying monitors from model tags, and it is now Coalesce Quality following the March 2026 acquisition, sold bundled with Coalesce Transform. Beyond that, warehouse-level platforms work with SQLMesh by construction, because they monitor the Snowflake, BigQuery, Databricks or Redshift tables the models write rather than reading the project itself.

Do I still need monitoring if all my SQLMesh audits are blocking?

Blocking audits are strong protection against propagating known-bad rows, and they do nothing when the run does not happen. They also see only the intervals being processed on incremental models, not the whole table, and they cannot flag a value that is legal but wrong, such as amounts arriving in cents instead of dollars. Those three gaps are why teams with thorough audit coverage still add monitoring.

Does SQLMesh have column level lineage?

Yes, inside the project. SQLMesh parses models with SQLGlot rather than treating SQL as text, so it can trace how columns flow between models and work out what a change affects. It stops at the project boundary, so it does not show which dashboards, reverse ETL syncs or ad hoc queries consume the final table. Warehouse-side lineage is built from query history and covers those consumers.

What replaced SYNQ for SQLMesh monitoring?

SYNQ became Coalesce Quality when Coalesce acquired it on March 10, 2026, and the product continues inside the Coalesce platform alongside Transform and Catalog. It is no longer sold standalone, and it is metered in actions shared with transformation work. Teams that want observability decoupled from a transformation vendor generally move to warehouse-level monitoring instead.

More of the platform

Data quality tools Data quality monitoring Data quality checks Data lineage Data pipeline monitoring Data anomaly detection Data incident management Data observability pricing Open source data observability Data quality dashboard Data lineage diagram tool Data contracts Data quality management tools Data observability market Data lineage tools Column level lineage BigQuery anomaly detection Snowflake anomaly detection Databricks data quality monitoring Redshift data quality Airflow data quality checks dbt observability Monte Carlo pricing Collibra pricing Acceldata pricing Power BI data quality Data lineage tools pricing Snowflake data metric functions dbt source freshness Dataplex data quality Tableau data quality Data observability for Snowflake dbt data observability BigQuery data quality Databricks data observability

SQLMesh Data Quality: Data Observability, Audits and Column Level Lineage for SQLMesh