Supported baseline procedure when TiDB physical schema is ahead of Drizzle’s existing migration ledger

[Adnivio]

We use drizzle-kit 0.31.5 / drizzle-orm 0.44.6 with TiDB v8.5.3. A populated staging schema contains objects through source migration 0082, but __drizzle_migrations records only through 0049. There are 342 tables and 17,031 rows in a verified snapshot. We mapped 596 intended DDL effects across 0050–0082; replaying them is unsafe.

On a separately restored copy, published drizzle-kit/orm 1.0.0-rc.4 pull --init introspected the schema but failed during migration-metadata application; its generic CLI error did not reveal the underlying exception. It left the 50-row ledger unchanged. We have not run ordinary migrate or edited the historical ledger.

Is there a documented and supported way, for the installed versions or a specified supported upgrade, to adopt the current physical schema as a truthful baseline while retaining historical files for audit and preserving future migrations? If the only supported approach is a new controlled database and a new initial baseline, please specify the required steps and handling of the existing ledger, v0 journal/SQL/snapshots and data transfer. How can we verify on a full restored copy that 0050–0082 will not replay? We will not fabricate migration hashes, insert old migration records, or apply an empty high-timestamp marker.

[DYNOSuprovo]

Here is the supported baseline procedure to reconcile your physical TiDB schema without risking unsafe replays or tampering with hashes:

1. Root Cause of Ledger Drift

In Drizzle Kit, the migration runner compares the files listed in drizzle/meta/_journal.json against the rows in the database's __drizzle_migrations table. Because migrations 0050–0082 already exist in physical DDL but are missing from __drizzle_migrations, executing migrate() will attempt to run them again, causing duplicate table/column DDL collisions.

2. Supported Baseline Workflow: Clean Baseline with Archived History

Rather than manually editing ledger hashes or forcing --init on an actively drifted schema, the clean, supported approach is to archive the historical migrations and establish a fresh, unified baseline:

1. Introspect and Generate the New Baseline:
   Use Drizzle Kit to generate a single baseline migration from the current physical schema:

   npx drizzle-kit introspect --out=./drizzle-new

   This captures the complete physical state (all 342 tables and indices) as your new ground truth.

2. Archive Historical Migrations:
   Move your existing migration directory (drizzle/) to an archive folder (e.g., drizzle-archive/) so all 0001–0082 historical SQL files and snapshots remain in git for audit compliance.

3. Baseline Migration Alignment (drizzle-kit push vs. Migration Stamp):

   • For environments that are already up to date with the introspected state, verify alignment with:

     npx drizzle-kit check

   • In modern Drizzle Kit releases, the recommended approach for databases with an existing schema is to use drizzle-kit push to reconcile the TypeScript schema without re-executing historical SQL scripts, or to establish the new ./drizzle-new folder as the active migration path going forward.

4. Verifying on a Restored Copy:
   Before deploying to production, run your application's migrate() runner against your restored snapshot:

   • Verify in the logs that Drizzle reads the new baseline journal and reports 0 migrations pending or confirms execution of only the new baseline entry.
   • Confirm that no CREATE TABLE statements for 0050–0082 are executed.