Ruby on Rails 4 Data Types Explained for Migrations and Models

By the end of this page, you will understand the common data types available in Ruby on Rails 4 migrations, what each type is used for, how Rails maps them to database columns, and how to choose the right type for real applications.

Rails data types are the column types you use when defining database tables in migrations. They describe what kind of data a column should store, such as short text, long text, whole numbers, dates, or true/false values.

In Rails 4, you usually see these types inside migration files:

create_table :products do |t|
  t.string :name
  t.text :description
  t.integer :stock
  t.decimal :price
  t.boolean :active
  t.date :released_on

  t.timestamps
end

Rails uses these migration types as an abstraction layer. That means you write string, integer, or date in Rails, and Rails translates them into the correct database-specific column type for SQLite, PostgreSQL, or MySQL.

This matters because:

• it keeps your code database-friendly
• it helps Active Record understand how to cast values
• it affects validations, querying, sorting, storage size, and precision
• choosing the wrong type can cause bugs or inaccurate data

Common Rails 4 migration data types

Here are the main built-in types you will commonly use:

• :string — short text, usually up to 255 characters
• :text — longer text
• :integer — whole numbers
• :float — floating-point numbers
• :decimal — precise decimal numbers, especially for money
• :datetime — date and time
• :timestamp — date and time, similar in many Rails uses
• :time — time only
• :date — date only
• :binary — raw binary data
• :boolean — true/false
• :references — foreign key-style reference to another model
• :belongs_to — alias commonly used like references

Special Rails helpers often seen in migrations

These are not exactly normal scalar data types, but they are commonly used and worth knowing:

• t.timestamps — adds created_at and updated_at
• t.primary_key — primary key column

Important note

The exact underlying SQL type can vary by database adapter. For example, string may become varchar(255) in one database and a similar equivalent in another. Rails keeps the migration syntax consistent, but the final database schema depends on the database engine.

Think of a database table like a spreadsheet with smart columns.

Each column has a label and a rule for what kind of value can go inside:

• string is like a small note field
• text is like a big paragraph box
• integer is like a counter
• decimal is like a calculator that must keep exact digits
• boolean is like a yes/no checkbox
• date is like a calendar day
• datetime is like a calendar day plus a clock time

Rails migrations are the instructions that build those columns.

So when you write:

t.string :title
t.integer :views

You are telling Rails:

• create a small text column called title
• create a whole-number column called views

A helpful way to think about it is: the data type is the shape of the box, and the value must fit the box correctly.

In Rails 4, data types are most often used in migrations.

Basic syntax

class CreateArticles < ActiveRecord::Migration
  def change
    create_table :articles do |t|
      t.string :title
      t.text :body
      t.integer :views
      t.boolean :published
      t.date :published_on

      t.timestamps
    end
  end
end

What each line means

• t.string :title stores short text
• t.text :body stores longer text
• t.integer :views stores whole numbers
• t.boolean :published stores true or false
• t.date :published_on stores a date without time
• t.timestamps adds created_at and updated_at

Common type list with examples

t.string     :name
t.text       :bio
t.integer    :age
t.float      :rating
t.decimal    :price, precision: 8, scale: 2
t.boolean    :admin
t.date       :birthday
t.time       :opens_at
t.datetime   :published_at
t.timestamp  :processed_at
t.binary     :file_data
t.references :user

Example: choosing good types

class CreateProducts < ActiveRecord::Migration
  def change
    create_table :products do |t|
      t.string  :name
      t.text    :description
      t.decimal :price, precision: 10, scale: 2
      t.integer :stock
      t.boolean :available, default: true
      t.date    :released_on

      t.timestamps
    end
  end
end

Why these choices?

• name is short, so string fits
• description may be long, so text is better
• price should use decimal, not float, to avoid rounding issues
• stock is a whole number, so integer fits
• available is yes/no, so boolean fits
• released_on needs only a date, not a full timestamp

Consider this migration:

class CreateEvents < ActiveRecord::Migration
  def change
    create_table :events do |t|
      t.string :name
      t.date :event_date
      t.boolean :public
      t.timestamps
    end
  end
end

Step by step

1. Rails reads the migration class

Rails sees a migration named CreateEvents and runs the change method.

2. create_table :events starts a new table

Rails prepares a database table called events.

3. t.string :name

Rails adds a column named name for short text.

Example values:

• "Ruby Meetup"
• "Launch Party"

4. t.date :event_date

Rails adds a date-only column.

Example values:

• 2026-01-15
• 2026-03-01

5. t.boolean :public

Rails adds a true/false column.

Example values:

• true
• false

6. t.timestamps

Rails adds:

• created_at
• updated_at

Both are datetime-style columns managed by Rails.

What the table conceptually looks like

After migration, using the model might look like this

event = Event.create(
  name: "Ruby Meetup",
  event_date: Date.new(2026, 1, 15),
  public: true
)

Rails will cast values based on the column types, so the schema influences how your application reads and writes data.

Rails data types appear everywhere in real applications.

User accounts

t.string  :email
t.string  :encrypted_password
t.boolean :admin, default: false
t.date    :birthday

