Laravel oder Symfony: Was für Projekt und Team passt

In der JetBrains-Umfrage State of PHP 2025 nutzten 64 Prozent der 1.720 Befragten Laravel und 23 Prozent Symfony. Das klingt nach einem klaren Ergebnis. Es ist aber nur die halbe Geschichte, denn Laravel steht selbst zum Teil auf Symfony: Komponenten wie HttpFoundation oder Console stammen aus dem Symfony-Projekt.

Die Frage ist also weniger, welches Framework „besser“ ist. Sie lautet: Welche Arbeitsweise passt zu deinem Projekt, und welche Leute bekommst du dafür?

Der grundlegende Unterschied: Konvention gegen Explizitheit

Laravel trifft viele Entscheidungen für dich. Ein Model namens Order gehört automatisch zur Tabelle orders, Facades geben schnellen Zugriff auf Dienste, und mit wenigen Zeilen steht eine funktionierende Anwendung. Das macht schnell. Es macht aber auch weniger sichtbar, was im Hintergrund passiert.

Symfony verlangt, dass du mehr selbst festlegst. Dienste werden über den Container verdrahtet, Konfiguration steht explizit in Dateien oder Attributen, und das ORM Doctrine trennt Objekt und Datenbank strikter. Das kostet am Anfang Zeit. In großen Teams, in denen Leute kommen und gehen und niemand mehr weiß, wer eine Entscheidung vor fünf Jahren getroffen hat, spart es später viele Diskussionen darüber, wie etwas funktioniert.

Am deutlichsten wird das beim Datenzugriff. Hier dieselbe Bestellung in beiden Welten:

// Laravel: Eloquent (Active Record)
use Illuminate\Database\Eloquent\Model;
use Illuminate\Database\Eloquent\Relations\BelongsTo;

final class Order extends Model
{
    protected $fillable = ['customer_id', 'total_cents'];

    public function customer(): BelongsTo
    {
        return $this->belongsTo(Customer::class);
    }
}

$order = Order::create(['customer_id' => 7, 'total_cents' => 4_990]);

// Symfony: Doctrine (Data Mapper)
use Doctrine\ORM\Mapping as ORM;

#[ORM\Entity(repositoryClass: OrderRepository::class)]
#[ORM\Table(name: 'orders')]
class Order
{
    #[ORM\Id, ORM\GeneratedValue, ORM\Column]
    private ?int $id = null;

    public function __construct(
        #[ORM\ManyToOne(targetEntity: Customer::class)]
        #[ORM\JoinColumn(nullable: false)]
        private Customer $customer,

        #[ORM\Column]
        private int $totalCents,
    ) {}
}

$order = new Order($customer, 4_990);
$entityManager->persist($order);
$entityManager->flush();

Bei Eloquent weiß das Objekt selbst, wie es sich speichert. Bei Doctrine ist die Klasse ein normales PHP-Objekt, gespeichert wird über den EntityManager. Das Eloquent-Beispiel ist kürzer. Das Doctrine-Beispiel lässt sich dafür ohne Datenbank testen und zwingt zu einem gültigen Zustand ab dem Konstruktor.

Keins von beiden ist falsch. Wer viele kleine Features in kurzer Zeit liefern muss, schätzt Eloquent. Wer komplexe Fachlogik über Jahre pflegt, schätzt oft die Trennung bei Doctrine.

Release-Zyklen und Support im Vergleich

Für ein System, das zehn Jahre laufen soll, sind die Support-Zeiträume wichtiger als jedes Feature. Hier unterscheiden sich die beiden deutlich.

Laravel 13 erschien am 17. März 2026 und bekommt laut den Laravel Release Notes Sicherheitsupdates bis 17. März 2028. Symfony 7.4 ist eine LTS-Version vom November 2025 mit Bugfixes bis November 2028 und Sicherheitsupdates bis November 2029, nachzulesen auf symfony.com/releases.

Praktisch heißt das: Ein Laravel-Projekt braucht etwa jedes Jahr ein Major-Upgrade, wenn es im Support bleiben will. Laravel bemüht sich, diese Upgrades klein zu halten. Ein Symfony-Projekt auf LTS kann zwei Jahre ruhiger laufen, das Upgrade danach ist dafür größer. Was solche Upgrades kosten, steht im Beitrag zu den Kosten eines PHP-Upgrades.

Ökosystem: was rund um das Framework mitkommt

Beide Frameworks stehen unter der MIT-Lizenz und kosten nichts. Geld verdienen die Firmen dahinter mit Diensten drumherum, und genau dort unterscheiden sie sich spürbar.

