Database migrations are one of those things that work fine until they don't. A missed rollback script, a schema change applied to production but not staging, credentials hardcoded in a config file someone committed by accident… These are the kind of incidents that keep backend engineers up at night (or well past 2am).
SQL Migration Tool
Who Is It For?
SMT is a practical tool for:
- Backend developers and DBAs who work with MySQL, PostgreSQL, or Microsoft SQL Server and want a structured way to track and apply schema changes across environments
- Teams running microservices or multi-tenant architectures, where multiple projects may share a database and migration tracking needs to stay isolated per service
- Engineering teams with CI/CD pipelines, where database changes need to be applied automatically and reliably without human interaction during deployments
- Projects inheriting legacy codebases with no existing migration system, where introducing a heavyweight ORM-based solution isn't practical or desirable
Why Plain SQL Matters
Most migration tools ask you to describe schema changes in a DSL, an ORM's migration syntax, or some abstraction layer. SMT takes the opposite approach: your migrations are plain .sql files. That means:
- You write exactly what gets executed; thus, no surprises from generated SQL
- Your .sql files can be run directly in any database client, independently of the tool itself
- There's no lock-in to a specific language runtime, framework, or ORM
- Every migration lives in your version control system like any other source file
This is a deliberate trade-off in favor of transparency and portability.
Key Capabilities
- Multi-environment support. Manage dev, staging, and production from a single project configuration. Migrations are tracked per environment so you always know what's been applied where.
- Dynamic replacements. Inject environment-specific values directly into your SQL files at execution time. Useful for targeting different schemas, table prefixes, or inserting seed data that varies by environment.
- Flexible credential management. Credentials never have to live in source code. SMT supports .env files and AWS Secrets Manager, or you can pass them at runtime via CLI arguments.
- Script support. Beyond versioned migrations, you can run ad-hoc SQL scripts (data backfills, maintenance operations, one-off fixes) with the same dynamic replacement system applied.
- Multi-project tracking. Multiple migration projects can run against the same database, each identified by a unique key. Essential for microservice setups where several services share a database server but own distinct schemas.
- Rollbacks via plain SQL. Rollback scripts are just .sql files too. What gets executed on rollback is exactly what you wrote, nothing inferred
CI/CD Integration
SMT ships as both a desktop application and an npm CLI package. For automated workflows, the CLI is the primary interface:
1npm install -g @2amtech/sql-migration-tool
22am-smt initFrom there, migrations can be run as part of any Node.js-compatible CI/CD pipeline: GitHub Actions, GitLab CI, Jenkins, or whatever your team already uses. No interactive prompts, no GUI dependency in automation context.
Supported Databases
- MySQL / MariaDB
- PostgreSQL
- Microsoft SQL Server
Desktop App and CLI, MIT Licensed
Both the desktop application (available for macOS and Linux) and the CLI tool are released under the MIT license. They are free to use, modify, and integrate into commercial projects without restrictions. The Windows version is coming soon.
The desktop app gives developers a visual interface for managing migration projects, reviewing history, and running scripts manually. The CLI handles everything in automation contexts. They're complementary, and you can use either or both depending on the context.
