Schema drift detection
Where the migration log and the running catalog stop agreeing, why "we have migrations" does not close the gap, and how a rename-aware diff produces a change history the team can trust after the fiftieth scan.
Read the piece
Engine · Schema changes
The diff engine behind your documentation.
Every scan is compared to the previous one. Added, removed, modified, and renamed objects are tagged with a severity. The result keeps your documentation accurate and the change history readable.
What it does
Cosmetic vs breaking, told apart.
Most diff engines read a column rename as a drop plus an add, which gives you two false positives and no idea that the two are related. Taavik pre-filters by data type, nullability, ordinal position and name similarity, then emits a single rename event with a match score, so the documentation and the audit trail both describe what actually happened.
Severity 01
Info
Comment changes, default expression rephrasing, harmless metadata.
Severity 02
Attention
Renames, collation changes, index rebuilds, view body edits.
Severity 03
Likely breaking
Column drops, type changes, foreign key removals, table drops.
Used by
Documentation, history, optional alerts
Documentation updates absorb every change. Alerts subscribe to a severity threshold of your choice.
The idea behind the engine
A diff engine is a schema drift detector with a different name on the door.
Two longer pieces on the reasoning: the first on the gap that opens between the migration folder and the running database, the second on why watching that gap deserves a place next to query performance monitoring. The first is closer to what this page describes; the second reframes it inside the broader observability picture teams already run.
Database observability, for structure
Runtime observability watches queries; structural observability watches the catalog. Both are needed. This piece is on why the second one deserves to be a first-class signal instead of a downstream consequence.
Read the pieceWhat is detected
Tables, columns, indexes, views, routines, foreign keys, triggers.
Tables
- Added, removed
- Renamed (heuristic, scored)
- Comment changed
Columns
- Added, removed
- Renamed, type changed
- Nullability, default, collation
Indexes
- Added, removed
- Column list changed
- Uniqueness changed
Views
- Added, removed
- Body changed
- Column list changed
Routines
- Added, removed
- Body changed
- Parameter list changed
Foreign keys
- Added, removed
- Column or referenced object changed
- On-delete and on-update changes
FAQ
Schema change detection that powers your documentation
Can I subscribe to alerts on schema changes? +
Yes. Create alert rules with a severity threshold and an object-type filter, route them to Slack or email. The rules are off by default so your inbox stays calm. See /schema-change-alerts.
How long is the change history kept? +
Free keeps thirty days, Pro keeps twelve months, Enterprise unlimited. The Markdown documentation always shows the recent change history regardless of the retention plan.
Can I export the change report for an audit? +
Yes. There is a markdown export of the changes for a given range and database. Useful for audits and consulting deliverables.
Try it
See your documentation update itself.
Run a scan, change something on the database, run another scan. The documentation reflects it and the history keeps the date.