Drift detection for Snowflake and Databricks

Your tests pass.
The data can still be wrong.

Driftwatcher watches your tables for the changes nobody wrote a check for: a dropped column, a null rate that jumps from 0 to 14 percent, a row count that quietly halves. There are no rules to define first. When a change matters, we write up a ticket that says what changed, what it touches, and where to look, ready to paste into Jira, Linear or GitLab.

Become a design partner See the live preview

Why tests aren’t enough

Data goes wrong in two ways a check can’t see.

The test passed and the data was wrong. A check covers what someone thought to ask. The failure that arrives is usually the one nobody anticipated.

There was no test. Tables get added, columns get repurposed, owners move on. Nobody writes the check, so there is nothing to fail.

dbt tests and the monitoring built into Databricks and Snowflake are good, and you should use them. They cover the tables and columns somebody set them up for. Driftwatcher starts from the tables you have, not the checks you’ve written.

What industry surveys say

$12.9m
Estimated average yearly cost of poor data quality per organization.
Gartner estimate, widely cited
40%
Of a data engineer’s workday goes to evaluating or checking data quality.
Monte Carlo / Wakefield Research survey, 2022
74%
Of surveyed data professionals say business stakeholders find data issues before the data team, all or most of the time.
Monte Carlo / Wakefield Research survey, 2023

How it works

Compare snapshots, then explain the difference.

On a schedule, Driftwatcher snapshots the structure and statistics of each monitored table and compares them with the last snapshot. Schema changes, null rates, row counts and similar signals are weighed together instead of alerted on one by one. A single odd number is usually noise. Three related ones usually aren’t.

We see statistics and metadata only. Raw row contents never leave your warehouse. If you upload your dbt manifest, we also use your criticality tags, owners and meta fields to judge how much a change matters. Most days you hear nothing from us.

Example alert

What an alert looks like.

An incident produced by Driftwatcher against a demo warehouse (“ACME”), shown as the ticket-ready write-up you paste into your tracker.

ACME-INC-0031 · schema_dropped_column · 2026-04-29 06:00:30

composition 0.850 · dimension 0.865 · verifier 0.900 · impact high

What changed

The column analytics.crm.customers.phone was dropped between the 06:00 UTC scheduled scan on 2026-04-28 and the 06:00 UTC scheduled scan on 2026-04-29, observed as a schema-snapshot diff. No DDL audit event has been captured upstream.

What it affects

analytics.crm.customers is annotated business_critical and customer_facing with a 1-hour SLA. Three registered consumers depend on this table: revenue_dashboards, customer_facing_app, and email_marketing_campaigns. The customer_facing_app performs real-time reads and is presumed broken immediately. email_marketing_campaigns runs as a batch pipeline and will fail on its next execution.

Why it matters

The drop occurred between two daily scheduled scans. No corroborating deploy or migration event has been observed. A dropped column on a business_critical, customer_facing table with three active consumers is an immediate breakage risk, not a degradation risk.

Investigate first

1. Identify who issued the ALTER TABLE or DROP COLUMN and when (Databricks query history):

SELECT executed_by_user_name, statement_text, start_time
FROM   system.query.history
WHERE  statement_text ILIKE '%DROP COLUMN%phone%'
  AND  statement_text ILIKE '%crm.customers%'
  AND  start_time > '2026-04-28 06:00'
ORDER  BY start_time DESC LIMIT 10;

2. Check whether a schema migration referencing phone was merged recently:

git log --since='2026-04-27 00:00' --all --grep='phone' \
  -- models/ migrations/

3. Confirm whether customer_facing_app is actively failing on phone reads:

SELECT error_message, COUNT(*) AS occurrences
FROM   app_error_log
WHERE  error_message ILIKE '%phone%'
  AND  occurred_at > '2026-04-29 06:00'
GROUP  BY error_message
ORDER  BY MAX(occurred_at) DESC LIMIT 10;

✓ cross-vendor verified ✓ response contract OK Ready to paste as a ticket

What’s different

Built for the checks you didn’t write.

No checks to define first: Each table is compared with its own history, so there is nothing to configure before it starts working. Add dbt metadata later if you want sharper judgment about what matters.
It explains, it doesn’t just flag: Every alert says what changed, what depends on it, why it matters, and what to look at first, with queries you can copy and run. We never run them for you.
Confidence you can see: Three separate numbers on every alert, plus a decision trace for each incident. We say what we believe and what we’re unsure about.
A second model checks the first: Different LLM providers generate and verify each alert, because they fail in different ways. No single model gets the final word.
Cost limits depth, not coverage: Spend never decides whether we look. When customer-set spend caps arrive (planned, see below), hitting one will reduce how deeply ambiguous cases are analysed. Detection keeps running.

Status

What works today, and what’s next.

We’re in the design-partner phase. “Live preview” opens a real staging environment connected to a real Databricks workspace, behind a preview gate.

LiveReal warehouse, real scans: Connect Databricks with read-only credentials. Scans run daily (you pick the hour) or hourly, plus a “Scan now” button per warehouse. Tested end-to-end against a real Databricks workspace: 93 tables surfaced in a 25-second round trip, cached so repeat reads are instant. The Snowflake connector is built but has not yet run against a live Snowflake account.
LiveAnnotations and ticket write-ups: Upload your dbt manifest and Driftwatcher uses your criticality, owners and meta tags when it judges an incident. Each incident page gives you a ticket-ready write-up to paste into Jira, Linear or GitLab. We never create tickets in your systems and we don’t push notifications; your existing ticket-to-Slack setup handles delivery.
NextStatistics-driven detection on real warehouses: Per-column statistics (null rates, approximate distinct counts, min and max) drive the drift detection. The skeleton is in; the SQL still needs validating against real Snowflake and Databricks workspaces. Once it does, the daily scan produces real incidents, not only structural snapshots.
PlannedSuggested dbt tests: When we flag something that no test covers, we’ll draft the dbt test that would have caught it, as a snippet you review and add. We don’t change your repo.
PlannedA check before the next pipeline step: Your pipeline asks Driftwatcher before its next step and gets back pass, warn or block, with the confidence behind it. Whether the job fails is your pipeline’s decision, never ours. We’ll start in advisory mode, which only reports what it would have blocked.
PlannedWebhooks, billing and spend caps: Wire your CI or dbt orchestrator to a webhook for sub-minute detection after deploys; the scheduled scan stays as the fallback. Billing, the rate card below and customer-set spend caps all land before we open self-serve signup.

Planned pricing

Pay for what you use.

Billing isn’t switched on yet. This is the rate card we plan to launch with, and the numbers may change after design-partner feedback. One rate card, no feature gates, no seats. Your bill depends on three things you can measure and predict.

Checks

$0.005

per snapshot

Each snapshot of each monitored table. The cheap, high-volume layer that everything else rests on.

First 50k a month$0.005

50k to 250k$0.003

Over 250k$0.001

Quick analysis

$0.03

per analysis

When a signal needs evaluating, we run cheap-model composition and reasoning. Every one is charged and shown on your invoice, including those we dismissed.

Deep analysis

$0.30