I'm currently trying to come up with a database migrations strategy for my organization. This includes getting the database scripts into source control, managing versioning, managing releases to QA / Production, managing branching and merging across different release branches, etc.

Ruby Migrations seems to offer solutions to a lot of those problems. But, from looking at the Ruby on Rails docs, it is unclear to me whether Ruby Migrations can be separated from the rest of the framework. I work in a primarily .NET shop, but with a lot of other technologies, and with multiple DBMS platforms (SQL Server, Oracle of various versions). Ruby is not present in our portfolio at all right now, and we have no plans to use it. If I was to use Ruby Migrations, it would be the only piece of the Ruby on Rails framework that we would want to use.

Can Ruby Migrations be effectively used to manage database changes independently of the rest of the Ruby on Rails framework? Are there any docs or articles out there that describe this workflow?

(Yes, I know there are other options such as Liquibase but I'm specifically trying to learn about Ruby Migrations with this question.)

  • You might want to look at something like Liquibase if you just want to manage DB migrations.
    – Pavling
    Jun 21, 2012 at 17:43

4 Answers 4


Ruby on Rails migrations are triggered through rake tasks, like rake db:migrate, rake db:reset and so on. You see a complete list with rake -T. You are not forced to ever start the Rails server. So the answer to your question is clearly yes.

  • Thanks Christoph. So I can use migrations with "regular" SQL scripts without using Active Record, for example? Jun 21, 2012 at 15:49
  • Regular SQL is possible, of course. But you should come far with ActiveRecord convenience. I recommend to create your migrations with rails generate scaffold Person name:string date_or_birth:date (for example) and you get a CRUD application for free. Jun 22, 2012 at 10:13

Ruby on Rails is designed to be used as a big whole, so separating out a chunk of it tends to be more work than it is worth.

An alternative library is Datamapper, which has a standalone migrations module.


I like Sequel a lot.

Sequel supports also migrations

I like Sequel, because it used like SQL, you don't need to use it as ORM, you can use it very easy as an interface to a DB. Sometimes I use Sequel only to generate SQL-commands.

Especially with legacy-DB I prefer Sequel.


You can use the migrations framework in a non-Rails project if you want. I use it in a Rails project that uses Sequel instead of ActiveRecord as the ORM solution but we still use ActiveRecord migrations to evolve our database schema. I know at least two projects that allow you to do that:

https://github.com/rosenfeld/active_record_migrations (compatible with ActiveRecord 4 and above) https://github.com/thuss/standalone-migrations (compatible with ActiveRecord 3.2)

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge you have read our privacy policy.

Not the answer you're looking for? Browse other questions tagged or ask your own question.