Laravel Repository Pattern: Worth It or Overkill?

The Laravel repository pattern is a classic design pattern that pulls data-access logic out of your controllers and services and into a dedicated layer. The idea is simple: your code shouldn't know where the data comes from (Eloquent, a raw query, an external API); it just asks a UserRepository interface for find() or all() and gets a result back. It sounds clean, but it's one of the most debated topics in the Laravel community — because Eloquent is already an abstraction layer, and stacking a second one on top adds more burden than benefit in most projects. In this article I clarify how to set the pattern up correctly, its real upsides, its hidden costs, and when it tips over into overkill.

What does the repository pattern actually solve?

The pattern originates in Domain-Driven Design. Its goal is to isolate business logic (the domain) from persistence details. In theory a repository behaves like an in-memory collection of objects: you ask it for objects, it gives you objects, and whether SQL, a file, or a REST API sits behind it is none of your concern. In practice, in Laravel, this boils down to three main aims:

• Abstraction: business logic depends on an interface, not a concrete ORM.
• Testability: you can swap the interface for a mock and write tests without touching the database.
• Reuse: complex queries live in one place instead of being scattered across controllers.

The critical question here is: doesn't Eloquent, as an Active Record implementation, already provide part of this abstraction? It does — and that overlap is precisely the most criticized aspect of the repository pattern.

The correct setup in Laravel

If you're going to apply the pattern, do it properly. The basic structure is an interface and a concrete class implementing it. First the interface:

namespace App\Repositories\Contracts;

interface UserRepositoryInterface
{
    public function all();
    public function find(int $id);
    public function create(array $data);
}

Then the Eloquent-based concrete implementation:

namespace App\Repositories\Eloquent;

use App\Models\User;
use App\Repositories\Contracts\UserRepositoryInterface;

class EloquentUserRepository implements UserRepositoryInterface
{
    public function __construct(private User $model) {}

    public function all()
    {
        return $this->model->all();
    }

    public function find(int $id)
    {
        return $this->model->findOrFail($id);
    }

    public function create(array $data)
    {
        return $this->model->create($data);
    }
}

The final step is binding the interface to the concrete class. You do this in a service provider:

// inside AppServiceProvider or a dedicated RepositoryServiceProvider
public function register(): void
{
    $this->app->bind(
        \App\Repositories\Contracts\UserRepositoryInterface::class,
        \App\Repositories\Eloquent\EloquentUserRepository::class
    );
}

Now the controller asks for the interface and Laravel's service container injects the right implementation:

public function show(UserRepositoryInterface $users, int $id)
{
    return view('users.show', [
        'user' => $users->find($id),
    ]);
}

Note that because the binding targets the interface, the day you want to swap Eloquent for another implementation you only change the bind line. On paper, that's the pattern's promise.

The real upsides

The pattern genuinely pays off in the right context. Its most concrete benefits are:

• Centralizing complex queries. If the same multi-stage reporting query is duplicated across five controllers, moving it into a meaningful method like topSpendingCustomers() in a ReportRepository dramatically improves readability.
• Multiple data sources. When data comes partly from MySQL and partly from an external API, a repository is a natural place to merge the two behind a single interface.
• Shielding business logic from the ORM. If your domain layer is large and long-lived, not tightly coupling it to Eloquent's features theoretically makes a future ORM migration easier.

Notice these points share one trait: the project has crossed a certain complexity threshold. In small and mid-sized projects, those conditions rarely materialize.

Hidden costs and criticisms

There are reasons the community frequently criticizes the pattern, and ignoring them is a mistake:

• Eloquent is already an abstraction. User::find($id) is itself an abstraction; it can swap the database driver and generates the query without you seeing it. Layering another one on top is often doing the same thing twice.
• You lose Eloquent's power. When your repository returns a collection, the calling code can no longer use the fluent chain like where(), with(), or paginate(). To support them you add dozens of methods to the repository and end up reinventing Eloquent.
• The "swap the driver" scenario almost never happens. The pattern's headline justification is the "what if we leave Eloquent tomorrow" assumption. In practice the overwhelming majority of projects stay on Eloquent for their entire lifetime; you're engineering for a problem that doesn't exist.
• More files, more overhead. An interface, a concrete class, and a binding line per model — a maze a new team member has to navigate for little gain.

Is testability really a justification?

The repository advocates' strongest card is testing: you mock the interface and test without hitting the database. That's true, but the alternative in Laravel is free. Using a fast in-memory SQLite database with the RefreshDatabase trait is fast enough for most tests and exercises your real queries — a mocked interface stays green even if your query logic is broken.

use Illuminate\Foundation\Testing\RefreshDatabase;

class UserTest extends TestCase
{
    use RefreshDatabase;

    public function test_user_is_created(): void
    {
        $user = User::factory()->create(['email' => 'a@b.com']);
        $this->assertDatabaseHas('users', ['email' => 'a@b.com']);
    }
}

So the claim that "you need a repository for testing" collapses in most cases against Laravel's own tooling. Testability is a result of well-structured code, not of the repository specifically.

A practical alternative: a thin service layer or Action classes

In most cases what you actually want is "keep controllers thin" and "gather business logic in one place" — which doesn't require a full repository abstraction. Two lightweight approaches suffice. Service classes group related business logic while comfortably using Eloquent inside. Action classes are small single-responsibility classes with one handle() method:

class CreateUser
{
    public function handle(array $data): User
    {
        $user = User::create($data);
        $user->sendWelcomeNotification();
        return $user;
    }
}

This approach organizes the code, preserves all of Eloquent's power, and avoids the unnecessary interface layer. It's the route many experienced Laravel developers prefer over a full repository.

Frequently Asked Questions

Should I use the repository pattern in every Laravel project?

No. In the vast majority of small and mid-sized projects it's an unnecessary abstraction; using Eloquent directly, with a thin service or Action layer if needed, is simpler and easier to maintain. Only consider the pattern if you genuinely have multiple data sources, heavy and repeated queries, or a large ORM-independent domain layer.

Does the repository pattern affect performance?

There's no directly measurable performance impact; the cost of an extra class call is negligible. The real risk is indirect: a naive repository that returns collections can lead to the N+1 query problem if it stops the calling code from eager loading with with(). That's a result of poor implementation, not of the pattern itself.

Does the repository pattern replace Eloquent?

No, it sits on top of it rather than replacing it. Inside the repository you usually still use Eloquent; the pattern merely hides that usage behind an interface. Abandoning Eloquent entirely is not a prerequisite for using the pattern.

Does your Laravel project really need the repository pattern, or is a simpler architecture enough? We can look at your project's scale and determine the right level of abstraction together — get in touch with me.