ORM Pattern

Whether each ORM follows the Active Record pattern, the Data Mapper pattern, or a query-builder-first design.

Active Record (Ruby on Rails)

The namesake implementation of the Active Record pattern — each model class both wraps a database row and carries the logic to save, validate, and query it, so the object and its persistence are inseparable.

Eloquent (Laravel)

Also implements the Active Record pattern directly: an Eloquent model instance represents a single row and knows how to save, delete, and query itself.

Django ORM

Follows the Active Record pattern as well — a Django model class defines both the schema and the behavior for querying and saving that data, accessed through the class’s own .objects manager.

Prisma

Doesn’t fit neatly into either classic pattern — it generates a fully separate, type-safe query client from your schema, closer in spirit to a typed query builder than a Data Mapper or Active Record system.

Drizzle

Primarily a typed SQL query builder rather than a classic ORM pattern — there’s no “model” object with built-in save/delete behavior, just composable, SQL-like queries with full TypeScript inference.

TypeORM

Supports both patterns: an Active Record style (entities with built-in save()/remove() methods) and a Data Mapper style (separate repository classes), letting teams choose.

Sequelize

Primarily Active Record-style — model classes carry both schema and persistence behavior, similar in spirit to Rails/Laravel/Django’s approach but in JavaScript.

SQLAlchemy

The clearest Data Mapper implementation in this group — its Core layer builds SQL expressions independently of Python objects, while its ORM layer maps plain Python classes to tables without those classes needing to know how to persist themselves.

Entity Framework Core

Follows the Data Mapper pattern — plain C# classes represent your data, while a separate DbContext handles all querying and persistence logic on their behalf.

Hibernate (JPA)

The canonical Java implementation of the Data Mapper pattern — POJOs (plain Java objects) stay persistence-ignorant, with a separate EntityManager handling all database interaction.

GORM

Blends the two patterns — structs represent data like a Data Mapper approach, but GORM attaches many Active-Record-like convenience methods (Save(), Find()) directly onto usage of those structs via the GORM handle.

Diesel

Closer to a Data Mapper/query-builder hybrid — structs represent rows, but all querying goes through Diesel’s explicit, compile-time-checked query builder rather than methods on the struct itself.