Zhivko Todorov
ALL CASE STUDIES

CASE 167 · PEBBLE · 2024

DATABASE MIGRATIONSFLYWAYATLASPOSTGRES

Database migrations the team trusts, even at 2am.

A B2B SaaS company ran database migrations through a homegrown shell-script orchestration that occasionally failed in surprising ways. Production migrations had become a five-engineer ceremony. We migrated to Atlas + Flyway with a proper schema-change workflow.

INDUSTRY

B2B SaaS

DOMAIN

PLATFORM

DELIVERED

2024

STACK

ATLAS·FLYWAY·POSTGRES·GITHUB ACTIONS·TERRAFORM (RDS)·AURORA BLUE/GREEN

RESULTS

What changed, by the numbers.

MIGRATION CEREMONY

5 → 1

ENGINEERS PRESENT

MIGRATION FAILURES

−92%

CAUGHT IN CI

SCHEMA-DIFF REVIEW

PR-VISIBLE

AUTO-RENDERED

ROLLBACK PATHS

DOCUMENTED

EVERY CHANGE

HOW IT WENT

The five-engineer ceremony existed because nobody quite trusted the migration to land cleanly. Two engineers ran the migration; one watched the application; one watched the database; one was on standby to roll back. Most of the time it was fine. Occasionally it wasn’t, and the team’s memory of the bad times kept the ceremony alive.

Atlas (declarative schema) plus Flyway (versioned migration files) brought rigour. Atlas computed the diff between the declared schema and the current state; Flyway versioned the migration files. GitHub Actions ran the migration in a CI clone first and rendered the diff in the PR. Aurora Blue/Green let the production migration land on a clone before promoting.

Migration ceremony dropped from five engineers to one. Migration failures fell 92% — most are caught in CI now. The schema diff is visible in PRs so reviewers can see the change without spelunking through migration files. Rollback paths are documented as part of every migration.

READY WHEN YOU ARE

Let's get your AWS bill (and architecture) in order.

The discovery call is free. You walk away with at least one concrete idea — even if we never work together.

Or email directly →