Schema reliability, at the pull request
Your migration passed CI.
It still broke three dashboards.
SchemaDrift Guardian is a CI check that reads your schema changes the way your consumers will. Drop a column, narrow a type, rename a field — the build goes red before merge, with a comment explaining exactly what breaks and what to do about it.
Free during early access · Postgres, Snowflake, OpenAPI
The failure nobody catches in review
What happens
An engineer drops a column that “nothing uses.” The migration runs clean. Tests pass. It ships on a Tuesday.
Three weeks later a nightly job fails, or a dashboard quietly reports the wrong number. The code that broke lives in another repo, owned by another team, and nobody connects it to that pull request.
Why your current tools miss it
Data observability platforms alert you after the pipeline breaks. By then the change is merged, deployed, and you are doing incident response instead of code review.
Schema linters check syntax. They do not know that
varchar(255) → varchar(64) can truncate rows that already exist.
How it works
-
1
Connect a schema
A read-only credential to your Postgres or Snowflake, or a URL to your OpenAPI spec. We take a baseline snapshot. The role needs no table grants at all.
-
2
Add the GitHub Action
On every pull request it stands up a throwaway database, applies that PR’s migrations, and compares the result against your baseline. Your production database is never touched.
-
3
Merge, or don’t
Breaking changes fail the check and post a comment naming each one. Safe changes pass silently. You decide what counts as breaking.
What your team sees on the PR
What it catches
Severity is judged from the consumer’s perspective, and every rule is yours to override.
| Change | Default | Why |
|---|---|---|
| Column dropped | breaking | Every SELECT of it fails on merge |
| Column renamed | breaking | A rename is a drop plus an add, to a consumer |
| Type narrowed | breaking | Existing values may not fit |
| NOT NULL column added | breaking | Writers that omit it start failing |
| Primary key changed | breaking | Upserts and CDC produce duplicates |
| Type widened | warning | Readers safe; upstream writers may not be |
| View body rewritten | warning | Same columns, different rows |
| Nullable column added | info | Additive and safe |
It also understands that NUMBER(18,0) in Snowflake and bigint in
Postgres are the same type, and that numeric(10,2) → numeric(10,4) is
narrowing — the integral capacity shrank from 8 digits to 6.
Built to be trusted with a red build
It never invents a breaking change
A type the engine cannot model is reported as a warning with an explanation — never as a fabricated failure. Guessing wrong in the blocking direction is how a CI gate gets uninstalled.
Our outage is never your outage
If the service is down or errors, the check reports neutral, not failure. A gate that fails closed on its own bugs is worse than no gate.
Read-only, minimum privilege
The monitoring role needs USAGE on the schema and nothing else. No table
grants, no write access, and your production database never sees a pull request.
Pricing
Free while we are in early access. When billing starts, early users keep free access for six months.
Early access
Free
- Unlimited CI checks
- Postgres, Snowflake, OpenAPI
- Snapshot and drift history
- Direct line to the person building it
Starter planned
$99/mo
- 50 monitored schemas
- Everything in early access
- Community support
Team planned
$499/mo
- 500 monitored assets
- Slack and PagerDuty alerts
- Email support
Questions
Does this touch my production database?
Only to read its structure, on a schedule, with a read-only role. Pull requests are checked against a throwaway database the Action creates in CI and destroys afterwards. Your production database never sees a PR.
What if it flags something that isn’t actually breaking?
Every rule has a severity you control. Downgrade column.dropped to a
warning, ignore a table pattern like tmp_*, or make widening types
blocking if you are stricter than we are. Start with
fail-on-drift: false — you get the comments without a blocking check until
you trust the verdicts.
How long does the check take?
Typically a second or two once the shadow database is up. The diff engine is written in Rust and runs the same binary in CI that produced your baseline, so the two can never disagree.
What about Snowflake, BigQuery, dbt?
Postgres, Snowflake, and OpenAPI/JSON Schema work today. BigQuery and dbt manifest ingestion are next. If one of those is what stops you adopting it, say so — it moves up the list.
Who is behind this?
One engineer, building in the open, looking for a handful of design partners who feel this problem often enough to help shape the fix. If that is you, email me directly — you will not get a sales sequence.
Stop finding out three weeks later
If you have ever traced a broken dashboard back to a migration nobody remembered, this was built for you.
Get early access
public.usersemailtype.narrowedvarchar(255)tovarchar(64).public.userslogin_countcolumn.droppedpublic.usersfull_namecolumn.renameddisplay_name(medium confidence).Note the third row: a rename is detected as a rename, not as a drop plus an add — so the message tells the author what actually happened. It still fails the build, because every query still breaks.