Skip to content
Cased Documentation

Database migrations

Run database migrations safely with your code deploys
Migrations

Why separate migrations?

Deploying database changes separately from application code:

  • Makes rollbacks easier if problems occur
  • Reduces deployment risk
  • Lets you verify schema changes before deploying dependent code

How it works

When your pull request includes database migrations, Cased:

  1. Finds the migration files
  2. Notifies your team in Slack
  3. Lets you manage the changes through Slack or our web UI

Finding migrations

Cased detects database changes in pull requests, whether they’re schema changes or data migrations. Your framework or migration style doesn’t matter. When found, you’ll get a Slack notification:

[image]

You can also manage migrations on the branch page:

[image]

Creating a separate PR

Click “Split Changes” in the Slack message to create a new PR with only the migration files.

Best practices

  • Review Before Splitting: Check the detected migrations before creating a separate PR
  • Communication: Use Slack threads to discuss changes with your team
  • Documentation: Add context when splitting migrations into their own PR
  • Testing: Both PRs need proper test coverage

Compatible frameworks

Works with:

  • Ruby on Rails / Active Record
  • Python / Alembic
  • TypeORM
  • Prisma
  • Django
  • SQLAlchemy
  • Entity Framework
  • Flyway
  • Sequelize
  • Knex.js
  • Raw SQL and SQL files
  • Database-specific formats (_.pgsql, _.mysql)
  • Stored procedures