🚀 Feature Request: Single Command to Apply Migrations to All D1 Databases in Wrangler

[sugar-cat7]

I'm currently working with multiple D1 databases with the same schema in a Cloudflare Workers project and facing a workflow challenge. My wrangler.toml file defines numerous D1 database bindings, as shown below:

# Example wrangler.toml configuration
[[d1_databases]]
binding = "Test1"
database_name = "test-1"

[[d1_databases]]
binding = "Test2"
database_name = "test-2"

# ... additional configurations ...

Currently, to apply migrations, I need to execute wrangler d1 migrations apply <database_name> individually for each database. This process is manageable but becomes cumbersome, especially when integrated into CI workflows.

A potential command might look like wrangler d1 migrations apply --all, automatically detecting and applying migrations to each database defined in wrangler.toml.
Alternatively, the introduction of a migration group concept could be considered. This would allow defining groups of databases in wrangler.toml that share the same schema, enabling us to apply migrations to all databases in a group with a single command.

This feature would significantly improve the developer experience and efficiency for projects utilizing Cloudflare's D1 databases with Workers.

[rozenmd]

Agreed, we need to do this.

[serranoarevalo]

Any news on this? If every customer creates a database then I'd have to go migrating one by one to add a new column.

[tohagan]

The only other solution would be to create a SQLite persisted Durable Object instance per tenant (which has been encouraged). That means you apply migrations on DO instantiation (not via wrangler ) but that can get out of hand as the DO schema grows and might even take too long to run for new instances. You also loose many valuable features of D1 like ... read-replication, time travel, encryption at the DB level (not just the filesystem level). Backup & restore might be a headache for large numbers of Tenant DO instances (you really want R2 backups for these DO databases).

I think we want the ability to:

• Create a D1 Namespace binding in which you can create/rename/drop D1 instances at run time.
• Apply a directory of SQL migrations to all D1 instances in Namespace
• Bind a DO class to D1 Namespace so the DO can create/drop/migrate/update a D1 instance per DO instance. D1 SQL migrations can live in an R2 folder so they can be applied at runtime by a DO instance. So in essence, DO's can now get a fully featured D1 database.
• Future: Might allow some DO operations to execute remotely via read-replicated D1.