Databases on RadarModel.com

Database Schema Drift Starts With One Manual ALTER

Sat, 17 Oct 2026 00:00:00 +0000

It’s 2 a.m. and checkout is timing out. Someone finds the slow query, adds an index on production by hand, and the graphs go green. Nobody writes a migration for it. Three weeks later a deploy runs a migration that drops and rebuilds that table, the index is gone, and checkout times out again. Or the other way round: a hotfix makes a column NOT NULL on production only, and the next release, which was tested against staging, fails every insert that leaves it empty.

RadarModel Schema Launches to Catch Database Drift

Sat, 17 Oct 2026 00:00:00 +0000

RadarModel 0.2 adds a second command, radarmodel-schema. It reads the live schema of a Postgres, MySQL, MariaDB or SQLite database, keeps it, reads it again later and tells you what changed. A column dropped by hand, a type changed on production only, an index lost in a rebuild. It’s in the same download as RadarModel AI, open source under the Apache License 2.0, and the code is on GitHub.

Migration tools know what they applied. They don’t look at what’s actually in the database, and a change made around them stays invisible until something fails. RadarModel Schema looks. Why schema drift happens

How RadarModel Schema Was Tested Against Real Databases

Sat, 17 Oct 2026 00:00:00 +0000

A drift detector earns trust slowly and loses it in one night. Report a dropped table that’s still there and the alert channel gets muted. So RadarModel Schema’s tests spend as much effort on what it must not report as on what it must.

None of them use a fake database. SQLite runs on Linux, macOS and Windows. Postgres 12, 16 and 17, MySQL 8.0 and 8.4, and MariaDB 10.6 and 11.4 run in containers on every push. Each test creates its own database on the server, does real DDL to it, and drops it afterwards.