When running migrations on production databases with active traffic, it's important to include safety settings like SET lock_timeout = '5s'; to prevent migrations from blocking writes indefinitely while waiting for locks.
Currently, teams must remember to manually add this to every migration - which is error-prone. A simple template feature would allow enforcing safe defaults automatically.
Proposed solution:
If a template file exists in the project (e.g., db/.dbmate/template.sql or configured via --template-file), dbmate new would use it instead of the default empty template:
-- migrate:up
SET lock_timeout = '5s';
-- migrate:down
Why this differs from PR #530:
The closed PR stored templates in ~/.config, which goes against dbmate's KISS philosophy. This proposal keeps templates in the project repo, making them:
- Version controlled with the project
- Shared across the team automatically
- Consistent with dbmate's simple, portable approach
This is a small change that would help teams enforce safe migration practices without external tooling.
When running migrations on production databases with active traffic, it's important to include safety settings like
SET lock_timeout = '5s';to prevent migrations from blocking writes indefinitely while waiting for locks.Currently, teams must remember to manually add this to every migration - which is error-prone. A simple template feature would allow enforcing safe defaults automatically.
Proposed solution:
If a template file exists in the project (e.g.,
db/.dbmate/template.sqlor configured via--template-file),dbmate newwould use it instead of the default empty template:Why this differs from PR #530:
The closed PR stored templates in
~/.config, which goes against dbmate's KISS philosophy. This proposal keeps templates in the project repo, making them:This is a small change that would help teams enforce safe migration practices without external tooling.