qop
is a command-line tool for managing database migrations for PostgreSQL and SQLite. It's designed to be simple, straightforward, and easy to use. The software respects semantic versioning and will only introduce breaking changes in new major
versions once passing the 1.0.0
version. While being in-development, breaking changes CAN occur in new minor
versions.
- Backend-agnostic design (supports PostgreSQL and SQLite)
- Simple migration file format (
up.sql
,down.sql
,meta.toml
) - Migration metadata support (comments, locking status)
- Migration locking system to prevent accidental reverts
- Timestamp-based migration IDs
- Command-line interface for managing migrations
- Comprehensive audit logging of all migration operations
- No interactive UI; all confirmations happen via CLI prompts or can be bypassed with
--yes
cargo install --path .
Please find more information about migration from one version to another in the dedicated release notes.
qop
is built with Cargo feature flags to include only the subsystems you need. SQLite support is enabled by default.
-
Default features
- Enabled:
sub+sqlite
- Disabled:
sub+postgres
(optional)
- Enabled:
-
Enable PostgreSQL (keeping default SQLite):
cargo build --features "sub+postgres"
- PostgreSQL only (no SQLite):
cargo build --no-default-features --features "sub+postgres"
- SQLite only (default):
cargo build # or: cargo build --features "sub+sqlite"
- No subsystems (not allowed):
cargo build --no-default-features # Fails at compile time with a clear error
Notes:
- Enabling a subsystem feature also enables only the matching
sqlx
backend internally, keeping binaries small. - Runtime uses Tokio and Rustls TLS by default. No
sqlx
macros are required.
-
Create a migrations directory and config file:
- Create a directory to hold your migrations (for example,
migrations/
). Place yourqop.toml
inside this directory. The tool expects migration folders (likeid=.../
) to live alongsideqop.toml
. - Generate a sample config for your database:
- PostgreSQL:
qop subsystem postgres config init -p migrations/qop.toml -c "postgresql://postgres:password@localhost:5432/postgres"
- SQLite:
qop subsystem sqlite config init -p migrations/qop.toml -d ./app.db
- PostgreSQL:
- Create a directory to hold your migrations (for example,
-
Initialize the migration table:
qop subsystem postgres init -p migrations/qop.toml qop subsystem sqlite init -p migrations/qop.toml
-
Create your first migration:
qop subsystem postgres new -p migrations/qop.toml # For PostgreSQL qop subsystem sqlite new -p migrations/qop.toml # For SQLite
This will create a new directory with
up.sql
anddown.sql
files. -
Apply the migration:
qop subsystem postgres up -p migrations/qop.toml # For PostgreSQL qop subsystem sqlite up -p migrations/qop.toml # For SQLite
qop
is configured using a qop.toml
file. Here are examples for both supported backends:
version = ">=0.1.0"
[subsystem.postgres]
connection = { static = "postgresql://postgres:password@localhost:5432/postgres" }
schema = "public"
table_prefix = "__qop"
timeout = 30
You can also use environment variables for the connection string:
version = ">=0.1.0"
[subsystem.postgres]
connection = { from_env = "DATABASE_URL" }
schema = "public"
table_prefix = "__qop"
timeout = 30
version = ">=0.1.0"
[subsystem.sqlite]
connection = { static = "sqlite:///path/to/database.db" }
table_prefix = "__qop"
timeout = 30
Or with environment variables:
version = ">=0.1.0"
[subsystem.sqlite]
connection = { from_env = "DATABASE_URL" }
table_prefix = "__qop"
timeout = 30
The migration files live in the same directory as the qop.toml
file (e.g., migrations/
). Each migration is a folder named id=<timestamp>/
containing up.sql
, down.sql
, and meta.toml
.
qop
provides several commands to manage your database migrations through subsystems.
The core command for managing database-specific operations. Available aliases: sub
, s
qop subsystem <DATABASE> <COMMAND>
All PostgreSQL operations are accessed through the postgres
(alias: pg
) subsystem:
Initializes the migration table in your PostgreSQL database.
qop subsystem postgres init --path path/to/your/qop.toml
Creates a new migration directory with up.sql
, down.sql
, and meta.toml
files.
qop subsystem postgres new --path path/to/your/qop.toml
Arguments:
-p, --path <PATH>
: Path to theqop.toml
configuration file. (default:qop.toml
)-c, --comment <COMMENT>
: Custom comment for the migration--lock
: Mark migration as locked (cannot be reverted without --unlock)
This will create a directory structure like:
migrations/
└── id=1678886400000/
├── up.sql
├── down.sql
└── meta.toml
Applies pending migrations. By default, it applies all pending migrations.
qop subsystem postgres up --path path/to/your/qop.toml
Arguments:
-p, --path <PATH>
: Path to theqop.toml
configuration file. (default:qop.toml
)-c, --count <COUNT>
: The number of migrations to apply. If not specified, all pending migrations are applied.-t, --timeout <TIMEOUT>
: Statement timeout in seconds.--dry
: Execute migration in a transaction but rollback instead of committing-y, --yes
: Skip confirmation prompts and apply migrations automatically
Reverts applied migrations. By default, it reverts the last applied migration.
qop subsystem postgres down --path path/to/your/qop.toml
Arguments:
-p, --path <PATH>
: Path to theqop.toml
configuration file. (default:qop.toml
)-c, --count <COUNT>
: The number of migrations to revert. (default: 1)-t, --timeout <TIMEOUT>
: Statement timeout in seconds.-r, --remote
: Use thedown.sql
from the database instead of the local file.--dry
: Execute migration in a transaction but rollback instead of committing--unlock
: Allow reverting locked migrations-y, --yes
: Skip confirmation prompts and revert migrations automatically
Lists all migrations, showing their status (applied or not) and when they were applied.
qop subsystem postgres list --path path/to/your/qop.toml
Arguments:
-o, --output <FORMAT>
: Output format (human
orjson
). (default:human
)
Manages migration history with commands for syncing and fixing migration order.
Upserts all remote migrations locally. This is useful for syncing migrations across multiple developers.
qop subsystem postgres history sync --path path/to/your/qop.toml
Shuffles all non-run local migrations to the end of the chain. This is useful when you have created migrations out of order.
qop subsystem postgres history fix --path path/to/your/qop.toml
Shows the raw SQL content of pending migrations without applying them.
qop subsystem postgres diff --path path/to/your/qop.toml
This command outputs the exact SQL content for each pending migration using the same formatted preview as the interactive diff (with headers and separators).
Applies or reverts a specific migration by ID.
Applies a specific migration.
qop subsystem postgres apply up <ID> --path path/to/your/qop.toml
Arguments:
<ID>
: Migration ID to apply (required)-t, --timeout <TIMEOUT>
: Statement timeout in seconds.--dry
: Execute migration in a transaction but rollback instead of committing--lock
: Mark applied migration as locked (cannot be reverted without --unlock)-y, --yes
: Skip confirmation prompts and apply migration automatically
Reverts a specific migration.
qop subsystem postgres apply down <ID> --path path/to/your/qop.toml
Arguments:
<ID>
: Migration ID to revert (required)-t, --timeout <TIMEOUT>
: Statement timeout in seconds.-r, --remote
: Use thedown.sql
from the database instead of the local file.--dry
: Execute migration in a transaction but rollback instead of committing--unlock
: Allow reverting locked migrations-y, --yes
: Skip confirmation prompts and revert migration automatically
All SQLite operations are accessed through the sqlite
(alias: sql
) subsystem and support the same commands as PostgreSQL:
Initializes the migration table in your SQLite database.
qop subsystem sqlite init --path path/to/your/qop.toml
Creates a new migration directory with up.sql
, down.sql
, and meta.toml
files.
qop subsystem sqlite new --path path/to/your/qop.toml
Arguments:
-p, --path <PATH>
: Path to theqop.toml
configuration file. (default:qop.toml
)-c, --comment <COMMENT>
: Custom comment for the migration--lock
: Mark migration as locked (cannot be reverted without --unlock)
Applies pending migrations.
qop subsystem sqlite up --path path/to/your/qop.toml
Arguments:
-p, --path <PATH>
: Path to theqop.toml
configuration file. (default:qop.toml
)-c, --count <COUNT>
: The number of migrations to apply.-t, --timeout <TIMEOUT>
: Statement timeout in seconds.--dry
: Execute migration in a transaction but rollback instead of committing-y, --yes
: Skip confirmation prompts and apply migrations automatically
Reverts applied migrations.
qop subsystem sqlite down --path path/to/your/qop.toml
Arguments:
-p, --path <PATH>
: Path to theqop.toml
configuration file. (default:qop.toml
)-c, --count <COUNT>
: The number of migrations to revert.-t, --timeout <TIMEOUT>
: Statement timeout in seconds.-r, --remote
: Use thedown.sql
from the database instead of the local file.--dry
: Execute migration in a transaction but rollback instead of committing--unlock
: Allow reverting locked migrations-y, --yes
: Skip confirmation prompts and revert migrations automatically
Lists all migrations, showing their status and when they were applied.
qop subsystem sqlite list --path path/to/your/qop.toml
Arguments:
-o, --output <FORMAT>
: Output format (human
orjson
). (default:human
)
Upserts all remote migrations locally.
qop subsystem sqlite history sync --path path/to/your/qop.toml
Shuffles all non-run local migrations to the end of the chain.
qop subsystem sqlite history fix --path path/to/your/qop.toml
Shows the raw SQL content of pending migrations without applying them.
qop subsystem sqlite diff --path path/to/your/qop.toml
This command outputs the exact SQL content for each pending migration using the same formatted preview as the interactive diff (with headers and separators).
Applies a specific migration by ID.
qop subsystem sqlite apply up <ID> --path path/to/your/qop.toml
Arguments:
<ID>
: Migration ID to apply (required)-t, --timeout <TIMEOUT>
: Statement timeout in seconds.--dry
: Execute migration in a transaction but rollback instead of committing--lock
: Mark applied migration as locked (cannot be reverted without --unlock)-y, --yes
: Skip confirmation prompts and apply migration automatically
Reverts a specific migration by ID.
qop subsystem sqlite apply down <ID> --path path/to/your/qop.toml
Arguments:
<ID>
: Migration ID to revert (required)-t, --timeout <TIMEOUT>
: Statement timeout in seconds.-r, --remote
: Use thedown.sql
from the database instead of the local file.--dry
: Execute migration in a transaction but rollback instead of committing--unlock
: Allow reverting locked migrations-y, --yes
: Skip confirmation prompts and revert migration automatically
Renders the manual.
qop man --out docs/manual --format markdown
Arguments:
-o, --out <PATH>
: Path to write documentation to (required)-f, --format <FORMAT>
: Format for the documentation. Can bemanpages
ormarkdown
(required)
Renders shell completion scripts.
qop autocomplete --out completions --shell zsh
Arguments:
-o, --out <PATH>
: Path to write completion script to (required)-s, --shell <SHELL>
: The shell to generate completions for (bash
,zsh
,fish
,elvish
,powershell
) (required)
During confirmation prompts, type d
or diff
to preview the exact SQL for the operation:
# Apply pending migrations (press 'd' at the prompt to preview SQL)
qop subsystem postgres up -p migrations/qop.toml
# Revert last migration (press 'd' at the prompt to preview SQL)
qop subsystem postgres down -p migrations/qop.toml
The preview shows the raw SQL content exactly as it will be executed, with no additional formatting.
You can also print pending SQL without prompts using the diff command:
qop subsystem postgres diff -p migrations/qop.toml
qop subsystem sqlite diff -p migrations/qop.toml
Example Output:
CREATE TABLE users (
id SERIAL PRIMARY KEY,
email VARCHAR(255) UNIQUE NOT NULL,
created_at TIMESTAMP DEFAULT CURRENT_TIMESTAMP
);
CREATE INDEX idx_users_email ON users(email);
The output contains only the SQL statements from your migration files, making it easy to redirect to files or pipe to other tools.
Skip confirmations with --yes
:
# Apply all pending migrations without prompts
qop subsystem postgres up --yes
# Revert last migration without prompts
qop subsystem postgres down --yes
The --dry
flag is now available for all migration commands and executes migrations in a transaction that is rolled back instead of committed, allowing you to test migrations safely.
Development Workflow:
# 1. Check what migrations are pending
qop subsystem postgres diff
# 2. Apply with confirmation
qop subsystem postgres up
CI/CD Pipeline:
# Apply all pending migrations automatically
qop subsystem postgres up --yes
Debugging:
# Save pending SQL to a file for review
qop subsystem postgres diff > pending_migrations.sql
# Apply a specific migration
qop subsystem postgres apply up 123456789
Database Rollback:
# Preview what will be rolled back (press 'd' at the prompt)
qop subsystem postgres down
# Rollback for real
qop subsystem postgres down --yes