Cloud Parts

Active Record (Ruby on Rails)

The model layer of Ruby on Rails and the best-known implementation of Fowler’s Active Record pattern: each Ruby class wraps a table, each object a row, and objects load, validate and save themselves.

What it is
Object-relational mapping (full orms)
Type
Open source
Made by
Rails core team
License
MIT
Facts checked
8 October 2026

What it is

In Active Record a model class such as Book maps to a table by convention, with no configuration: the class name is pluralised to find the books table, the primary key is an integer id, foreign keys are named like author_id, and created_at and updated_at are filled in automatically. Columns become attributes automatically: an empty class Product < ActiveRecord::Base; end already has accessors for every column of products. Objects carry both data and behaviour: Book.find_by(title: ...) loads one, setting book.title and calling book.save writes an UPDATE, and validations and callbacks run around each save. Associations (belongs_to, has_many) are declared with one line each, and migrations describe schema changes in a Ruby DSL instead of SQL.

Associations load lazily, so iterating over 10 books and reading each author runs 11 queries; the Rails guide calls this the N + 1 queries problem. includes, preload and eager_load load associations up front, turning those 11 queries into 2, and strict_loading raises an error on any lazy load that slips through. When the query interface isn’t enough, find_by_sql runs your own SQL and still returns model objects. Active Record supports MySQL, MariaDB, PostgreSQL and SQLite and ships as the activerecord gem with every Rails release; Rails 8.1 is the current series.

Why teams pick it

  • Convention over configuration: a model with associations and validations can be a handful of lines
  • Migrations, validations, callbacks and associations integrated with the rest of Rails
  • Readable query interface that stays the same across MySQL, MariaDB, PostgreSQL and SQLite
  • Tools against N+1 built in: includes, preload, eager_load and strict_loading

Watch out for

  • Domain objects are tied to the database: persistence and business logic share one class, the opposite of the Data Mapper separation, so models tend to grow large
  • Lazy associations make N+1 queries easy to write unless strict loading is turned on
  • Built around Rails conventions; legacy schemas that break them need explicit overrides for table names and keys
  • Validations and callbacks run per object on save; fast bulk changes such as update_all bypass them, so the two paths can behave differently

Alternatives

What all full orms have in common →

How it fits with other technologies

See it in a real stack

No architecture uses Active Record (Ruby on Rails) yet. Drop it into the playground and wire it up yourself.Open playground →
Where it came from2004–2025

David Heinemeier Hansson extracted Ruby on Rails from Basecamp, the project management tool he was building at 37signals, and released it as open source in July 2004. Its database layer took its name and design from the Active Record pattern Martin Fowler had described in Patterns of Enterprise Application Architecture (2002): an object that wraps a row in a table, encapsulates the database access and adds domain logic on that data.

Rails 1.0 arrived on 13 December 2005, 15 months after the first public release. Active Record combined convention over configuration, migrations written in Ruby and one-line association declarations. Hansson’s view, as Fowler later summed it up, was that anyone building on a relational database should know how it works: Active Record takes care of the boring parts but provides “manholes” to get down to SQL.

Active Record has shipped with every Rails release since, as the activerecord gem. Rails 8.0 came in November 2024 and 8.1 in October 2025, with additions over the years such as strict loading to catch N+1 queries and composite primary keys.

Why it’s built this way

Data and database access in the same object
Hansson’s doctrine admits this offends purists by mixing database interfacing with business logic, but argues it proved the practical way to build web apps that almost always persist their domain in a database.
Convention over configuration
If applications are configured the same way most of the time, that way should be the default. Naming conventions for tables, keys and timestamps remove most of the mapping configuration other ORMs need.
Schema changes as Ruby migrations
Describing changes in a Ruby DSL rather than raw SQL keeps the schema’s history in the codebase and portable across the databases Rails supports.
Manholes into SQL
Rather than pretend the database isn’t there, Active Record handles routine queries and leaves find_by_sql and raw SQL available for the rest.

Timeline

  1. 2004

    Rails, with Active Record, is released as open source in July

  2. 2005

    Rails 1.0 on 13 December

  3. 2010

    Rails 3.0 in August

  4. 2024

    Rails 8.0 in November

  5. 2025

    Rails 8.1 in October

Sources5 · facts checked 8 October 2026

Improve this page on GitHub