Used for:

• login systems
• profile fields
• account permissions

Blog posts

t.string   :title
t.text     :body
t.datetime :published_at
t.references :author

Used for:

• content management systems
• publishing workflows
• author relationships

E-commerce products

t.string  :name
t.text    :description
t.decimal :price, precision: 10, scale: 2
t.integer :stock

Used for:

• product catalogs
• inventory systems
• checkout logic

Scheduling systems

t.date     :appointment_date
t.time     :start_time
t.datetime :confirmed_at

Used for:

• booking apps
• calendar tools
• reminders and notifications

File storage metadata

t.string :filename
t.string :content_type
t.integer :file_size
t.binary :data

Used for:

• uploads
• document storage
• import/export systems

In real Rails projects, developers do more than just declare types. They choose them carefully to support validation, querying, and maintainability.

Common patterns

Use decimal for money

t.decimal :price, precision: 10, scale: 2

This avoids floating-point precision problems.

Use references for associations

t.references :user

This is common when a model belongs to another model.

Add defaults for booleans

t.boolean :active, default: true

Without defaults, boolean columns can end up nil, which may complicate logic.

Use timestamps for auditing

t.timestamps

Almost every Rails table includes these so developers can track when records were created and updated.

Pair types with validations

class Product < ActiveRecord::Base
  validates :name, presence: true
  validates :stock, numericality: { only_integer: true }
  validates :price, numericality: true
end

The database type stores the data, while validations help protect data quality before it reaches the database.

Reading schema as documentation

In real projects, developers often check:

• migration files
• schema.rb
• model validations
• associations

Together, these show what kind of data the app expects and how tables relate to each other.

Beginners often know the type names but are unsure when to use each one.

1. Using float for money

Broken approach:

t.float :price

Why it is a problem:

• floating-point numbers can introduce rounding errors
• money usually needs exact precision

Better:

t.decimal :price, precision: 10, scale: 2

2. Using string for long content

Broken approach:

t.string :article_body

Why it is a problem:

• string is meant for shorter values
• long text belongs in text

Better:

t.text :article_body

3. Storing numbers as strings

Broken approach:

t.string :age

Why it is a problem:

• sorting and numeric calculations become awkward
• `

Choosing the right Rails type is easier when you compare similar options.

references vs integer

These may look similar because foreign keys are often stored as integers.

t.integer :user_id

vs

t.references :user

references is usually better in Rails because it expresses intent more clearly: this column points to another model.

date vs datetime

Use date for things like birthdays.

t.date :birthday

Use datetime for events with exact timing.

t.datetime :starts_at

Common Rails 4 migration types

t.string     :name
t.text       :description
t.integer    :count
t.float      :rating
t.decimal    :price, precision: 10, scale: 2
t.boolean    :active
t.date       :birthday
t.time       :opens_at
t.datetime   :published_at
t.timestamp  :processed_at
t.binary     :file_data
t.references :user

Quick rules

• Use string for short text
• Use text for long text
• Use integer for whole numbers
• Use decimal for money or exact decimal values
• Use float only when approximation is acceptable
• Use boolean for true/false
• Use date for date only
• Use time for time only
• Use datetime for date and time
• Use references for associations
• Use timestamps for created_at and updated_at

Useful example

create_table :orders do |t|
  t.references :user
  t.decimal :total, precision: 10, scale: 2
  t.boolean :paid, default: false
  t.datetime :paid_at
  t.timestamps
end

Common pitfalls

• Do not use float for money
• Do not use string for very long text
• Do not store dates as strings
• Do not forget precision and scale for decimal
• Do not assume every database stores types exactly the same way

Where to check in a Rails app

• migration files in db/migrate
• generated schema.rb
• Rails migration documentation for your version

What data types are available in Rails 4 migrations?

Common Rails 4 migration types include string, text, integer, float, decimal, boolean, date, time, datetime, timestamp, binary, and references.

What is the difference between string and text in Rails?

string is for shorter text, such as names or email addresses. text is for longer content, such as article bodies or descriptions.

Should I use float or decimal in Rails?

Use decimal when precision matters, especially for money. Use float only when small rounding differences are acceptable.

What does t.timestamps do in a Rails migration?

It adds two columns: created_at and updated_at.

Is references a data type in Rails?

It is a migration helper used to create a reference column such as user_id, usually for associations between models.

Where can I see the actual types used in my Rails app?

Check your migration files and db/schema.rb. Those show the columns and types currently defined.

Are Rails data types the same in every database?

Not exactly. Rails provides a common migration syntax, but the underlying SQL type can vary between databases like PostgreSQL, MySQL, and SQLite.

• Active Record migrations — data types are primarily used when creating or changing tables.
• Active Record associations — references and foreign keys connect related models.
• Validations — types define storage, while validations help ensure good input.
• Schema.rb — shows the current structure of your Rails database.
• Database normalization — choosing proper column types supports cleaner table design.
• Model attributes — Rails maps database column types to Ruby objects.
• Default values — often used with booleans, counters, and status fields.