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_loadandstrict_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 asupdate_allbypass them, so the two paths can behave differently
Alternatives
What all full orms have in common →
Tortoise ORMOpen sourceAn async-native Python ORM with a Django-style API: models as classes, `await Model.filter(...)` queries, and built-in migrations since 1.0.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_sqland raw SQL available for the rest.
Timeline
- 2004
Rails, with Active Record, is released as open source in July
- 2005
Rails 1.0 on 13 December
- 2010
Rails 3.0 in August
- 2024
Rails 8.0 in November
- 2025
Rails 8.1 in October
- Wikipedia: Ruby on Rails, History (extracted from Basecamp, released July 2004)
- Martin Fowler: Active Record (PoEAA catalog)
- Rails blog: Rails 1.0: Party like it’s one oh oh! (13 December 2005)
- The Rails Doctrine (convention over configuration; Active Record mixes persistence and domain logic)
- Martin Fowler: OrmHate (May 2012; Hansson and Active Record’s manholes into SQL)
- RubyGems: activerecord versions (3.0.0 August 2010, 8.0.0 November 2024, 8.1.0 October 2025)
Sources5 · facts checked 8 October 2026
- Rails Guides: Active Record Basics (the pattern, naming and schema conventions, CRUD, validations, callbacks)
- Rails Guides: Active Record Query Interface (supported databases, find_by_sql, N + 1 queries, includes, strict_loading)
- Rails Guides: Active Record Migrations
- Active Record README in the Rails repository
- RubyGems: activerecord (MIT; 8.1.4 in September 2026)