v1.0.0-beta.22

Bug fixed

• drizzle-kit generate fails to generate correct migrations.js file on Windows

• [BUG]: MSSQL real() column returns imprecise float64 values -- missing mapFromDriverValue

• Object key collision

• [BUG]:beta20 Migration to Cloudflare D1 fails

• [BUG]: drizzle-kit migrate: migration SQL failures exit with code 1 but print no error (MigrateProgress hides rejection)

• [BUG]: MS SQL Filtered Index - Drizzle Kit incorrectly generates fully qualified column name in WHERE clause

• [BUG]: [Drizzle-kit][Pg] Altering a UNIQUE constraint: generated SQL ignores the new changes

• [BUG]: Non-commutative migration false positive: create_index commutativity check ignores table name

• Commutativity checks were updated for PostgreSQL and MySQL. Before, create_index statements could be reported as non-commutative even when they targeted different tables, and --ignore-conflicts could still collapse multi-parent history down to a single parent. Now index/table/schema footprints are resolved more accurately, unrelated index branches are accepted, and --ignore-conflicts preserves all open leaf parents for the next migration

• fix: mark mssql and @types/mssql as optional peer dependencies

1.0.0-beta.21

More fixes for the drizzle-kit migration process and commutativity checks

• Adding a value to a PostgreSQL enum will no longer be treated as commutative
• Enum values added in different leaves will now be merged properly

1.0.0-beta.20

• Fixed sql.identifier(), sql.as() escaping issues. Previously all the values passed to this functions were not properly escaped
  causing a possible SQL Injection (CWE-89) vulnerability

Thanks to @EthanKim88, @0x90sh and @wgoodall01 for reaching out to us with a reproduction and suggested fix

0.45.2

• Fixed sql.identifier(), sql.as() escaping issues. Previously all the values passed to this functions were not properly escaped
  causing a possible SQL Injection (CWE-89) vulnerability

Thanks to @EthanKim88, @0x90sh and @wgoodall01 for reaching out to us with a reproduction and suggested fix

v1.0.0-beta.19

New Features

sqlcommenter support for PostgreSQL and MySQL

You can now add custom tags to the query. These tags will be appended to the end of each query, helping the database add metadata/tags to it. This will be especially useful with PlanetScale’s new Database Traffic Control feature

// raw string support
db.select().from().comment("key='val'");
db.select().from().comment("my_first_tag");

// developer friendly dedicated to tags
db.select().from().comment({ key: 'val' });

Example:

db.select().from(comments).comment({ priority: 'high', category: "analytics" });

select "id", "name" from "comments" /*priority='high',category='analytics'*/

The only limitation is that you can't use comments with a prepared statement:

// can't be used
const p = db.select().from().prepare();
// ❌
p.comment({ key: 'val' }).execute();

Bug fixes

• Fixed error message for the defineRelations function
• [BUG]: drizzle-kit push attempts to drop policies in excluded schemas (e.g. cron) despite schemaFilter: ["public"]
• [BUG]: error attempting to drizzle-kit migrate table with char array field generated using drizzle-kit generate
• [BUG]: Ignore Vim *.swp files in drizzle-kit generate
• [BUG]: drizzle-kit pull outputs access method name instead of operator class for ivfflat indexes
• [BUG]: drizzle-kit pull generates not enough data provided to build the relation
• drizzle-kit push fails with Turso/libSQL on table recreation: "cannot commit - no transaction is active"
• [BUG]: Cannot read properties of undefined (reading 'requestLayout') when running drizzle-kit introspect (MySQL)
• [BUG (beta)]: RDS Data API pulling schema error
• [BUG]: drizzle-kit commutative migrations takes only last leaf migration into account

Updates

• Updated migrate() function for mysql dialect to correctly manage multiple databases

• The behavior for reading schema files has been updated. From now only files with the following extensions will be processed: .js .mjs .cjs .jsx .ts .mts .cts .tsx. All other file types will be ignored

v1.0.0-beta.18

New driver support for kit and studio

You can now use the node:sqlite driver to run migrations and browse Drizzle Studio. If node:sqlite is available at runtime, we will automatically detect it and use it.

Fixes

• resolved tsconfig path aliases in drizzle-kit loader using get-tsconfig + jiti alias mapping
• added fixtures and tests covering wildcard and non-wildcard path aliases
• ensured schema load succeeds for alias imports
• Updated to hanji@0.0.8 - native bun stringWidth, stripANSI support, errors for non-TTY environments
• [BUG]: drizzle-kit@1.0.0-beta.13 regression in module resolution
• [BUG]: drizzle-kit does not support node:sqlite

drizzle-kit@0.31.10

• Updated to hanji@0.0.8 - native bun stringWidth, stripANSI support, errors for non-TTY environments
• We've migrated away from esbuild-register to tsx loader, it will now allow to use drizzle-kit seamlessly with both ESM and CJS modules
• We've also added native Bun and Deno launch support, which will not trigger tsx loader and utilise native bun and deno imports capabilities and faster startup times

v1.0.0-beta.17

New SQLite driver node-sqlite

Usage example:

import { drizzle } from 'drizzle-orm/node-sqlite';

const db = drizzle("sqlite.db");

const result = db.select().from(...);

If you need to provide your existing driver:

