Beta.22

[AleksandrSherman]

D1 up-migrations

1. An additional file migrator.internal.ts was added to drizzle.orm/src/sqlite-proxy

This file exports a migrateInternal function, which is used by drizzle-orm/src/sqlite-proxy/migrator and drizzle-kit/src/cli/connections (connectToSQLite)

Drizzle-Kit reuses the sqlite-proxy migrator for its migrate command, since it communicates with the D1 database over HTTP. However, the up-migration step in the sqlite-proxy migrator used a transaction only, which is unavailable in D1. Two approaches were considered:
a. fully copy the sqlite-proxy migrator into a d1/migrator-proxy.ts file
b. introduce an optional mode flag on the sqlite-proxy migrate function so that the migrator knows how to execute statements
Chose option b

To avoid changing the public API (since the mode flag is only needed internally by drizzle-kit), all core logic was extracted into migrateInternal inside migrator.internal.ts. The public-facing API remains unchanged. Drizzle-Kit can now explicitly pass the mode flag internally

flowchart TD
    A["sqlite-proxy/migrator.ts migrate(db, ...)"] -->|"call with explicit 'transaction' mode migrateInternal(db, ..., 'mode': transaction)"| B
    B["sqlite-proxy/migrator.internal.ts migrateInternal(db, ..., 'mode': transaction | batch)"]
    C[drizzle-kit migrate command] --> |"call with explicit 'batch' mode migrateInternal(db, ..., 'mode': 'batch')"| B

Loading

Drizzle-Kit and D1

As said above - Drizzle Kit uses the sqlite-proxy driver under the hood

A function called remoteMigrateBatchCallback was added in drizzle-kit/src/cli/connections.ts (connectToSQLite function) to support compatibility with the sqlite-proxy batch method. This enables the use of batch operations within the migrator when running drizzle-kit migrate

2 D1 Migrator

The D1 migrator itself (drizzle-orm/src/d1/migrator.ts) was also updated to use batch operations

Some research was made to find out whether migrate() could be executed inside a Worker. No viable solution was found as Cloudflare Workers do not have access to a persistent filesystem, making it impossible to use migrate() inside of a Worker. This might work if migrations were bundled similarly to how it is done in Expo SQLite, but tests are needed

As of August 2025, Workers have access to a virtual in-memory filesystem via node:fs (with the nodejs_compat flag and a compatibility date of 2025-09-01 or later). However, this VFS is ephemeral — files written to it do not persist across requests and are not shared between Worker instances.

However, for local development it is possible to use Miniflare. Therefore, migrate() was updated to support Miniflare cases

Other

Some issues were fixed