Skip to content
BSWEN
Blog

Framework vs Standalone: Which Database Migration Tool Should You Choose?

Cowrie
Cowrie
Dev @ Bswen

Datacenter server racks representing database infrastructure

The Problem

I faced a decision that every development team encounters: how to track database schema changes alongside code. The options boiled down to two paths:

  1. Use the migration tool bundled with my framework (Rails ActiveRecord, Django migrations)
  2. Pick a standalone tool like Flyway or Liquibase

The question seemed simple, but the implications weren’t. Each choice creates a different kind of lock-in. Framework-bundled tools lock you to the framework. Standalone tools lock you to the migration software—and potentially to your database vendor if you use SQL-based migrations.

The Decision Crossroads
┌─────────────────────────────────────────────────────────────────────┐
│                     DATABASE MIGRATION CHOICE                        │
│                                                                     │
│   Framework-Bundled          vs          Standalone                 │
│   (Rails, Django)                        (Flyway, Liquibase)        │
│                                                                     │
│   ✓ Pre-integrated                       ✓ Cross-language support   │
│   ✓ Cognitive familiarity                ✓ Framework independence   │
│   ✗ Framework lock-in                    ✗ Tool lock-in             │
│   ✗ No flexibility                       ✗ Possible DB lock-in      │
└─────────────────────────────────────────────────────────────────────┘

The Direct Answer

Use framework-bundled migration tools if your team is already committed to a specific language/framework stack. Use standalone tools like Flyway or Liquibase if you haven’t locked into a framework or need flexibility across languages.

The critical insight from the CloudBees article: “Database migration is not an area where changing the tools yields you tremendous benefits.” Pick one tool and commit to it. The value comes from having migrations at all, not from switching tools mid-project.

Decision Framework
COMMITTED TO RAILS/DJANGO/etc?  →  Use bundled migrations
NO FRAMEWORK COMMITMENT?       →  Consider Flyway/Liquibase
CHANGING MID-PROJECT?          →  STOP! This wastes time and adds risk

Framework-Bundled Migration Tools

Framework-bundled tools come pre-integrated. They feel natural to developers already working in that ecosystem.

Rails ActiveRecord Migrations

Rails migrations use Ruby syntax that mirrors the framework’s conventions:

create_products.rb
class CreateProducts < ActiveRecord::Migration[5.0]
  def change
    create_table :products do |t|
      t.string :name
      t.text :description
      t.timestamps
    end
  end
end

The benefits:

Rails Migration Benefits
+ Integrated with Rails workflow
+ Same language as application code
+ Version tracking built into framework
+ Team already knows the syntax
+ Schema.rb provides snapshot view

Django Migrations

Django follows the same pattern—migrations live in the Python ecosystem:

0001_initial.py
from django.db import migrations, models


class Migration(migrations.Migration):
    initial = True


    dependencies = []


    operations = [
        migrations.CreateModel(
            name='Product',
            fields=[
                ('id', models.BigAutoField(primary_key=True)),
                ('name', models.CharField(max_length=100)),
                ('description', models.TextField()),
            ],
        ),
    ]

The lock-in with framework-bundled tools is voluntary. Most developers choose this path because they want to stay in their framework’s ecosystem. The lock-in is a feature, not a bug.

Standalone Migration Tools

Standalone tools provide independence from frameworks but introduce their own constraints.

Liquibase

Liquibase uses XML, YAML, or JSON to define changes:

changelog.xml
<changeSet id="1" author="bob">
    <createTable tableName="department">
        <column name="id" type="int">
            <constraints primaryKey="true" nullable="false"/>
        </column>
        <column name="name" type="varchar(50)">
            <constraints nullable="false"/>
        </column>
        <column name="active" type="boolean" defaultValueBoolean="true"/>
    </createTable>
</changeSet>

Liquibase supports multiple databases and formats:

Liquibase Capabilities
Format options: XML, YAML, JSON, SQL
Database support: Oracle, MySQL, PostgreSQL, SQL Server, and more
Rollback support: Built-in rollback for most operations

Flyway

Flyway prefers SQL-based migrations with a versioned filename convention:

V1__Create_department.sql
CREATE TABLE department (
    id INT PRIMARY KEY NOT NULL,
    name VARCHAR(50) NOT NULL,
    active BOOLEAN DEFAULT TRUE
);

