Schema Drift Detection - AnomalyArmor

Schema drift occurs when your database structure , intentionally or accidentally. AnomalyArmor detects drift automatically and alerts you before it causes downstream failures.

Before/after comparison showing column added, removed, and modified — Schema diff visualization showing column changes

What is Schema Drift?

Schema drift is any change to database structure:

Column	Before (Discovery T1)	After (Discovery T2)	Change
id	`integer`	`integer`	No change
user_id	`integer`	`integer`	No change
status	`varchar`	—	Removed (or renamed)
order_status	—	`varchar`	Added (possibly renamed from `status`)
total	`decimal`	`decimal`	No change
shipping_date	`timestamp`	—	Removed (or renamed)
shipping_estimate	—	`timestamp`	Added (possibly renamed from `shipping_date`)
delivery_fee	—	`decimal`	Added
created_at	`timestamp`	`timestamp`	No change

Types of Schema Drift

Breaking Changes (High Risk)

Changes that will cause immediate failures:

Change	Example	Impact
Column Removed	`shipping_status` deleted	Queries referencing it fail
Table Removed	`legacy_orders` dropped	All queries to table fail
Column Renamed	`status` → `order_status`	Queries using old name fail
Incompatible Type Change	`varchar` → `integer`	Type mismatches, cast failures

Non-Breaking Changes (Low-Medium Risk)

Changes that usually don’t cause immediate failures:

Change	Example	Impact
Column Added	New `delivery_fee` column	Existing queries work; new data available
Table Added	New `order_items` table	No impact on existing queries
Compatible Type Change	`varchar(50)` → `varchar(100)`	Usually transparent
Constraint Added	New unique constraint	May affect inserts, not selects

How Drift is Detected

AnomalyArmor compares consecutive discovery runs:

Column	Run #1 (Baseline)	Run #2 (Comparison)	Result
id	Present	Present	No change
user_id	Present	Present	No change
status	Present	Missing	Removed
total	Present	Present	No change
order_status	Missing	Present	Added
created_at	Present	Present	No change

Detected drift: Column status removed, column order_status added (possibly a rename, investigate).

Detection Timing

Discovery Schedule	Max Detection Delay
Every 15 minutes	15 minutes
Hourly	1 hour
Daily	24 hours

For production databases, hourly discovery provides a good balance of timeliness and resource usage.

Viewing Schema Drift

Asset Schema History

Navigate to Assets
Click on a table
Select Schema History tab

You’ll see:

Schema change timeline displaying multiple changes with timestamps and details — Schema change history showing column additions, removals, and modifications over time

Change Details

Click any change to see details:

Before state: Previous column definition
After state: New column definition (or “Removed”)
Detection time: When the change was discovered
Discovery run: Which scan found it

Schema Drift Alerts

Setting Up Alerts

Create rules to notify you of drift:

Field	Value
Name	Production Breaking Changes
Event	Schema Change Detected
Data source	`production-postgres`
Schema	`public`, `analytics`
Change type	Column Removed, Table Removed, Type Changed
Destinations	Slack, PagerDuty

Alert Content

Schema drift alerts include:

⚠️ Schema Change Detected

Asset: production.public.orders
Changes detected:
  • Column removed: status (varchar)
  • Column added: order_status (varchar)

Detected: January 15, 2024 at 8:00 AM UTC
Discovery Run: #1234

[View Details] [View Asset]

Common Drift Scenarios

Scenario 1: Column Rename

Symptom: Column removed + column added with similar name

Detected changes:
- Column removed: user_email
- Column added: email_address

This is likely a rename.

Action:

Confirm it’s a rename (ask the upstream team)
Update all downstream references
Verify queries work with new name

Scenario 2: Unannounced Migration

Symptom: Multiple columns changed in related tables

Detected changes in users:
- Column type changed: phone (varchar → jsonb)
- Column added: phone_verified (boolean)

Detected changes in user_profiles:
- Column removed: phone_number

Action:

Identify the migration (check with upstream team)
Review impact on your queries
Update affected models

Scenario 3: Table Dropped

Symptom: Table no longer exists

Asset removed: public.legacy_orders
Last seen: January 14, 2024

This could be:
- Intentional removal
- Renamed table
- Permission change
- Wrong database connected

Action:

Verify if intentional
Update any queries referencing it
Check if data was migrated elsewhere

Scenario 4: Type Change

Symptom: Column data type modified

Column: products.price
Type change: integer → decimal(10,2)

Action:

Review aggregations (SUM, AVG) for precision changes
Check comparisons and arithmetic
Verify no type casting issues

Managing Expected Drift

Planned Schema Changes

When you know changes are coming:

Communicate: Tell your team about upcoming changes
Prepare: Update downstream code in advance (staged rollout)
Execute: Make the schema change
Verify: Confirm AnomalyArmor detects it
Acknowledge: Mark alerts as expected

Disabling Rules During Migrations

For large migrations:

Go to Alerts → Rules
Toggle OFF relevant rules
Perform migration
Review detected changes
Toggle rules back ON

Don’t forget to re-enable rules after migration! Set a calendar reminder.

