[{"data":1,"prerenderedAt":-1},["ShallowReactive",2],{"project-10427":3},{"id":4,"name":5,"fullName":6,"owner":7,"repo":5,"description":8,"homepage":9,"htmlUrl":10,"language":11,"languages":10,"totalLinesOfCode":10,"stars":12,"forks":13,"watchers":14,"openIssues":15,"contributorsCount":16,"subscribersCount":16,"size":16,"stars1d":17,"stars7d":18,"stars30d":19,"stars90d":16,"forks30d":16,"starsTrendScore":18,"compositeScore":20,"rankGlobal":10,"rankLanguage":10,"license":21,"archived":22,"fork":22,"defaultBranch":23,"hasWiki":22,"hasPages":22,"topics":24,"createdAt":10,"pushedAt":10,"updatedAt":42,"readmeContent":43,"aiSummary":44,"trendingCount":16,"starSnapshotCount":16,"syncStatus":17,"lastSyncTime":45,"discoverSource":46},10427,"dbmate","amacneil\u002Fdbmate","amacneil","🚀 A lightweight, framework-agnostic database migration tool.","",null,"Go",6942,350,27,20,0,2,9,66,78.74,"MIT License",false,"main",[25,26,27,28,29,30,31,32,33,34,35,36,37,38,39,40,41],"clickhouse","cpp","database","database-migrations","database-schema","docker","go","golang","migration","migrations","mysql","nodejs","postgres","postgresql","python","rust","sqlite","2026-06-12 04:00:50","# Dbmate\n\n[![Release](https:\u002F\u002Fimg.shields.io\u002Fgithub\u002Frelease\u002Famacneil\u002Fdbmate.svg)](https:\u002F\u002Fgithub.com\u002Famacneil\u002Fdbmate\u002Freleases)\n[![Go Report](https:\u002F\u002Fgoreportcard.com\u002Fbadge\u002Fgithub.com\u002Famacneil\u002Fdbmate)](https:\u002F\u002Fgoreportcard.com\u002Freport\u002Fgithub.com\u002Famacneil\u002Fdbmate)\n[![Reference](https:\u002F\u002Fimg.shields.io\u002Fbadge\u002Fgo.dev-reference-blue?logo=go&logoColor=white)](https:\u002F\u002Fpkg.go.dev\u002Fgithub.com\u002Famacneil\u002Fdbmate\u002Fv2\u002Fpkg\u002Fdbmate)\n\nDbmate is a database migration tool that will keep your database schema in sync across multiple developers and your production servers.\n\nIt 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.\n\nFor a comparison between dbmate and other popular database schema migration tools, please see [Alternatives](#alternatives).\n\n## Table of Contents\n\n- [Features](#features)\n- [Installation](#installation)\n- [Commands](#commands)\n  - [Command Line Options](#command-line-options)\n- [Usage](#usage)\n  - [Connecting to the Database](#connecting-to-the-database)\n    - [PostgreSQL](#postgresql)\n    - [MySQL](#mysql)\n    - [SQLite](#sqlite)\n    - [ClickHouse](#clickhouse)\n    - [BigQuery](#bigquery)\n    - [Spanner](#spanner)\n  - [Creating Migrations](#creating-migrations)\n  - [Running Migrations](#running-migrations)\n  - [Rolling Back Migrations](#rolling-back-migrations)\n  - [Migration Options](#migration-options)\n  - [Waiting For The Database](#waiting-for-the-database)\n  - [Exporting Schema File](#exporting-schema-file)\n- [Library](#library)\n  - [Use dbmate as a library](#use-dbmate-as-a-library)\n  - [Embedding migrations](#embedding-migrations)\n- [Concepts](#concepts)\n  - [Migration files](#migration-files)\n  - [Schema file](#schema-file)\n  - [Schema migrations table](#schema-migrations-table)\n- [Alternatives](#alternatives)\n- [Contributing](#contributing)\n\n## Features\n\n- Supports MySQL, PostgreSQL, SQLite, and ClickHouse\n- Uses plain SQL for writing schema migrations\n- Migrations are timestamp-versioned, to avoid version number conflicts with multiple developers\n- Migrations are run atomically inside a transaction\n- Supports creating and dropping databases (handy in development\u002Ftest)\n- Supports saving a `schema.sql` file to easily diff schema changes in git\n- Database connection URL is defined using an environment variable (`DATABASE_URL` by default), or specified on the command line\n- Built-in support for reading environment variables from your `.env` file\n- Easy to distribute, single self-contained binary\n- Doesn't try to upsell you on a SaaS service\n\n## Installation\n\n**NPM**\n\nInstall using [NPM](https:\u002F\u002Fwww.npmjs.com\u002F):\n\n```sh\nnpm install --save-dev dbmate\nnpx dbmate --help\n```\n\n**macOS**\n\nInstall using [Homebrew](https:\u002F\u002Fbrew.sh\u002F):\n\n```sh\nbrew install dbmate\ndbmate --help\n```\n\n**Linux**\n\nInstall the binary directly:\n\n```sh\nsudo curl -fsSL -o \u002Fusr\u002Flocal\u002Fbin\u002Fdbmate https:\u002F\u002Fgithub.com\u002Famacneil\u002Fdbmate\u002Freleases\u002Flatest\u002Fdownload\u002Fdbmate-linux-amd64\nsudo chmod +x \u002Fusr\u002Flocal\u002Fbin\u002Fdbmate\n\u002Fusr\u002Flocal\u002Fbin\u002Fdbmate --help\n```\n\n**Windows**\n\nInstall using [Scoop](https:\u002F\u002Fscoop.sh)\n\n```pwsh\nscoop install dbmate\ndbmate --help\n```\n\n**Docker**\n\nDocker images are published to GitHub Container Registry ([`ghcr.io\u002Famacneil\u002Fdbmate`](https:\u002F\u002Fghcr.io\u002Famacneil\u002Fdbmate)).\n\nRemember to set `--network=host` or see [this comment](https:\u002F\u002Fgithub.com\u002Famacneil\u002Fdbmate\u002Fissues\u002F128#issuecomment-615924611) for more tips on using dbmate with docker networking):\n\n```sh\ndocker run --rm -it --network=host ghcr.io\u002Famacneil\u002Fdbmate --help\n```\n\nIf you wish to create or apply migrations, you will need to use Docker's [bind mount](https:\u002F\u002Fdocs.docker.com\u002Fstorage\u002Fbind-mounts\u002F) feature to make your local working directory (`pwd`) available inside the dbmate container:\n\n```sh\ndocker run --rm -it --network=host -v \"$(pwd)\u002Fdb:\u002Fdb\" ghcr.io\u002Famacneil\u002Fdbmate new create_users_table\n```\n\n## Commands\n\n```sh\ndbmate --help         # print usage help\ndbmate new            # generate a new migration file\ndbmate up             # create the database (if it does not already exist) and run any pending migrations\ndbmate create         # create the database\ndbmate drop           # drop the database\ndbmate migrate        # run any pending migrations\ndbmate rollback       # roll back the most recent migration\ndbmate down           # alias for rollback\ndbmate status         # show the status of all migrations (supports --exit-code and --quiet)\ndbmate dump           # write the database schema.sql file\ndbmate dump -- [...]  # optionally pass additional arguments directly to mysqldump or pg_dump\ndbmate load           # load schema.sql file to the database\ndbmate wait           # wait for the database server to become available\n```\n\n### Command Line Options\n\nThe 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).\n\n- `--url, -u \"protocol:\u002F\u002Fhost:port\u002Fdbname\"` - specify the database url directly. _(env: `DATABASE_URL`)_\n- `--driver \"driver_name\"` - specify the driver to use (if empty, the driver is derived from database URL scheme). _(env: `DBMATE_DRIVER`)_\n- `--env, -e \"DATABASE_URL\"` - specify an environment variable to read the database connection URL from.\n- `--env-file \".env\"` - specify an alternate environment variables file(s) to load.\n- `--migrations-dir, -d \".\u002Fdb\u002Fmigrations\"` - where to keep the migration files. _(env: `DBMATE_MIGRATIONS_DIR`)_\n- `--migrations-table \"schema_migrations\"` - database table to record migrations in. _(env: `DBMATE_MIGRATIONS_TABLE`)_\n- `--schema-file, -s \".\u002Fdb\u002Fschema.sql\"` - a path to keep the schema.sql file. _(env: `DBMATE_SCHEMA_FILE`)_\n- `--no-dump-schema` - don't auto-update the schema.sql file on migrate\u002Frollback _(env: `DBMATE_NO_DUMP_SCHEMA`)_\n- `--strict` - fail if migrations would be applied out of order _(env: `DBMATE_STRICT`)_\n- `--wait` - wait for the db to become available before executing the subsequent command _(env: `DBMATE_WAIT`)_\n- `--wait-timeout 60s` - timeout for --wait flag _(env: `DBMATE_WAIT_TIMEOUT`)_\n\n## Usage\n\n### Connecting to the Database\n\nDbmate locates your database using the `DATABASE_URL` environment variable by default. If you are writing a [twelve-factor app](http:\u002F\u002F12factor.net\u002F), you should be storing all connection strings in environment variables.\n\nTo 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).\n\nIf you do not already have a `.env` file, create one and add your database connection URL:\n\n```sh\n$ cat .env\nDATABASE_URL=\"postgres:\u002F\u002Fpostgres@127.0.0.1:5432\u002Fmyapp_development?sslmode=disable\"\n```\n\n`DATABASE_URL` should be specified in the following format:\n\n```\nprotocol:\u002F\u002Fusername:password@host:port\u002Fdatabase_name?options\n```\n\n- `protocol` must be one of `mysql`, `postgres`, `postgresql`, `sqlite`, `sqlite3`, `clickhouse`\n- `username` and `password` must be URL encoded (you will get an error if you use special charactors)\n- `host` can be either a hostname or IP address\n- `options` are driver-specific (refer to the underlying Go SQL drivers if you wish to use these)\n\nDbmate 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:\n\n```sh\n$ cat .env\nDATABASE_URL=\"postgres:\u002F\u002Fpostgres@127.0.0.1:5432\u002Fmyapp_dev?sslmode=disable\"\nTEST_DATABASE_URL=\"postgres:\u002F\u002Fpostgres@127.0.0.1:5432\u002Fmyapp_test?sslmode=disable\"\n```\n\nYou can then specify this environment variable in your test script (Makefile or similar):\n\n```sh\n$ dbmate -e TEST_DATABASE_URL drop\nDropping: myapp_test\n$ dbmate -e TEST_DATABASE_URL --no-dump-schema up\nCreating: myapp_test\nApplying: 20151127184807_create_users_table.sql\nApplied: 20151127184807_create_users_table.sql in 123µs\n```\n\nAlternatively, you can specify the url directly on the command line:\n\n```sh\n$ dbmate -u \"postgres:\u002F\u002Fpostgres@127.0.0.1:5432\u002Fmyapp_test?sslmode=disable\" up\n```\n\nThe 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.\n\n#### PostgreSQL\n\nWhen 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\u002Flanguages allow unencrypted connections by default).\n\n```sh\nDATABASE_URL=\"postgres:\u002F\u002Fusername:password@127.0.0.1:5432\u002Fdatabase_name?sslmode=disable\"\n```\n\nA `socket` or `host` parameter can be specified to connect through a unix socket (note: specify the directory only):\n\n```sh\nDATABASE_URL=\"postgres:\u002F\u002Fusername:password@\u002Fdatabase_name?socket=\u002Fvar\u002Frun\u002Fpostgresql\"\n```\n\nFor passwordless authentication such as PostgreSQL [peer auth](https:\u002F\u002Fwww.postgresql.org\u002Fdocs\u002Fcurrent\u002Fauth-pg-hba-conf.html), the password can be omitted (note the `@` is still required):\n\n```sh\nDATABASE_URL=\"postgres:\u002F\u002Fusername@\u002Fdatabase_name?socket=\u002Fvar\u002Frun\u002Fpostgresql\"\n```\n\nIf the username is also omitted, it defaults to the `PGUSER` environment variable if set, otherwise the OS username (via `lib\u002Fpq`, matching `libpq` behavior):\n\n```sh\nDATABASE_URL=\"postgres:\u002F\u002F\u002Fdatabase_name?socket=\u002Fvar\u002Frun\u002Fpostgresql\"\n```\n\nA `search_path` parameter can be used to specify the [current schema](https:\u002F\u002Fwww.postgresql.org\u002Fdocs\u002F13\u002Fddl-schemas.html#DDL-SCHEMAS-PATH) while applying migrations, as well as for dbmate's `schema_migrations` table.\nIf the schema does not exist, it will be created automatically. If multiple comma-separated schemas are passed, the first will be used for the `schema_migrations` table.\n\n```sh\nDATABASE_URL=\"postgres:\u002F\u002Fusername:password@127.0.0.1:5432\u002Fdatabase_name?search_path=myschema\"\n```\n\n```sh\nDATABASE_URL=\"postgres:\u002F\u002Fusername:password@127.0.0.1:5432\u002Fdatabase_name?search_path=myschema,public\"\n```\n\n#### MySQL\n\n```sh\nDATABASE_URL=\"mysql:\u002F\u002Fusername:password@127.0.0.1:3306\u002Fdatabase_name\"\n```\n\nA `socket` parameter can be specified to connect through a unix socket:\n\n```sh\nDATABASE_URL=\"mysql:\u002F\u002Fusername:password@\u002Fdatabase_name?socket=\u002Fvar\u002Frun\u002Fmysqld\u002Fmysqld.sock\"\n```\n\n#### SQLite\n\nSQLite databases are stored on the filesystem, so you do not need to specify a host. By default, files are relative to the current directory. For example, the following will create a database at `.\u002Fdb\u002Fdatabase.sqlite3`:\n\n```sh\nDATABASE_URL=\"sqlite:db\u002Fdatabase.sqlite3\"\n```\n\nTo specify an absolute path, add a forward slash to the path. The following will create a database at `\u002Ftmp\u002Fdatabase.sqlite3`:\n\n```sh\nDATABASE_URL=\"sqlite:\u002Ftmp\u002Fdatabase.sqlite3\"\n```\n\nNote that for some common [settings](https:\u002F\u002Fsqlite.org\u002Fpragma.html) like `journal_mode` to improve performance, transactions need to be disabled for that migration file, e.g.\n\n```sql\n-- migrate:up transaction:false\nPRAGMA journal_mode = WAL;\n```\n\nOtherwise the migration will fail with \"Error: cannot change into wal mode from within a transaction\".\n\n#### ClickHouse\n\nDbmate supports connecting to ClickHouse using native TCP (default) or HTTP\u002FHTTPS.\n\n##### Native (TCP)\n\nBy default, the `clickhouse:\u002F\u002F` scheme uses the native protocol on port `9000`.\n\n```sh\nDATABASE_URL=\"clickhouse:\u002F\u002Fusername:password@127.0.0.1:9000\u002Fdatabase_name\"\n```\n\n##### HTTP \u002F HTTPS\n\nYou can use `clickhouse+http:\u002F\u002F` (deafult port 8123) or `clickhouse+https:\u002F\u002F` (default port 8443).\n\n```sh\n# HTTP (Defaults to port 8123)\nDATABASE_URL=\"clickhouse+http:\u002F\u002Fusername:password@127.0.0.1:8123\u002Fdatabase_name\"\n\n# HTTPS (Defaults to port 8443)\nDATABASE_URL=\"clickhouse+https:\u002F\u002Fusername:password@127.0.0.1:8443\u002Fdatabase_name\"\n```\n\n##### Using the --driver flag\n\nYou can use the ClickHouse driver with a standard http\u002Fhttps\u002Ftcp URL by providing the --driver flag\n\n```sh\n# Connect via HTTP using generic URL syntax\ndbmate --driver clickhouse --url \"http:\u002F\u002Fusername:password@127.0.0.1:8123\u002Fdatabase_name\" status\n\ndbmate --driver clickhouse --url \"https:\u002F\u002Fusername:password@127.0.0.1:8443\u002Fdatabase_name\" status\n\n# Better to rely on the standard clickhouse:\u002F\u002F scheme, but this is supported\ndbmate --driver clickhouse --url \"tcp:\u002F\u002Fusername:password@127.0.0.1:9000\u002Fdatabase_name\" status\n```\n\nTo work with ClickHouse cluster, there are 4 connection query parameters that can be supplied:\n\n- `on_cluster` - Indicataion to use cluster statements and replicated migration table. (default: `false`) If this parameter is not supplied, other cluster related query parameters are ignored.\n\n```sh\nDATABASE_URL=\"clickhouse:\u002F\u002Fusername:password@127.0.0.1:9000\u002Fdatabase_name?on_cluster\"\n\nDATABASE_URL=\"clickhouse:\u002F\u002Fusername:password@127.0.0.1:9000\u002Fdatabase_name?on_cluster=true\"\n```\n\n- `cluster_macro` (Optional) - Macro value to be used for ON CLUSTER statements and for the replciated migration table engine zookeeper path. (default: `{cluster}`)\n\n```sh\nDATABASE_URL=\"clickhouse:\u002F\u002Fusername:password@127.0.0.1:9000\u002Fdatabase_name?on_cluster&cluster_macro={my_cluster}\"\n```\n\n- `replica_macro` (Optional) - Macro value to be used for the replica name in the replciated migration table engine. (default: `{replica}`)\n\n```sh\nDATABASE_URL=\"clickhouse:\u002F\u002Fusername:password@127.0.0.1:9000\u002Fdatabase_name?on_cluster&replica_macro={my_replica}\"\n```\n\n- `zoo_path` (Optional) - The path to the table migration in ClickHouse\u002FZoo Keeper. (default: `\u002Fclickhouse\u002Ftables\u002F\u003Ccluster_macro>\u002F{table}`)\n\n```sh\nDATABASE_URL=\"clickhouse:\u002F\u002Fusername:password@127.0.0.1:9000\u002Fdatabase_name?on_cluster&zoo_path=\u002Fzk\u002Fpath\u002Ftables\"\n```\n\n[See other supported connection options](https:\u002F\u002Fgithub.com\u002FClickHouse\u002Fclickhouse-go#dsn).\n\n#### BigQuery\n\nFollow the following format for `DATABASE_URL` when connecting to actual BigQuery in GCP:\n\n```\nbigquery:\u002F\u002Fprojectid\u002Flocation\u002Fdataset\n```\n\n`projectid` (mandatory) - Project ID\n\n`dataset` (mandatory) - Dataset name within the Project\n\n`location` (optional) - Where Dataset is created\n\n_NOTE: Follow [this doc](https:\u002F\u002Fcloud.google.com\u002Fdocs\u002Fauthentication\u002Fprovide-credentials-adc) on how to set `GOOGLE_APPLICATION_CREDENTIALS` environment variable for proper Authentication_\n\nFollow the following format if trying to connect to a custom endpoint e.g. [BigQuery Emulator](https:\u002F\u002Fgithub.com\u002Fgoccy\u002Fbigquery-emulator)\n\n```\nbigquery:\u002F\u002Fhost:port\u002Fprojectid\u002Flocation\u002Fdataset?disable_auth=true\n```\n\n`disable_auth` (optional) - Pass `true` to skip Authentication, use only for testing and connecting to emulator.\n\n#### Spanner\n\nSpanner support is currently limited to databases using the [PostgreSQL Dialect](https:\u002F\u002Fcloud.google.com\u002Fspanner\u002Fdocs\u002Fpostgresql-interface), which must be chosen during database creation. For future Spanner with GoogleSQL support, see [this discussion](https:\u002F\u002Fgithub.com\u002Famacneil\u002Fdbmate\u002Fdiscussions\u002F369).\n\nSpanner with the Postgres interface requires that the [PGAdapter](https:\u002F\u002Fcloud.google.com\u002Fspanner\u002Fdocs\u002Fpgadapter) is running. Use the following format for `DATABASE_URL`, with the host and port set to where the PGAdapter is running:\n\n```shell\nDATABASE_URL=\"spanner-postgres:\u002F\u002F127.0.0.1:5432\u002Fdatabase_name?sslmode=disable\"\n```\n\nNote that specifying a username and password is not necessary, as authentication is handled by the PGAdapter (they will be ignored by the PGAdapter if specified).\n\nOther options of the [postgres driver](#postgresql) are supported.\n\nSpanner also doesn't allow DDL to be executed inside explicit transactions. You must therefore specify `transaction:false` on migrations that include DDL:\n\n```sql\n-- migrate:up transaction:false\nCREATE TABLE ...\n\n-- migrate:down transaction:false\nDROP TABLE ...\n```\n\nSchema dumps are not currently supported, as `pg_dump` uses functions that are not provided by Spanner.\n\n### Creating Migrations\n\nTo create a new migration, run `dbmate new create_users_table`. You can name the migration anything you like. This will create a file `db\u002Fmigrations\u002F20151127184807_create_users_table.sql` in the current directory:\n\n```sql\n-- migrate:up\n\n-- migrate:down\n```\n\nTo write a migration, simply add your SQL to the `migrate:up` section:\n\n```sql\n-- migrate:up\ncreate table users (\n  id integer,\n  name varchar(255),\n  email varchar(255) not null\n);\n\n-- migrate:down\n```\n\nFor related changes, it is possible to include multiple migrations in a single file using additional `migrate:up` and `migrate:down` sections. Migration file either succeeds or fails as a whole.\n\n```sql\n-- migrate:up\nCREATE TABLE users (id SERIAL PRIMARY KEY);\n\n-- migrate:down\nDROP TABLE users;\n\n-- migrate:up\nALTER TABLE users ADD COLUMN email VARCHAR;\n\n-- migrate:down\nALTER TABLE users DROP COLUMN email;\n```\n\n> Note: Migration files are named in the format `[version]_[description].sql`. Only the version (defined as all leading numeric characters in the file name) is recorded in the database, so you can safely rename a migration file without having any effect on its current application state.\n\n### Running Migrations\n\nRun `dbmate up` to run any pending migrations.\n\n```sh\n$ dbmate up\nCreating: myapp_development\nApplying: 20151127184807_create_users_table.sql\nApplied: 20151127184807_create_users_table.sql in 123µs\nWriting: .\u002Fdb\u002Fschema.sql\n```\n\n> Note: `dbmate up` will create the database if it does not already exist (assuming the current user has permission to create databases). If you want to run migrations without creating the database, run `dbmate migrate`.\n\nPending migrations are always applied in numerical order. However, dbmate does not prevent migrations from being applied out of order if they are committed independently (for example: if a developer has been working on a branch for a long time, and commits a migration which has a lower version number than other already-applied migrations, dbmate will simply apply the pending migration). See [#159](https:\u002F\u002Fgithub.com\u002Famacneil\u002Fdbmate\u002Fissues\u002F159) for a more detailed explanation.\n\n### Rolling Back Migrations\n\nBy default, dbmate doesn't know how to roll back a migration. In development, it's often useful to be able to revert your database to a previous state. To accomplish this, implement the `migrate:down` section:\n\n```sql\n-- migrate:up\ncreate table users (\n  id integer,\n  name varchar(255),\n  email varchar(255) not null\n);\n\n-- migrate:down\ndrop table users;\n```\n\nRun `dbmate rollback` to roll back the most recent migration:\n\n```sh\n$ dbmate rollback\nRolling back: 20151127184807_create_users_table.sql\nRolled back: 20151127184807_create_users_table.sql in 123µs\nWriting: .\u002Fdb\u002Fschema.sql\n```\n\n### Migration Options\n\ndbmate supports options passed to a migration block in the form of `key:value` pairs. List of supported options:\n\n- `transaction`\n\n**transaction**\n\n`transaction` is useful if you do not want to run SQL inside a transaction:\n\n```sql\n-- migrate:up transaction:false\nALTER TYPE colors ADD VALUE 'orange' AFTER 'red';\n```\n\n`transaction` will default to `true` if your database supports it.\n\n### Waiting For The Database\n\nIf you use a Docker development environment for your project, you may encounter issues with the database not being immediately ready when running migrations or unit tests. This can be due to the database server having only just started.\n\nIn general, your application should be resilient to not having a working database connection on startup. However, for the purpose of running migrations or unit tests, this is not practical. The `wait` command avoids this situation by allowing you to pause a script or other application until the database is available. Dbmate will attempt a connection to the database server every second, up to a maximum of 60 seconds.\n\nIf the database is available, `wait` will return no output:\n\n```sh\n$ dbmate wait\n```\n\nIf the database is unavailable, `wait` will block until the database becomes available:\n\n```sh\n$ dbmate wait\nWaiting for database....\n```\n\nYou can also use the `--wait` flag with other commands if you sometimes see failures caused by the database not yet being ready:\n\n```sh\n$ dbmate --wait up\nWaiting for database....\nCreating: myapp_development\n```\n\nYou can customize the timeout using `--wait-timeout` (default 60s). If the database is still not available, the command will return an error:\n\n```sh\n$ dbmate --wait-timeout=5s wait\nWaiting for database.....\nError: unable to connect to database: dial tcp 127.0.0.1:5432: connect: connection refused\n```\n\nPlease note that the `wait` command does not verify whether your specified database exists, only that the server is available and ready (so it will return success if the database server is available, but your database has not yet been created).\n\n### Exporting Schema File\n\nWhen you run the `up`, `migrate`, or `rollback` commands, dbmate will automatically create a `.\u002Fdb\u002Fschema.sql` file containing a complete representation of your database schema. Dbmate keeps this file up to date for you, so you should not manually edit it.\n\nIt is recommended to check this file into source control, so that you can easily review changes to the schema in commits or pull requests. It's also possible to use this file when you want to quickly load a database schema, without running each migration sequentially (for example in your test harness). However, if you do not wish to save this file, you could add it to your `.gitignore`, or pass the `--no-dump-schema` command line option.\n\nTo dump the `schema.sql` file without performing any other actions, run `dbmate dump`. Unlike other dbmate actions, this command relies on the respective `pg_dump`, `mysqldump`, or `sqlite3` commands being available in your PATH. If these tools are not available, dbmate will silently skip the schema dump step during `up`, `migrate`, or `rollback` actions. You can diagnose the issue by running `dbmate dump` and looking at the output:\n```sh\n$ dbmate dump\nexec: \"pg_dump\": executable file not found in $PATH\n```\nOn Ubuntu or Debian systems, you can fix this by installing `postgresql-client`, `mysql-client`, or `sqlite3` respectively. Ensure that the package version you install is greater than or equal to the version running on your database server.\n\nIt is possible to pass additional arguments directly to mysqldump or pg_dump:\n```sh\n$ dbmate dump -- --flag1 --flag2\n$ dbmate --url=\"...\" dump -- --restrict-key=restrict_key\n```\nfor mysqldump:\n```sh\nmysqldump [default_options] [your_arguments_go_here] dbname\n```\nfor pg_dump:\n```sh\npg_dump [default_options] [your_arguments_go_here] dbname\n``` \n\n> Note: The `schema.sql` file will contain a complete schema for your database, even if some tables or columns were created outside of dbmate migrations.\n\n## Library\n\n### Use dbmate as a library\n\nDbmate is designed to be used as a CLI with any language or framework, but it can also be used as a library in a Go application.\n\nHere is a simple example. Remember to import the driver you need!\n\n```go\npackage main\n\nimport (\n\t\"net\u002Furl\"\n\n\t\"github.com\u002Famacneil\u002Fdbmate\u002Fv2\u002Fpkg\u002Fdbmate\"\n\t_ \"github.com\u002Famacneil\u002Fdbmate\u002Fv2\u002Fpkg\u002Fdriver\u002Fsqlite\"\n)\n\nfunc main() {\n\tu, _ := url.Parse(\"sqlite:foo.sqlite3\")\n\tdb := dbmate.New(u)\n\n\terr := db.CreateAndMigrate()\n\tif err != nil {\n\t\tpanic(err)\n\t}\n}\n```\n\nSee the [reference documentation](https:\u002F\u002Fpkg.go.dev\u002Fgithub.com\u002Famacneil\u002Fdbmate\u002Fv2\u002Fpkg\u002Fdbmate) for more options.\n\n### Embedding migrations\n\nMigrations can be embedded into your application binary using Go's [embed](https:\u002F\u002Fpkg.go.dev\u002Fembed) functionality.\n\nUse `db.FS` to specify the filesystem used for reading migrations:\n\n```go\npackage main\n\nimport (\n\t\"embed\"\n\t\"fmt\"\n\t\"net\u002Furl\"\n\n\t\"github.com\u002Famacneil\u002Fdbmate\u002Fv2\u002Fpkg\u002Fdbmate\"\n\t_ \"github.com\u002Famacneil\u002Fdbmate\u002Fv2\u002Fpkg\u002Fdriver\u002Fsqlite\"\n)\n\n\u002F\u002Fgo:embed db\u002Fmigrations\u002F*.sql\nvar fs embed.FS\n\nfunc main() {\n\tu, _ := url.Parse(\"sqlite:foo.sqlite3\")\n\tdb := dbmate.New(u)\n\tdb.FS = fs\n\n\tfmt.Println(\"Migrations:\")\n\tmigrations, err := db.FindMigrations()\n\tif err != nil {\n\t\tpanic(err)\n\t}\n\tfor _, m := range migrations {\n\t\tfmt.Println(m.Version, m.FilePath)\n\t}\n\n\tfmt.Println(\"\\nApplying...\")\n\terr = db.CreateAndMigrate()\n\tif err != nil {\n\t\tpanic(err)\n\t}\n}\n```\n\n## Concepts\n\n### Migration files\n\nMigration files are very simple, and are stored in `.\u002Fdb\u002Fmigrations` by default. You can create a new migration file named `[date]_create_users.sql` by running `dbmate new create_users`.\nHere is an example:\n\n```sql\n-- migrate:up\ncreate table users (\n  id integer,\n  name varchar(255),\n);\n\n-- migrate:down\ndrop table if exists users;\n```\n\nBoth up and down migrations are stored in the same file, for ease of editing. Both up and down directives are required, even if you choose not to implement the down migration.\n\nWhen you apply a migration dbmate only stores the version number, not the contents, so you should always rollback a migration before modifying its contents. For this reason, you can safely rename a migration file without affecting its applied status, as long as you keep the version number intact.\n\n### Schema file\n\nThe schema file is written to `.\u002Fdb\u002Fschema.sql` by default. It is a complete dump of your database schema, including any applied migrations, and any other modifications you have made.\n\nThis file should be checked in to source control, so that you can easily compare the diff of a migration. You can use the schema file to quickly restore your database without needing to run all migrations.\n\n### Schema migrations table\n\nDbmate stores a record of each applied migration in table named `schema_migrations`. This table will be created for you automatically if it does not already exist.\n\nThe table is very simple:\n\n```sql\nCREATE TABLE IF NOT EXISTS schema_migrations (\n  version VARCHAR(255) PRIMARY KEY\n)\n```\n\nYou can customize the name of this table using the `--migrations-table` flag or `DBMATE_MIGRATIONS_TABLE` environment variable.\n\n## Alternatives\n\nWhy another database schema migration tool? Dbmate was inspired by many other tools, primarily [Active Record Migrations](http:\u002F\u002Fguides.rubyonrails.org\u002Factive_record_migrations.html), with the goals of being trivial to configure, and language & framework independent. Here is a comparison between dbmate and other popular migration tools.\n\n|                                                              | [dbmate](https:\u002F\u002Fgithub.com\u002Famacneil\u002Fdbmate) | [goose](https:\u002F\u002Fgithub.com\u002Fpressly\u002Fgoose) | [sql-migrate](https:\u002F\u002Fgithub.com\u002Frubenv\u002Fsql-migrate) | [golang-migrate](https:\u002F\u002Fgithub.com\u002Fgolang-migrate\u002Fmigrate) | [activerecord](http:\u002F\u002Fguides.rubyonrails.org\u002Factive_record_migrations.html) | [sequelize](http:\u002F\u002Fdocs.sequelizejs.com\u002Fmanual\u002Ftutorial\u002Fmigrations.html) | [flyway](https:\u002F\u002Fflywaydb.org\u002F) | [sqitch](https:\u002F\u002Fsqitch.org\u002F) |\n| ------------------------------------------------------------ | :------------------------------------------: | :---------------------------------------: | :--------------------------------------------------: | :---------------------------------------------------------: | :-------------------------------------------------------------------------: | :----------------------------------------------------------------------: | :-----------------------------: | :---------------------------: |\n| **Features**                                                 |\n| Plain SQL migration files                                    |              :white_check_mark:              |            :white_check_mark:             |                  :white_check_mark:                  |                     :white_check_mark:                      |                                                                             |                                                                          |       :white_check_mark:        |      :white_check_mark:       |\n| Support for creating and dropping databases                  |              :white_check_mark:              |                                           |                                                      |                                                             |                             :white_check_mark:                              |                                                                          |                                 |\n| Support for saving schema dump files                         |              :white_check_mark:              |                                           |                                                      |                                                             |                             :white_check_mark:                              |                                                                          |                                 |\n| Timestamp-versioned migration files                          |              :white_check_mark:              |            :white_check_mark:             |                                                      |                     :white_check_mark:                      |                             :white_check_mark:                              |                            :white_check_mark:                            |                                 |\n| Custom schema migrations table                               |              :white_check_mark:              |                                           |                  :white_check_mark:                  |                                                             |                                                                             |                            :white_check_mark:                            |       :white_check_mark:        |\n| Ability to wait for database to become ready                 |              :white_check_mark:              |                                           |                                                      |                                                             |                                                                             |                                                                          |                                 |\n| Database connection string loaded from environment variables |              :white_check_mark:              |                                           |                                                      |                                                             |                                                                             |                                                                          |       :white_check_mark:        |\n| Automatically load .env file                                 |              :white_check_mark:              |                                           |                                                      |                                                             |                                                                             |                                                                          |                                 |\n| No separate configuration file                               |              :white_check_mark:              |            :white_check_mark:             |                                                      |                     :white_check_mark:                      |                             :white_check_mark:                              |                            :white_check_mark:                            |                                 |\n| Language\u002Fframework independent                               |              :white_check_mark:              |            :white_check_mark:             |                                                      |                     :white_check_mark:                      |                                                                             |                                                                          |       :white_check_mark:        |      :white_check_mark:       |\n| **Drivers**                                                  |\n| PostgreSQL                                                   |              :white_check_mark:              |            :white_check_mark:             |                  :white_check_mark:                  |                     :white_check_mark:                      |                             :white_check_mark:                              |                            :white_check_mark:                            |       :white_check_mark:        |      :white_check_mark:       |\n| MySQL                                                        |              :white_check_mark:              |            :white_check_mark:             |                  :white_check_mark:                  |                     :white_check_mark:                      |                             :white_check_mark:                              |                            :white_check_mark:                            |       :white_check_mark:        |      :white_check_mark:       |\n| SQLite                                                       |              :white_check_mark:              |            :white_check_mark:             |                  :white_check_mark:                  |                     :white_check_mark:                      |                             :white_check_mark:                              |                            :white_check_mark:                            |       :white_check_mark:        |      :white_check_mark:       |\n| CliсkHouse                                                   |              :white_check_mark:              |                                           |                                                      |                     :white_check_mark:                      |                             :white_check_mark:                              |                            :white_check_mark:                            |                                 |\n\n_If you notice any inaccuracies in this table, please [propose a change](https:\u002F\u002Fgithub.com\u002Famacneil\u002Fdbmate\u002Fedit\u002Fmain\u002FREADME.md)._\n\n## Contributing\n\nDbmate is written in Go, pull requests are welcome.\n\nTests are run against a real database using docker compose. To build a docker image and run the tests:\n\n```sh\n$ make docker-all\n```\n\nTo start a development shell:\n\n```sh\n$ make docker-sh\n```\n","Dbmate 是一个轻量级的、与框架无关的数据库迁移工具。它支持包括 MySQL、PostgreSQL、SQLite 和 ClickHouse 在内的多种数据库，使用纯 SQL 语句编写模式迁移，并通过时间戳版本控制避免多开发者间的版本冲突。Dbmate 的核心功能还包括原子性事务处理、创建和删除数据库的能力以及将 schema 导出为文件以方便版本控制系统中的比较。此外，该工具易于分发，仅需单一自包含二进制文件即可运行。Dbmate 适合在需要跨多个开发人员或生产服务器保持数据库结构同步的应用场景中使用，尤其是当项目涉及多种编程语言和技术栈时。","2026-06-11 03:28:20","top_topic"]