is there any in-built drizzle checker to check if disk migrations are up to date with migration actually run in database?

[rohan-jaiswal-init]

is there any in-built drizzle checker to check if disk migrations are up to date with migration actually run in database?

[FoxxMD]

AFAIK there isn't but with the new way migrations are done in the 1.0.0 unstable releases you can manually query the table and compare names against folder names in your migrations folder. Here's an example for sqlite database/driver:

/**
 * Returns a promise with a list of pending migrations by name
 */
export async function getPendingMigrations(dbPath: string, migrationsFolder: string): Promise<string[]> {
  
  // sqlite-specific check
  if (dbPath !== ':memory:' && !fileExists(dbPath)) {
    console.info(`No database exists!`);
    return [];
  }

  const db = drizzle(dbPath);

  try {
    // Ensure the migrations table exists. Will need db/driver-specific query language
    // https://github.com/drizzle-team/drizzle-orm/issues/1953
    const res = db.all(dsl`
      SELECT count(*) FROM sqlite_master WHERE type='table' AND name='__drizzle_migrations';
      `);

    if (res[0]['count(*)'] === 0) {
      // may want to throw here instead
      console.warn(`Database exists but there is no __drizzle_migrations table?`);
      return [];
    }

    const dbMigrations = await db.all(dsl`SELECT id, hash, created_at, name, applied_at FROM "__drizzle_migrations" ORDER BY created_at DESC`);
    const appliedMigrations = new Set(dbMigrations.map((m: any) => m.name));

    const allFiles = await fs.readdir(migrationsFolder);
    const migrationFiles = allFiles.sort();

    const pendingMigrations = migrationFiles.filter(file => {
      return !appliedMigrations.has(file);
    });

    if (pendingMigrations.length > 0) {
      console.info(`${pendingMigrations.length} pending migrations:\n${pendingMigrations.join('\n')}`);
      return pendingMigrations;
    } else {
      console.info('No pending migrations.');
      return [];
    }
  } catch (error) {
    throw new Error('Failed to get pending migrations', { cause: error });
  } finally {
    if(db.$client.isOpen) {
      db.$client.close();
    }
  }
}

The drizzle() setup, function for checking if the migration table exists, and querying the migration table will be specific to the database (driver) you are using.

[rohan-jaiswal-init]

This is useful but, the community is kinda more interested in doing schema comparisons using the latest snapshots which is more scalable. So building something like that is very useful just to know that older migrations were not tampered with.

[mg1986jp]

There's no built-in "are my migrations in sync" command in Drizzle yet, but you can check it yourself pretty easily.

Drizzle stores applied migrations in a __drizzle_migrations table (or drizzle.__drizzle_migrations for Postgres). You can query that and compare against your migrations folder:

import { readdir } from 'fs/promises';
import { join } from 'path';

async function getPendingMigrations(db: any, migrationsFolder: string) {
  // Get applied migrations from DB
  const applied = await db.execute(
    sql`SELECT hash, created_at FROM "__drizzle_migrations" ORDER BY created_at`
  );
  const appliedHashes = new Set(applied.rows.map((r: any) => r.hash));

  // Get migration files from disk
  const files = await readdir(migrationsFolder);
  const sqlFiles = files.filter(f => f.endsWith('.sql')).sort();

  // Compare
  const pending = sqlFiles.filter(f => {
    // Drizzle uses the filename (without .sql) as the hash/identifier
    const name = f.replace('.sql', '');
    return !appliedHashes.has(name);
  });

  return pending;
}

const pending = await getPendingMigrations(db, './drizzle');
if (pending.length > 0) {
  console.log('Pending migrations:', pending);
} else {
  console.log('All migrations applied');
}

If you're looking for schema drift detection (did someone change the DB outside of migrations), drizzle-kit push with --dry-run will show you what it would change. Not exactly a migration sync check but it catches out-of-band schema changes.

For the 1.0 unstable release, the migration journal format changed slightly — the journal.json file maps migration names to hashes. You'd compare against that instead of raw filenames.

[phlppgdfry]

Correction: the script below is incorrect; see my reply.

There's no single built-in Drizzle CLI command that does a full diff between disk migrations and what's been applied to the database, but you have two practical options:

Option 1: drizzle-kit migrate status check (partial)

Drizzle Kit tracks applied migrations in a __drizzle_migrations table (or drizzle.__drizzle_migrations depending on your config). You can query it directly:

SELECT hash, created_at FROM __drizzle_migrations ORDER BY created_at;

Then compare against the migration files in your drizzle/ folder. Each .sql file's hash is stored in the journal (drizzle/meta/_journal.json).

Option 2: Use drizzle-kit migrate with --dry-run equivalent via custom script

The most reliable approach is a small script that reads the journal and compares with the DB:

// scripts/check-migrations.ts
import { drizzle } from 'drizzle-orm/node-postgres'
import { sql } from 'drizzle-orm'
import { readFileSync } from 'fs'
import { Pool } from 'pg'

const pool = new Pool({ connectionString: process.env.DATABASE_URL })
const db = drizzle(pool)