Drift Prevention

Schema Versioning

Coordinate schema changes with version control:

Use migration tools (Flyway, Alembic, Atlas)
Review migrations before applying
Test in staging first

Change Communication

Establish processes:

Schema change announcements
Dependency mapping
Impact assessment before changes

Backward Compatibility

When changing schemas:

Add new columns instead of modifying existing
Keep old columns during transition periods
Use views to maintain compatibility

Troubleshooting

Drift detected but change was intentional

This is expected behavior. AnomalyArmor doesn’t know intent. It reports all changes. Consider:

Acknowledging the alert
Documenting the change in your records
Disabling rules during planned migrations

Drift not detected

Check discovery schedule: Has discovery run since the change?
Check scope: Is the table in a monitored schema?
Check permissions: Can AnomalyArmor user see the table?
Run manual discovery: Trigger discovery to check now

Too many drift alerts

Filter by change type: Alert only on breaking changes (removed columns/tables)
Exclude dev/test: Don’t monitor volatile environments
Use patterns: Exclude *_temp, *_backup tables

False positive - rename detected as remove+add

This is expected. AnomalyArmor can’t automatically determine if a remove+add pair is a rename. You should:

Investigate the pair manually
Document the rename in your records
Update downstream references

Best Practices

Monitor production closely: Run frequent discovery, alert immediately
Differentiate environments: Different rules for prod vs. dev
Route by change type: Breaking changes → PagerDuty; additions → Email
Review history regularly: Check drift patterns to identify risky areas
Coordinate changes: Communicate schema changes before making them

Common Questions

What counts as a breaking schema change?

Column removals, table removals, column renames, and incompatible type changes (such as varchar to integer) will break queries immediately. Additions and compatible type widenings (varchar(50) to varchar(100)) usually don’t.

How do I avoid alert storms during a planned migration?

Disable the relevant alert rules in Alerts → Rules before the migration, let the changes flow through, then toggle the rules back on. Set a calendar reminder, leaving rules off is a common mistake.

Can AnomalyArmor detect renames automatically?

No. A rename shows up as a column removed plus a column added with a similar name. The UI flags the pair as a possible rename, but confirming intent still requires a human to check with the upstream team.

Why did drift get detected for a change I made intentionally?

AnomalyArmor reports all structural changes, it has no way to know which ones you planned. Acknowledge the alert, document the change, and optionally disable the rule during known migration windows.

What should I do first when a breaking change is detected in production?

Open the asset’s schema history to see exactly what changed and when. Then check downstream dependencies, such as views, models, and dashboards, that reference the affected column or table, and coordinate fixes before more queries fail.

Does detection work on views and materialized views, not just tables?

Yes. Discovery catalogs tables, views, and their underlying columns, so drift on views is detected the same way. See Asset Discovery for what’s captured.

Schema Monitoring Overview

Broader schema monitoring capabilities

Alert Rules

Configure drift alerts

Schema Changes Concept

Deep dive into change types

Asset Discovery

How assets are discovered

​What is Schema Drift?

​Types of Schema Drift

​Breaking Changes (High Risk)

​Non-Breaking Changes (Low-Medium Risk)

​How Drift is Detected

​Detection Timing

​Viewing Schema Drift

​Asset Schema History

​Change Details

​Schema Drift Alerts

​Setting Up Alerts

​Alert Content

​Common Drift Scenarios

​Scenario 1: Column Rename

​Scenario 2: Unannounced Migration

​Scenario 3: Table Dropped

​Scenario 4: Type Change

​Managing Expected Drift

​Planned Schema Changes

​Disabling Rules During Migrations

​Drift Prevention

​Schema Versioning

​Change Communication

​Backward Compatibility

​Troubleshooting

​Best Practices

​Common Questions

​What counts as a breaking schema change?

​How do I avoid alert storms during a planned migration?

​Can AnomalyArmor detect renames automatically?

​Why did drift get detected for a change I made intentionally?

​What should I do first when a breaking change is detected in production?

​Does detection work on views and materialized views, not just tables?

​Related Topics

Schema Monitoring Overview

Alert Rules

Schema Changes Concept

Asset Discovery

What is Schema Drift?

Types of Schema Drift

Breaking Changes (High Risk)

Non-Breaking Changes (Low-Medium Risk)

How Drift is Detected

Detection Timing

Viewing Schema Drift

Asset Schema History

Change Details

Schema Drift Alerts

Setting Up Alerts

Alert Content

Common Drift Scenarios

Scenario 1: Column Rename

Scenario 2: Unannounced Migration

Scenario 3: Table Dropped

Scenario 4: Type Change

Managing Expected Drift

Planned Schema Changes

Disabling Rules During Migrations

Drift Prevention

Schema Versioning

Change Communication

Backward Compatibility

Troubleshooting

Best Practices

Common Questions

What counts as a breaking schema change?

How do I avoid alert storms during a planned migration?

Can AnomalyArmor detect renames automatically?

Why did drift get detected for a change I made intentionally?

What should I do first when a breaking change is detected in production?

Does detection work on views and materialized views, not just tables?

Related Topics