import { drizzle } from 'drizzle-orm/node-sqlite';
import { DatabaseSync } from 'node:sqlite';

const sqlite = new DatabaseSync('sqlite.db');
const db = drizzle({ client: sqlite });

const result = db.select().from(...);

Fixes

We added a few checks to the migration upgrade logic introduced in beta.16. Now, when your migrations table is upgraded, we double-check that all entities in the table have been updated. If any are missing, we prompt you to pull all migrations into your environment so that we can properly update the drizzle_migrations table

v1.0.0-beta.16

Drizzle ORM beta.16 updates

We've fixed a regression in migrations introduced in beta.13 that persisted through beta.15, and used the opportunity to significantly improve the entire migration infrastructure going forward.

After receiving github issue, we focused on not just fixing the symptoms but rethinking how migrations are tracked, validated, and applied. As we always do with Drizzle we went deeper and redesigned the underlying architecture so it can be stable for all future changes, additions, and edge cases

We went through how we check migrations, how we store them, and how we help developers keep their migration flow reliable. After several iterations of rewriting the migrate function in both ORM and Kit, adding migration table versioning, and building a new commutativity check system: here's what changed and why.

What happened in beta.12–beta.15 and what caused the issue

On latest (pre-beta) versions, the migrations folder used a journal-based structure. A meta/_journal.json file stored a timestamp for each migration in milliseconds. That same millis value was stored in the database's created_at column and used to determine which migrations had been applied. Because the journal enforced ordering, we could simply fetch the last applied migration from the database and apply everything after it.

With the new v3 folder structure (introduced in beta), each migration lives in its own folder named <YYYYMMDDHHmmss>_<name>. This format only has second precision. The new structure also intentionally allows out-of-order migrations (as it should for team workflows), so we switched to reading all migrations from the database and comparing against all local migrations.

The problem appeared after drizzle-kit up converted the old journal structure to v3 folders. It mapped millis timestamps to the YYYYMMDDHHmmss_name format, stripping away the millisecond precision. So when the new migration checker compared what was in the database (millis) to what was on disk (seconds), nothing matched causing migrations to be re-applied on every run.

This only affected beta users who upgraded from the journal-based format. Users on latest were not impacted.

How we fixed it

1. Versioned migration table

Version 0 (old schema):

Column	Type
id	serial
hash	text
created_at	bigint (millis)

Version 1 (new schema):

Column	Type
id	serial
hash	text
created_at	bigint	(legacy)
name	text
applied_at	timestamp

The name column stores the full folder name of the migration (e.g. 20250220153045_brave_wolverine). The applied_at column records when the migration was actually executed. For pre-existing migrations that were backfilled during upgrade, applied_at is set to NULL to distinguish them from newly applied ones.

This versioning system means we can add more fields in the future (like migration state for rollbacks) without any disruption for developers

2. Matching by folder name instead of timestamps

All migrations are now checked against the full folder name: the combination of a 14-digit UTC timestamp and a name suffix (random or custom). Even if two migrations are generated within the same second, the name suffix guarantees uniqueness.

The detection logic is simple: build a set of name values from the database, filter local migrations whose name isn't in that set, and apply those. No more timestamp arithmetic, no more precision mismatches.

3. Automatic upgrade with smart backfilling

When beta.16 detects a version_0 table, it adds the new columns and backfills the name for each existing row using a multi-step matching strategy:

1. Millis match: truncate the stored millis to seconds and match against local migration folder timestamps
2. Hash tiebreaker: if multiple migrations share the same second, use the SQL hash to pick the right one
3. Hash-only fallback: if millis matching fails entirely, fall back to matching by hash alone

This means the upgrade handles all edge cases: normal single-developer projects, teams with closely-timed migrations, and even cases where the old journal data doesn't perfectly align with the new folder names.

4. New commutativity checks (drizzle-kit check)

When working in teams, multiple developers may generate migrations from the same base schema on different branches. These migrations can conflict in non-obvious ways, for example, two branches both altering a column to the same table, or one renaming a table that another is altering.

We built a new drizzle-kit check command that detects these non-commutative migrations. It works by:

• Building a DAG (directed acyclic graph) from snapshot prevIds to understand the branch structure
• Finding fork points where branches diverged
• Computing the DDL diff from the parent snapshot to each branch leaf
• Checking for conflicting operations using a comprehensive footprint map that knows which DDL statement types can interfere with each other

This is available for PostgreSQL and MySQL today. If conflicts are found, the report tells you exactly which migrations on which branches are incompatible and what statements are conflicting.

The new folder structure also changed snapshot metadata from prevId: string to prevIds: string[], enabling proper DAG representation of migration history across branches.

Upgrading to beta.16

The upgrade is automatic. When you run migrate for the first time on beta.16:

1. Drizzle detects your migration table version
2. If it's version_0, it adds the new columns and backfills name from your local migration files
3. All future migrations are tracked by name
4. No manual steps required

If you're also upgrading your migration folder structure from the old journal format, run drizzle-kit up first to convert to the v3 folder layout, then migrate will handle the rest.

Upgrading to beta.16 is not fixing my problem

If you're still hitting migration issues after upgrading, please reach out to us directly - drop a message in Discord or open a GitHub issue with your migration folder structure and the contents of your migrations table. We'll help you sort it out.

drizzle-kit@0.31.9

• drizzle-kit api improvements for D1 connections