A client asked me last month whether we should build their new billing system in Symfony or Laravel, and I caught myself giving the most annoying answer in the world: “it depends.” Then I actually had to explain what it depends on, out loud, to a non-technical person who was paying for my time. That conversation is what this post is. I’ve shipped real things in both, kept some, regretted a few, and I finally have a rule I trust.
Short version for the impatient: I reach for Laravel when I want to ship a product fast with a small team, and Symfony when I’m building something that a rotating cast of engineers will maintain for the next eight years. If you want to know why, read on.
One thing to get out of the way first, because it trips people up: this isn’t really a fight. Laravel is built on top of Symfony components. The HTTP layer, the console, the routing internals, a lot of the plumbing you rely on in Laravel is literally Symfony code. So when someone frames it as “PHP’s two rival frameworks,” they’re half wrong. One of them quietly runs inside the other.
The philosophy gap is the whole story
Laravel optimizes for how fast a human can go from idea to working feature. It hides wiring behind sensible defaults, gives you an ORM that reads like plain English, and assumes you’d rather write less config than have more control. That assumption is correct about 80% of the time, which is why Laravel feels so good for the first three months of a project.
Symfony optimizes for the opposite thing. It wants the wiring to be visible, explicit, and swappable. Nothing is magic. You declare your services, you configure your dependencies, and in exchange you get an app where any competent PHP developer can trace exactly how a request becomes a response. That’s tedious on day one and a gift on day eight hundred.
Here’s the same idea in code. A basic route and controller in Laravel:
// routes/web.php
Route::get('/invoices/{invoice}', [InvoiceController::class, 'show']);
// app/Http/Controllers/InvoiceController.php
class InvoiceController extends Controller
{
public function show(Invoice $invoice)
{
// Route-model binding already fetched the row for me
return view('invoices.show', ['invoice' => $invoice]);
}
}
Notice what I didn’t write. I didn’t fetch the invoice. Laravel saw the type hint, matched the route parameter, and loaded the model for me. That’s the magic people love and occasionally curse.
The same thing in Symfony is more spelled out:
// src/Controller/InvoiceController.php
#[Route('/invoices/{id}', name: 'invoice_show')]
public function show(int $id, InvoiceRepository $invoices): Response
{
$invoice = $invoices->find($id);
if (!$invoice) {
throw $this->createNotFoundException();
}
return $this->render('invoice/show.html.twig', [
'invoice' => $invoice,
]);
}
More lines, yes. But the repository got injected because I asked for it by type, the fetch is right there where I can see it, and the 404 is my decision instead of a framework convention. Symfony can do route-model binding too with a value resolver, but the default posture is “show your work.”
The ORM difference matters more than the syntax
This is where I’ve watched teams make expensive mistakes, so I’ll be blunt about it.
Laravel’s Eloquent is an Active Record ORM. Your model is the table, and the row knows how to save itself. It’s wonderful for moving quickly:
$invoice = Invoice::create([
'client_id' => $client->id,
'amount' => 4200,
'status' => 'draft',
]);
$invoice->status = 'sent';
$invoice->save();
$overdue = Invoice::where('status', 'sent')
->where('due_at', '<', now())
->get();
Symfony pairs with Doctrine, which is a Data Mapper. Your entity is a plain object that knows nothing about the database, and a separate manager handles persistence:
$invoice = new Invoice();
$invoice->setClient($client);
$invoice->setAmount(4200);
$invoice->setStatus('draft');
$entityManager->persist($invoice);
$entityManager->flush();
$overdue = $invoiceRepository->createQueryBuilder('i')
->where('i.status = :status')
->andWhere('i.dueAt < :now')
->setParameter('status', 'sent')
->setParameter('now', new \DateTimeImmutable())
->getQuery()
->getResult();
Eloquent gets you to a demo faster. No argument. But Active Record couples your domain logic to your database schema, and on a big app that coupling becomes the thing you fight every time you refactor. Doctrine keeps your business objects clean and testable at the cost of more ceremony up front. The Doctrine ORM documentation is upfront that the persist-then-flush model exists precisely so your entities stay ignorant of the database, which is the whole point and also the part beginners hate. I’ve seen a five-year-old Eloquent codebase where nobody could change a column without breaking six unrelated features. I’ve also seen junior devs bounce hard off that flush model and quietly go back to raw SQL. Both problems are real. Pick the one you’d rather have.
Tooling and the day-to-day feel
Both frameworks have strong command-line tools. Laravel’s Artisan is friendlier out of the box:
php artisan make:model Invoice -mcr # model, migration, controller in one shot
php artisan migrate
php artisan queue:work
Symfony’s console is just as capable, a little more verbose, and leans on the MakerBundle for scaffolding:
php bin/console make:entity Invoice
php bin/console doctrine:migrations:migrate
php bin/console messenger:consume async
The real difference isn’t the commands, it’s the ecosystem around them. Laravel ships a whole first-party universe: Forge for servers, Vapor for serverless, Horizon for queues, Nova for admin panels, plus starter kits that give you auth and billing in an afternoon. If you want to see how I lean on the queue side of that stack in production, I wrote up my Laravel Horizon setup separately. Symfony’s answer is smaller in scope and bigger in flexibility: you assemble the pieces you want, and a lot of the wider PHP world already runs on its components. You can read the details in the official Symfony documentation and Laravel documentation, both of which are genuinely good, which is not something I can say about most framework docs.
Release cadence, which nobody thinks about until it hurts
Here’s a boring factor that decides more architecture debates than any syntax preference: how predictable are the upgrades?
Symfony runs on a fixed calendar. A new minor version every six months, a new major every two years, and long-term-support releases you can sit on for years while getting security fixes. If you’re a bank or a government contractor, that predictability is worth more than any feature. You can plan a three-year maintenance budget and actually hit it.
Laravel moves faster and less formally. Laravel 12 landed in early 2025, and the pace of the ecosystem means you’re upgrading more often and adapting to more change. I covered what actually shifted in that release in my breakdown of Laravel 12’s new features, and the honest summary is that the churn is a tax you pay for velocity. For a product startup, that’s a fine trade. For a system that has to survive three CTO transitions, less so.
So which one do I actually pick
My rule now fits on a sticky note. If the project is a product, if the team is small, and if speed to first revenue is the thing that matters, I use Laravel and I don’t feel bad about the magic. If the project is a long-lived system with a big team, strict architecture needs, or a compliance story that outlasts everyone currently employed, I use Symfony and I’m grateful for every explicit line.
The trap is choosing based on which one felt nicer in a weekend tutorial. Laravel always wins the weekend. That tells you almost nothing about year three. I’ve made that mistake, shipped fast, and then spent a quarter untangling coupling that a stricter framework would have prevented. I’ve also over-engineered a tiny internal tool in Symfony and annoyed everyone including myself.
If you want to see the kind of production PHP work these decisions come out of, that’s most of what I do in my consulting and project work. And if you’re on the fence right now, do this one thing this week: write down how long the app has to live and how many people will touch it. Not the features. Just those two numbers. Nine times out of ten, they pick the framework for you.