Laravel hat ein dichtes Angebot aus einer Hand. Forge und Laravel Cloud kümmern sich um Server und Deployment, Horizon überwacht Queues, Nova ist ein Admin-Panel, Livewire bringt interaktive Oberflächen ohne viel JavaScript. Für ein kleines Team ist das bequem: Viele Entscheidungen sind schon getroffen, und die Dokumentation erklärt alles im selben Stil.

Symfony setzt stärker auf Bausteine. Flex installiert Pakete samt Konfiguration, Messenger übernimmt asynchrone Verarbeitung, und auf Symfony bauen eigene Projekte wie API Platform auf. Wer nur einen Teil braucht, etwa die Console-Komponente für ein Kommandozeilenwerkzeug, nimmt sich genau diesen Teil. Das passt zu Organisationen, die ungern von einem einzelnen Anbieter abhängen.

Für die Personalsuche hat das eine Folge, die man leicht übersieht. Bewerber für Laravel-Projekte erwarten oft die üblichen Werkzeuge des Ökosystems. Wer eine Laravel-Anwendung ohne Queues, ohne Tests und mit selbst gebautem Deployment betreibt, sollte das in der Anzeige erwähnen. Sonst gibt es im zweiten Gespräch lange Gesichter.

Was die Wahl für die Personalsuche bedeutet

Hier kippt die Entscheidung oft. Bei einem Verhältnis von etwa 64 zu 23 Prozent in der JetBrains-Umfrage findest du Laravel-Leute schlicht leichter. Wie du sie gezielt suchst, beschreibt der Beitrag Laravel-Entwickler finden.

Symfony-Entwickler sind seltener, bringen aber häufig Erfahrung aus größeren Systemen mit: Behörden, Versicherungen, große Shops. Viele kennen Doctrine, Messenger, strenge statische Analyse und lange Lebenszyklen. Ein interessantes Detail aus der Umfrage: PhpStorm nutzen 83 Prozent der Symfony-Entwickler, bei Laravel sind es 62 Prozent. Das sagt nichts über Qualität, deutet aber auf eine etwas andere Werkzeugkultur hin.

Meine Einschätzung für die Suche:

• Hast du schon ein Team, entscheidet dessen Erfahrung. Ein Framework-Wechsel wegen des Bewerbermarkts lohnt sich fast nie.
• Startest du neu und brauchst bald drei, vier Leute, spricht der größere Pool für Laravel.
• Baust du ein System für eine Behörde oder einen Konzern mit Ausschreibungen, ist Symfony häufig schon gesetzt oder zumindest leichter zu verkaufen.

Wechsel zwischen den Welten funktionieren übrigens besser, als viele denken. Dependency Injection und Middleware gibt es in beiden. Events und Queues auch. Ein erfahrener Entwickler aus der einen Welt braucht für die andere eher Wochen als Monate. Nicht jeder will das aber, also frag im Gespräch danach.

Wann Laravel, wann Symfony

Eine Entscheidungshilfe, bewusst zugespitzt:

Die Tabelle ist eine Einschätzung, keine Regel. Es gibt langlebige Laravel-Systeme mit Dutzenden Entwicklern, und es gibt Symfony-MVPs, die nach wenigen Wochen online waren, weil das Team sein Framework seit Jahren im Schlaf beherrscht. Der wichtigste Faktor ist das Wissen, das schon im Haus ist.

Wie du im Interview Framework-Wissen prüfst

Wer „Laravel“ oder „Symfony“ im Lebenslauf stehen hat, sollte erklären können, wie das Framework eine Anfrage verarbeitet. Bei Laravel: Service Provider, Middleware, Controller, Eloquent. Bei Symfony: Kernel, Event-Listener, Controller, Doctrine. Eine gute Antwort zeichnet den Weg einer Anfrage nach, ohne nachzuschlagen.

Eine zweite gute Frage: „Was würdest du an unserem Framework vermissen, wenn du zum anderen wechseln müsstest?“ Wer beide kennt, antwortet konkret. Wer nur eins kennt, sagt das hoffentlich ehrlich. Weitere Fragen, auch zu modernem PHP, stehen in unserem Katalog mit PHP-Interviewfragen.

Wenn die Entscheidung gefallen ist, aber das Team dafür fehlt, kann ein externes Studio wie OnlineBuilders Aufbau und Betrieb übernehmen, auch auf einer bestehenden Codebasis. Für die eigene Suche ist die Stellenanzeige der nächste Baustein; eine Vorlage findest du unter Stellenanzeige für PHP-Entwickler.

Nimm dir als Nächstes die Tabelle oben und markiere ehrlich, welche Zeilen auf dein Vorhaben zutreffen. Wenn das Ergebnis knapp ist, entscheide nach dem Framework, das die Person beherrscht, die das Projekt technisch führen wird.