The Active Record pattern is a way of connecting application objects to a relational database in which each object corresponds to a single row of a table. Martin Fowler named and catalogued the pattern in his 2002 book Patterns of Enterprise Application Architecture, defining an Active Record as “an object that wraps a row in a database table or view, encapsulates the database access, and adds domain logic on that data.” The object is both the data and the gateway to its own storage.
In practice this means a class such as Customer maps to a customers table, an instance of that class holds the fields of one row, and the same object exposes methods to load itself, save changes, and delete itself. Because the persistence logic lives directly on the domain object, code reads and writes the database through ordinary method calls rather than separate data-access layers or hand-written SQL scattered through the application.
Fowler describes the pattern’s appeal as its directness: it places data-access logic in the domain object so developers can intuitively read and write persistent data. The trade-off, which he also notes, is that Active Record tightly couples the object model to the database schema, so when the in-memory design and the table design diverge significantly, a more decoupled approach such as Data Mapper can fit better.
The pattern existed in various forms before it had a name, but it became famous through Ruby on Rails, whose Active Record library made it the default way to model data in a Rails application. The library leaned on convention so heavily that a model usually needed no configuration to find its table or its columns, and that frictionless mapping was a large part of why Rails felt so productive. Other frameworks followed, most prominently Laravel, whose Eloquent ORM is an Active Record implementation for PHP.
Active Record sits within the broader family of object-relational mapping techniques, and contrasting it with Data Mapper became one of the standard discussions in how to bridge objects and tables. As a named pattern it gave the industry a shared vocabulary for a design that countless web applications now use without a second thought, anchoring much of modern framework data modeling to a single, well-described idea.