# Eloquent Model vs Model in Laravel: Understanding the Fundamental Difference

> Understand the core Eloquent model difference in Laravel. Discover how Eloquent models offer ORM persistence, unlike plain PHP models.

- Repository: [Laravel/framework](https://github.com/laravel/framework)
- Tags: deep-dive
- Published: 2026-02-16

---

**An Eloquent model extends `Illuminate\Database\Eloquent\Model` and provides active-record database interaction, while a plain Laravel model is any PHP class representing domain data without ORM coupling or built-in persistence logic.**

When working with the `laravel/framework` repository, developers encounter two distinct interpretations of the term "model." Understanding the difference between an Eloquent model and a model in the context of a Laravel model setup is crucial for architecting maintainable applications. While both represent data structures, their coupling to the database layer and available functionality differ fundamentally.

## What Is an Eloquent Model in Laravel?

An Eloquent model is a PHP class that extends `Illuminate\Database\Eloquent\Model`, the core active-record base class located in [`src/Illuminate/Database/Eloquent/Model.php`](https://github.com/laravel/framework/blob/main/src/Illuminate/Database/Eloquent/Model.php). This inheritance chain provides a robust ORM layer that maps database tables to objects, enabling developers to interact with relational data using expressive PHP syntax rather than raw SQL.

The Eloquent implementation leverages traits such as `ForwardsCalls` (from [`src/Illuminate/Support/Traits/ForwardsCalls.php`](https://github.com/laravel/framework/blob/main/src/Illuminate/Support/Traits/ForwardsCalls.php)) to delegate method calls to the underlying query builder, creating the fluent interface developers expect when chaining methods like `where()` and `first()`.

## What Is a Plain Laravel Model?

A plain Laravel model—often implemented as a Data Transfer Object (DTO) or value object—is simply a PHP class that does not extend the Eloquent base class. These classes represent domain concepts or data structures without assuming database persistence capabilities. Unlike Eloquent models, plain models contain no built-in query methods, relationship helpers, or active-record lifecycle hooks.

Developers typically use plain models when data originates from external APIs, configuration files, CSV imports, or when implementing domain-driven design patterns that require strict separation between business logic and data access layers.

## Key Differences Between an Eloquent Model and a Model

Understanding the architectural distinctions helps determine which approach fits specific use cases.

### Database Coupling and Active Record Pattern

**Eloquent models** implement the active-record pattern, meaning each object carries both data and database access logic. The class in [`src/Illuminate/Database/Eloquent/Model.php`](https://github.com/laravel/framework/blob/main/src/Illuminate/Database/Eloquent/Model.php) provides methods like `save()`, `update()`, and `delete()` that translate directly to SQL operations.

**Plain models** remain persistence-agnostic. They hold state but delegate storage operations to repositories, services, or external APIs, maintaining strict separation of concerns.

### Query Building and Relationships

**Eloquent** provides a fluent query API through method forwarding to the query builder. Relationships like `hasOne()`, `hasMany()`, and `belongsTo()` are defined as methods returning `Illuminate\Database\Eloquent\Relations\Relation` subclasses, enabling eager loading via `with()` and lazy loading through dynamic properties.

**Plain models** lack these capabilities. Implementing relationships requires manual foreign key management and query construction using the `DB` facade or query builder directly.

### Built-in Functionality via Traits

**Eloquent models** leverage a rich trait ecosystem:
- `HasFactory` ([`src/Illuminate/Database/Eloquent/Factories/HasFactory.php`](https://github.com/laravel/framework/blob/main/src/Illuminate/Database/Eloquent/Factories/HasFactory.php)) for testing
- `SoftDeletes` ([`src/Illuminate/Database/Eloquent/SoftDeletes.php`](https://github.com/laravel/framework/blob/main/src/Illuminate/Database/Eloquent/SoftDeletes.php)) for non-destructive deletion
- `Notifiable` for notifications

**Plain models** only include traits you explicitly import, keeping the class lightweight but requiring manual implementation of cross-cutting concerns.

## Code Examples: Eloquent vs Plain Model

### Eloquent Model Implementation

The following example extends `Illuminate\Database\Eloquent\Model` to create an active-record entity with relationships and soft deletes:

```php
<?php

namespace App\Models;

use Illuminate\Database\Eloquent\Model;
use Illuminate\Database\Eloquent\SoftDeletes;

class Post extends Model
{
    use SoftDeletes;

    protected $fillable = ['title', 'body', 'author_id'];

    public function author()
    {
        return $this->belongsTo(User::class, 'author_id');
    }
}

```

Usage demonstrates the active-record pattern:

```php
// Create and persist in one operation
$post = Post::create([
    'title' => 'Laravel 12 Features',
    'body'  => 'New Eloquent improvements...',
    'author_id' => 1,
]);

// Query with eager loading
$posts = Post::with('author')
    ->where('title', 'like', '%Laravel%')
    ->get();

```

### Plain Model Implementation

This Data Transfer Object represents the same domain concept without database coupling:

```php
<?php

namespace App\DTO;

class PostData
{
    public string $title;
    public string $body;
    public int $authorId;

    public function __construct(string $title, string $body, int $authorId)
    {
        $this->title = $title;
        $this->body = $body;
        $this->authorId = $authorId;
    }
}

```

Persistence requires explicit service logic:

```php
use App\DTO\PostData;
use App\Services\PostService;

$data = new PostData('Laravel 12 Features', 'Content...', 1);
$service = new PostService();
$posted = $service->store($data); // Handles API call or manual DB insert

```

### When to Use Each Approach

- **Choose Eloquent** when mapping database tables with relationships, requiring query scopes, soft deletes, or active-record convenience methods.
- **Choose Plain Models** when integrating external APIs, implementing domain-driven design, or when strict separation between business logic and persistence is required.

## Core Laravel Source Files

The Eloquent ORM implementation resides in specific files within the `laravel/framework` repository:

- **[`src/Illuminate/Database/Eloquent/Model.php`](https://github.com/laravel/framework/blob/main/src/Illuminate/Database/Eloquent/Model.php)** – The base active-record class providing attribute management, CRUD operations, and relationship handling.
- **[`src/Illuminate/Database/Eloquent/Relations/Relation.php`](https://github.com/laravel/framework/blob/main/src/Illuminate/Database/Eloquent/Relations/Relation.php)** – Base class for relationship types including `HasOne`, `BelongsTo`, and polymorphic variants.
- **[`src/Illuminate/Database/Eloquent/Factories/HasFactory.php`](https://github.com/laravel/framework/blob/main/src/Illuminate/Database/Eloquent/Factories/HasFactory.php)** – Trait enabling model factories for testing.
- **[`src/Illuminate/Database/Eloquent/SoftDeletes.php`](https://github.com/laravel/framework/blob/main/src/Illuminate/Database/Eloquent/SoftDeletes.php)** – Trait implementing non-destructive deletion via the `deleted_at` timestamp.
- **[`src/Illuminate/Support/Traits/ForwardsCalls.php`](https://github.com/laravel/framework/blob/main/src/Illuminate/Support/Traits/ForwardsCalls.php)** – Supports dynamic method forwarding from models to the underlying query builder.

## Summary

- **Eloquent models** extend `Illuminate\Database\Eloquent\Model` and implement the active-record pattern, providing built-in database persistence, query building, and relationship management.
- **Plain Laravel models** are standard PHP classes representing domain data without ORM coupling, requiring manual persistence logic but offering greater architectural flexibility.
- The choice depends on data source requirements: use Eloquent for relational database mapping and plain models for external APIs, DTOs, or domain-driven design scenarios.
- Core Eloquent functionality resides in [`src/Illuminate/Database/Eloquent/Model.php`](https://github.com/laravel/framework/blob/main/src/Illuminate/Database/Eloquent/Model.php) and related traits within the `laravel/framework` repository.

## Frequently Asked Questions

### Can I use a plain PHP class as an Eloquent model?

No, Eloquent requires classes to extend `Illuminate\Database\Eloquent\Model` located in [`src/Illuminate/Database/Eloquent/Model.php`](https://github.com/laravel/framework/blob/main/src/Illuminate/Database/Eloquent/Model.php). However, you can use plain classes as Data Transfer Objects (DTOs) alongside Eloquent models, passing data between layers without database coupling.

### Do I lose Eloquent features if I create a custom base model?

If your custom base model extends `Illuminate\Database\Eloquent\Model`, all Eloquent features remain available. You can add custom methods or override existing ones while retaining active-record capabilities, query building, and trait support like `SoftDeletes` and `HasFactory`.

### When should I choose a DTO over an Eloquent model?

Choose a Data Transfer Object (plain model) when data originates from external APIs, configuration files, or CSV imports, or when implementing domain-driven design that requires strict separation between business logic and persistence. Eloquent models excel when mapping relational database tables with complex relationships and query requirements.

### How do relationships work in plain models versus Eloquent?

Eloquent models define relationships using methods like `hasOne()`, `hasMany()`, and `belongsTo()` that return `Illuminate\Database\Eloquent\Relations\Relation` instances, enabling lazy loading, eager loading via `with()`, and relationship existence queries. Plain models lack these helpers; you must manually implement foreign key logic and query the database using the query builder or external API calls.