dbmate vs Goose

dbmate is a free, open-source command-line tool for keeping database schemas in sync across developers and production servers. It works independently of application language and can be used with Go, Node.js, Python, Ruby, PHP, Rust, C++, and other languages or frameworks. Migrations are plain SQL in timestamp-versioned files. Commands create, apply, and roll back migrations, check status, dump or load a schema, and wait for a database server. The project lists MySQL, MariaDB, PostgreSQL, SQLite, and ClickHouse, and documents BigQuery connections and Spanner support for databases using the PostgreSQL dialect. Migrations run atomically in a transaction by default when the database supports transactions, though individual migration blocks can opt out. dbmate can maintain a schema.sql dump for source-control review and Git diffs; creating dumps relies on database client tools such as pg_dump, mysqldump, or sqlite3. It reads DATABASE_URL by default and can load environment variables from a .env file. Installation options include NPM, Homebrew, Scoop, a Linux binary, and Docker images. Go applications can use it as a library, and Go embed can package migrations into an application binary.

Goose is a free, open-source database migration tool for managing schema changes through incremental SQL files and Go functions. It is available as both a command-line utility and a library. The CLI can apply, roll back, redo, reset, inspect, and version migrations, with documented drivers for ClickHouse, Microsoft SQL Server, MySQL, PostgreSQL, SQLite, Turso, Vertica, and YDB. SQL migration files use an up annotation and may include a down annotation; filenames can use timestamps or sequential numbers. Statements in a migration file run in one transaction by default, with an annotation for running them outside one. Go migration functions can use a transaction when given a transaction argument. Other listed capabilities include embedded and out-of-order migrations, data seeding, and environment variable substitution in SQL migrations. For library use, a provider accepts a database dialect, connection, migration filesystem, and optional configuration. The provider does not lock the database by default, so callers must arrange safe concurrent migrations or configure a session locker.