14 releases (9 stable)

2.1.0 May 26, 2023
2.0.0 Aug 29, 2022
2.0.0-rc.1 Jul 22, 2022
1.4.0 Jan 21, 2019
0.99.0 Nov 28, 2017

#285 in Database interfaces

Download history 44940/week @ 2023-12-13 34787/week @ 2023-12-20 29651/week @ 2023-12-27 50882/week @ 2024-01-03 54099/week @ 2024-01-10 58387/week @ 2024-01-17 56482/week @ 2024-01-24 60321/week @ 2024-01-31 60288/week @ 2024-02-07 59260/week @ 2024-02-14 61054/week @ 2024-02-21 61011/week @ 2024-02-28 61150/week @ 2024-03-06 57240/week @ 2024-03-13 62329/week @ 2024-03-20 49631/week @ 2024-03-27

242,108 downloads per month
Used in 154 crates (113 directly)


33K SLoC

Provides functions for maintaining database schema.

A database migration always provides procedures to update the schema, as well as to revert itself. Diesel's migrations are versioned, and run in order. Diesel also takes care of tracking which migrations have already been run automatically. Your migrations don't need to be idempotent, as Diesel will ensure no migration is run twice unless it has been reverted.

Migrations should be placed in a /migrations directory at the root of your project (the same directory as Cargo.toml). When any of these functions are run, Diesel will search for the migrations directory in the current directory and its parents, stopping when it finds the directory containing Cargo.toml.

Individual migrations should be a folder containing two files, up.sql and down.sql. up.sql will be used to run the migration, while down.sql will be used for reverting it. The folder itself should have the structure {version}_{migration_name}. It is recommended that you use the timestamp of creation for the version.

Migrations can either be run with the CLI or embedded into the compiled application and executed with code, for example right after establishing a database connection. For more information, consult the embed_migrations! macro.


~29K SLoC