Flyway’s SQL approach creates a different kind of lock-in:

Flyway Lock-In Trade-offs
+ Simple versioning (V1__, V2__, etc.)
+ Direct SQL control
+ Fast execution


- SQL-based migrations lock to specific database
- MySQL SQL differs from PostgreSQL SQL
- Switching databases means rewriting migrations

Comparison Table

Here’s how the two approaches stack up:

Migration Tool Comparison
| Aspect                | Framework-Bundled    | Standalone            |
|-----------------------|----------------------|-----------------------|
| Setup complexity      | Low (pre-integrated) | Higher (separate tool)|
| Language lock-in      | Yes                  | No                    |
| Framework lock-in     | Yes                  | No                    |
| Database lock-in      | No (abstracted)      | Possible (SQL-based)  |
| Cognitive load        | Low                  | Higher                |
| Cross-team sharing    | Harder               | Easier                |
| Best for              | Committed stacks     | Multi-language teams  |

The key observation from CloudBees: framework-bundled tools dominate because “the lock-in is entirely voluntary and desired.” Teams want the integration. They want the cognitive familiarity.

Why This Matters

The real cost isn’t in choosing between tools. It’s in switching tools mid-project:

Tool Switching Costs
Switching mid-project costs:
+ Time to learn new tool
+ Time to migrate existing migrations
+ Risk of errors during conversion
+ Lost history in version control
+ Team confusion during transition


What you gain:
+ Slightly different syntax
+ Marginal feature differences
+ Mostly the same functionality


Net result: High cost, minimal benefit

I’ve seen teams spend weeks migrating from Rails migrations to Flyway, only to end up with the same functionality wrapped in a different syntax. The switch didn’t improve their workflow. It just consumed time.

Common Mistakes

I’ve made these mistakes myself:

Mistake 1: Switching tools unnecessarily

Wrong vs Right
WRONG:
"We're using Rails migrations but heard Flyway is better.
Let's switch everything over."


Result: 3 weeks of migration work, no functional improvement


RIGHT:
"We're using Rails migrations. They work.
Let's focus on features instead of tooling."

Mistake 2: Assuming standalone eliminates lock-in

Wrong vs Right
WRONG:
"We'll use Flyway so we're not locked into Rails."


Reality: Now locked into Flyway and possibly MySQL


RIGHT:
"Flyway gives us framework flexibility.
But we accept tool lock-in as the trade-off."

Mistake 3: Choosing based on features instead of context

Wrong vs Right
WRONG:
"Liquibase has rollback features, so it's better."


Context ignored: We're a Django team, Django migrations handle rollback


RIGHT:
"We're a Django team. Django migrations work.
Features don't matter if they're not in our workflow."

The Decision Process

Here’s how I approach this decision:

Decision Checklist
1. What framework does our team use?
   → Rails/Django/etc? Use bundled migrations


2. Are we committed to this framework long-term?
   → Yes? Bundled migrations are the right choice
   → No? Consider standalone


3. Do we need cross-language flexibility?
   → Multiple languages/frameworks in play?
   → Standalone might fit better


4. Have we already started with migrations?
   → Yes? Stick with current tool
   → Switching is almost never worth it


5. What database do we use?
   → Might change databases?
   → Abstracted migrations (Liquibase XML) help
   → SQL-based (Flyway) creates DB lock-in

Summary

In this post, I explained the decision framework for choosing database migration tools. The choice between framework-bundled and standalone tools comes down to your team’s commitment level:

  • Framework-bundled tools (Rails ActiveRecord, Django migrations) work best when your team is committed to a specific framework. The lock-in is voluntary and desired.
  • Standalone tools (Flyway, Liquibase) provide cross-language flexibility but create their own lock-in to the tool and potentially your database.

The key insight: changing migration tools mid-project yields minimal benefits while consuming significant time. Pick one approach and commit to it. The value comes from having migrations at all—not from which tool you choose.

Final Words + More Resources

My intention with this article was to help others share my knowledge and experience. If you want to contact me, you can contact by email: Email me

Here are also the most important links from this article along with some further resources that will help you in this scope:

Oh, and if you found these resources useful, don’t forget to support me by starring the repo on GitHub!

Comments

Tags: