chore(deps): bump drizzle-orm from 1.0.0-beta.16-ea816b6 to 1.0.0-beta.17-e361198

[dependabot]

Bumps drizzle-orm from 1.0.0-beta.16-ea816b6 to 1.0.0-beta.17-e361198.

Release notes

Sourced from drizzle-orm's releases.

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

... (truncated)

Commits

• See full diff in compare view

Dependabot will resolve any conflicts with this PR as long as you don't alter it yourself. You can also trigger a rebase manually by commenting @dependabot rebase.

---

Dependabot commands and options

You can trigger Dependabot actions by commenting on this PR:

• @dependabot rebase will rebase this PR
• @dependabot recreate will recreate this PR, overwriting any edits that have been made to it
• @dependabot show <dependency name> ignore conditions will show all of the ignore conditions of the specified dependency
• @dependabot ignore this major version will close this PR and stop Dependabot creating any more for this major version (unless you reopen the PR or upgrade to it yourself)
• @dependabot ignore this minor version will close this PR and stop Dependabot creating any more for this minor version (unless you reopen the PR or upgrade to it yourself)
• @dependabot ignore this dependency will close this PR and stop Dependabot creating any more for this dependency (unless you reopen the PR or upgrade to it yourself)

[dosubot]

Related Documentation

1 document(s) may need updating based on files changed in this PR:

Zerobyte's Space

Zerobyte Startup Orchestration

View Suggested Changes

@@ -30,8 +30,10 @@
 
 - **Database Directory Creation**: Automatically creates the database directory if it doesn't exist
 - **Legacy Database Migration**: Handles automatic renaming from the legacy `ironmount.db` to `zerobyte.db`
-- **Schema Migration Execution**: Runs Drizzle ORM schema migrations from the `app/drizzle` directory
+- **Schema Migration Execution**: Runs Drizzle ORM schema migrations from the `app/drizzle` directory using Drizzle ORM v1.0.0-beta.17
 - **Foreign Key Constraints**: Automatically enables foreign key constraints for referential integrity
+
+**Migration Table Architecture**: Drizzle ORM beta.17 uses a versioned migration table system that includes `name` and `applied_at` columns in addition to the legacy `id`, `hash`, and `created_at` fields. Migrations are matched by their full folder name (e.g., `20250220153045_brave_wolverine`) rather than timestamps, ensuring reliable identification even when multiple migrations are generated within the same second. When upgrading from older versions, Drizzle automatically upgrades the migration table schema and backfills existing migration records with their folder names, setting `applied_at` to `NULL` to distinguish pre-existing migrations from newly applied ones.
 
 Database schema migrations execute synchronously and fail fast—any failure terminates the bootstrap process, as the application cannot function without a properly initialized database.
 

❌ Declined

Note: You must be authenticated to accept/decline updates.

^{How did I do? Any feedback?}  

[dependabot]

Superseded by #653.