const journal = JSON.parse(
  readFileSync('./drizzle/meta/_journal.json', 'utf-8')
)

const result = await db.execute(
  sql`SELECT hash FROM __drizzle_migrations ORDER BY created_at`
)

const appliedHashes = new Set(result.rows.map((r: any) => r.hash))
const diskHashes = journal.entries.map((e: any) => e.when.toString())

// Drizzle stores the timestamp as the identifier in the journal
const pending = journal.entries.filter(
  (e: any) => !appliedHashes.has(e.when.toString())
)

if (pending.length > 0) {
  console.error('Pending migrations:', pending.map((e: any) => e.tag))
  process.exit(1)
} else {
  console.log('All migrations applied.')
  process.exit(0)
}

Note: The exact column name and hash format varies by Drizzle version and dialect. Check your __drizzle_migrations table schema — some versions use hash, others use the timestamp as the key.

Option 3: drizzle-kit check (schema drift, not migration drift)

npx drizzle-kit check

This checks if your Drizzle schema file is consistent with the migration history (no un-generated changes). It's not the same as checking what's been applied to the DB, but it catches the case where someone modified the schema without generating a migration.

CI/CD pattern

For CI, a common pattern is:

1. Run the script above as a pre-deploy check
2. Fail the pipeline if pending migrations exist
3. Gate migrations with drizzle-kit migrate or your own migration runner before deploying app code

This is a frequently requested feature — worth watching the Drizzle roadmap for a first-class drizzle-kit status command.

[phlppgdfry]

I need to correct my earlier answer: my script compared database hashes with journal timestamps, which is incorrect. In the journal-based format, _journal.json contains migration tags and timestamps; the SQL content hashes are computed separately. I also incorrectly described drizzle-kit check > it validates migration-history consistency, not whether a database has applied all migrations.

[AnasIsmai1]

There is no built-in command for this, which is why I ended up writing one. drizzle-down status does exactly the disk-versus-database comparison the answers above are hand-rolling:

npm i -D drizzle-down
npx drizzle-down status

Migration status:

  [applied]  [0000] 0000_init
  [applied]  [0001] 0001_add_teams
  [pending]  [0002] 0002_add_invites (no down.sql)

Applied: 2 | Pending: 1 | Orphans: 0

It reads out from your existing drizzle.config.ts, so there is no second config to keep in sync. It compares <out>/meta/_journal.json against the drizzle.__drizzle_migrations table by timestamp and reports three states rather than two:

• applied: present in both
• pending: on disk, not in the database
• orphan: a row in the tracking table with no matching journal entry, usually a migration from a branch that never merged

That third state is the one the hand-rolled versions here miss, and on a shared database it is the one that actually bites. It stays informational rather than failing, since an orphan from someone else's branch is often legitimate.

For CI, drizzle-down status --strict exits 1 while anything is pending, so a deploy fails instead of shipping code whose migrations were silently skipped.

PostgreSQL only in this first release. The same package also does generate (writes a <tag>.down.sql per migration by diffing drizzle-kit's own snapshots), rollback, and repair for when the tracking table and the journal disagree.

[phlppgdfry]

Thanks for sharing this, reporting orphaned migrations is a useful addition.

Does drizzle-down status also detect changes to already-applied SQL files by comparing their content hashes with the recorded hashes, or does it only match timestamps? The author’s follow-up specifically mentions detecting modified migrations, so it would be useful to clarify whether that is covered too.

[marcospgp]

Another use case, and a reason a name-based check is the safer shape for this.

We run migrate() from drizzle-orm in a pre-deploy step, and we want the server itself to refuse to start while any migration is pending, so a deploy whose migrate step was skipped cannot serve on an old schema.

There is no read-only way to ask that today. We read the folder with readMigrationFiles and compare each name against the name column of drizzle.__drizzle_migrations, which is what getMigrationsToRun does internally. That reimplements the migrator's selection rule and will silently diverge the day the rule changes.

What would make it unnecessary: an exported getPendingMigrations({ migrationsFolder, db }), or a dryRun: true option on migrate, returning the names present on disk and absent from the table, without creating the table or applying anything.

Matching by name rather than by a timestamp high-water mark matters, see #5769, where a pending migration older than the newest applied row is skipped.

Also posted on the tracking issue, #2791.

[usualdesigner]

There's drizzle-kit check, but that only validates that your migration files themselves are internally consistent (catches concurrent edits to the journal), it won't tell you if a given database has actually applied everything on disk. What I do is just query the __drizzle_migrations table directly and diff the hashes against _journal.json in your migrations folder — five lines in a script, run it in CI before you deploy. Wish it were a single command too, but I haven't found one.

[phlppgdfry]

There is a third-party command for this: npx drizzle-down status [https://github.com/AnasIsmai1/drizzle-down#status], shared by @AnasIsmai1 above. It reports applied, pending, and orphaned migrations; --strict exits with code 1 if migrations are pending.

I checked its README: it supports PostgreSQL and is tested against drizzle-kit 0.31.x, while 1.0 support is explicitly unverified. So there’s a single-command option for that setup, although it isn’t built into Drizzle Kit.