Dbmate
๐ A lightweight, framework-agnostic database migration tool.
Install / Use
/learn @amacneil/DbmateREADME
Dbmate
Dbmate is a database migration tool that will keep your database schema in sync across multiple developers and your production servers.
It is a standalone command line tool that can be used with Go, Node.js, Python, Ruby, PHP, Rust, C++, or any other language or framework you are using to write database-backed applications. This is especially helpful if you are writing multiple services in different languages, and want to maintain some sanity with consistent development tools.
For a comparison between dbmate and other popular database schema migration tools, please see Alternatives.
Table of Contents
Features
- Supports MySQL, PostgreSQL, SQLite, and ClickHouse
- Uses plain SQL for writing schema migrations
- Migrations are timestamp-versioned, to avoid version number conflicts with multiple developers
- Migrations are run atomically inside a transaction
- Supports creating and dropping databases (handy in development/test)
- Supports saving a
schema.sqlfile to easily diff schema changes in git - Database connection URL is defined using an environment variable (
DATABASE_URLby default), or specified on the command line - Built-in support for reading environment variables from your
.envfile - Easy to distribute, single self-contained binary
- Doesn't try to upsell you on a SaaS service
Installation
NPM
Install using NPM:
npm install --save-dev dbmate
npx dbmate --help
macOS
Install using Homebrew:
brew install dbmate
dbmate --help
Linux
Install the binary directly:
sudo curl -fsSL -o /usr/local/bin/dbmate https://github.com/amacneil/dbmate/releases/latest/download/dbmate-linux-amd64
sudo chmod +x /usr/local/bin/dbmate
/usr/local/bin/dbmate --help
Windows
Install using Scoop
scoop install dbmate
dbmate --help
Docker
Docker images are published to GitHub Container Registry (ghcr.io/amacneil/dbmate).
Remember to set --network=host or see this comment for more tips on using dbmate with docker networking):
docker run --rm -it --network=host ghcr.io/amacneil/dbmate --help
If you wish to create or apply migrations, you will need to use Docker's bind mount feature to make your local working directory (pwd) available inside the dbmate container:
docker run --rm -it --network=host -v "$(pwd)/db:/db" ghcr.io/amacneil/dbmate new create_users_table
Commands
dbmate --help # print usage help
dbmate new # generate a new migration file
dbmate up # create the database (if it does not already exist) and run any pending migrations
dbmate create # create the database
dbmate drop # drop the database
dbmate migrate # run any pending migrations
dbmate rollback # roll back the most recent migration
dbmate down # alias for rollback
dbmate status # show the status of all migrations (supports --exit-code and --quiet)
dbmate dump # write the database schema.sql file
dbmate dump -- [...] # optionally pass additional arguments directly to mysqldump or pg_dump
dbmate load # load schema.sql file to the database
dbmate wait # wait for the database server to become available
Command Line Options
The following options are available with all commands. You must use command line arguments in the order dbmate [global options] command [command options]. Most options can also be configured via environment variables (and loaded from your .env file, which is helpful to share configuration between team members).
--url, -u "protocol://host:port/dbname"- specify the database url directly. (env:DATABASE_URL)--driver "driver_name"- specify the driver to use (if empty, the driver is derived from database URL scheme). (env:DBMATE_DRIVER)--env, -e "DATABASE_URL"- specify an environment variable to read the database connection URL from.--env-file ".env"- specify an alternate environment variables file(s) to load.--migrations-dir, -d "./db/migrations"- where to keep the migration files. (env:DBMATE_MIGRATIONS_DIR)--migrations-table "schema_migrations"- database table to record migrations in. (env:DBMATE_MIGRATIONS_TABLE)--schema-file, -s "./db/schema.sql"- a path to keep the schema.sql file. (env:DBMATE_SCHEMA_FILE)--no-dump-schema- don't auto-update the schema.sql file on migrate/rollback (env:DBMATE_NO_DUMP_SCHEMA)--strict- fail if migrations would be applied out of order (env:DBMATE_STRICT)--wait- wait for the db to become available before executing the subsequent command (env:DBMATE_WAIT)--wait-timeout 60s- timeout for --wait flag (env:DBMATE_WAIT_TIMEOUT)
Usage
Connecting to the Database
Dbmate locates your database using the DATABASE_URL environment variable by default. If you are writing a twelve-factor app, you should be storing all connection strings in environment variables.
To make this easy in development, dbmate looks for a .env file in the current directory, and treats any variables listed there as if they were specified in the current environment (existing environment variables take preference, however).
If you do not already have a .env file, create one and add your database connection URL:
$ cat .env
DATABASE_URL="postgres://postgres@127.0.0.1:5432/myapp_development?sslmode=disable"
DATABASE_URL should be specified in the following format:
protocol://username:password@host:port/database_name?options
protocolmust be one ofmysql,postgres,postgresql,sqlite,sqlite3,clickhouseusernameandpasswordmust be URL encoded (you will get an error if you use special charactors)hostcan be either a hostname or IP addressoptionsare driver-specific (refer to the underlying Go SQL drivers if you wish to use these)
Dbmate can also load the connection URL from a different environment variable. For example, before running your test suite, you may wish to drop and recreate the test database. One easy way to do this is to store your test database connection URL in the TEST_DATABASE_URL environment variable:
$ cat .env
DATABASE_URL="postgres://postgres@127.0.0.1:5432/myapp_dev?sslmode=disable"
TEST_DATABASE_URL="postgres://postgres@127.0.0.1:5432/myapp_test?sslmode=disable"
You can then specify this environment variable in your test script (Makefile or similar):
$ dbmate -e TEST_DATABASE_URL drop
Dropping: myapp_test
$ dbmate -e TEST_DATABASE_URL --no-dump-schema up
Creating: myapp_test
Applying: 20151127184807_create_users_table.sql
Applied: 20151127184807_create_users_table.sql in 123ยตs
Alternatively, you can specify the url directly on the command line:
$ dbmate -u "postgres://postgres@127.0.0.1:5432/myapp_test?sslmode=disable" up
The only advantage of using dbmate -e TEST_DATABASE_URL over dbmate -u $TEST_DATABASE_URL is that the former takes advantage of dbmate's automatic .env file loading.
PostgreSQL
When connecting to Postgres, you may need to add the sslmode=disable option to your connection string, as dbmate by default requires a TLS connection (some other frameworks/languages allow unencrypted connections by default).
DATABASE_URL="postgres://username:password@127.0.0.1:5432/database_name?sslmode=disable"
A socket or host parameter can be specified to connect through a unix socket (note: specify the directory only):
DATABASE_URL="postgres://username:password@/database_name?socket=/var/run/postgresql"
For passwordless authentication such as PostgreSQL peer auth, the password can be omitted (note the @ is still required):
DATABASE_URL="postgres://username@/database_name?socket=/var/run/postgresql"
If the username is also omitted, it defaults to the PGUSER environment variable if set, otherwise the OS username (via lib/pq, matching libpq behavior):
DATABASE_URL="postgres:///database_name?socket=/var/run/postgresql"
A search_path parameter can be used to specify the current schema while applying mi
