Migrations, Schema Design, Seeds, Indexes, and the Rails Database Workflow
Learn how Rails evolves databases safely through migrations and how schema design affects correctness and performance.
Inside this chapter
- What Migrations Are For
- Migration Example
- Schema Design Still Matters
- Seeds and Environment Setup
Series navigation
Study the chapters in order for the clearest path from Rails beginner concepts to advanced production architecture. Use the previous and next links at the bottom of each page to move through the full tutorial series.
What Migrations Are For
Migrations are version-controlled Ruby files that describe database schema changes over time. They let teams add tables, rename columns, create indexes, and evolve the database in a repeatable way across environments. Good Rails teams treat migrations as part of the application codebase, not as random one-off scripts.
Migration Example
class CreateBooks < ActiveRecord::Migration[7.1]
def change
create_table :books do |t|
t.string :title, null: false
t.decimal :price, precision: 10, scale: 2
t.references :author, foreign_key: true
t.timestamps
end
add_index :books, :title
end
endSchema Design Still Matters
Rails makes database work easier, but it does not replace good data modeling. Students should understand column types, nullability, defaults, uniqueness constraints, foreign keys, indexes, and normalization trade-offs. A poorly designed schema stays painful no matter how elegant the Rails code looks.
Seeds and Environment Setup
Author.create!(name: "Mira Sen")
Book.create!(title: "Rails in Practice", price: 599, author: Author.first)Seed data is useful for onboarding, demos, and local development. Advanced teams keep seeds intentional and separate large production-like data generation from basic developer setup data.