ESX vs QBCore vs QBox im Jahr 2026: welches FiveM-Framework wählen
Die Wahl eines FiveM-Frameworks ist die eine frühe Entscheidung, die du nicht einfach rückgängig machen kannst. Das Framework liefert die Datenbankstruktur, die Charaktererstellung, Jobs, Geld und das Inventar, auf denen alles andere auf deinem Server aufbaut. 2026 gibt es drei ernstzunehmende Optionen - ESX, QBCore und QBox - und sie sind nicht austauschbar. Ein Script, das für eines geschrieben wurde, läuft ohne Konvertierung nicht auf einem anderen. Dieser Guide erklärt, was jedes davon ist, wie sie sich unterscheiden und wie du die richtige Basis wählst, bevor du mit dem Bauen beginnst.
Der Grund, warum das so wichtig ist, ist die Kompatibilität. Es gibt kein gemeinsames Script-Format über diese Frameworks hinweg, also legst du dich in dem Moment, in dem du eines wählst, auf dessen Script-Ökosystem, dessen Konventionen und dessen Community fest. Später zu wechseln bedeutet, jede Ressource zu konvertieren und deine Datenbank neu zu importieren. Wähle bewusst.
Die drei Frameworks auf einen Blick
Vor dem Detail hier die Kurzfassung, wo jedes davon steht:
- ESX ist der Veteran. Die größte Script-Bibliothek, das tiefste Community-Wissen und die längste Erfolgsbilanz.
- QBCore ist der moderne Roleplay-Standard, der ab etwa 2022 ESX bei neuen Servern abgelöst hat, mit mehr ab Werk eingebauten Systemen.
- QBox ist das neueste, ein Community-Fork von QBCore, neu rund um das ox-Ökosystem aufgebaut, gestaltet als das, wie QBCore aussähe, wenn es heute geschrieben würde.
Entscheidender Punkt: ESX-Scripts und QBCore-Scripts sind nicht untereinander kompatibel. Entscheide dich für die Funktionen und das Ökosystem, das du möchtest, bevor du dich festlegst, denn ein späterer Framework-Wechsel bedeutet, all deine Scripts zu konvertieren und deine Datenbank zu überarbeiten.
ESX: das etablierte Ökosystem
ESX, kurz für EssentialMode Extended, war von etwa 2018 bis 2022 das dominierende Roleplay-Framework. Seine große Stärke ist das Alter. Weil es am längsten existiert, ist die Menge der dafür geschriebenen Ressourcen enorm, und nahezu jeder erfahrene FiveM-Entwickler hat damit gearbeitet. Wenn du ein Script, ein Tutorial oder einen Entwickler brauchst, der etwas repariert, ist der ESX-Talentpool der tiefste der drei.
Wo ESX stark ist
- Größte Script-Bibliothek: über Jahre angesammelte Ressourcen bedeuten, dass es von fast allem eine ESX-Version gibt.
- Tiefes Community-Wissen: Support, Guides und Entwickler sind leicht zu finden.
- Moderne Performance: ESX Legacy hat viel vom alten Code-Ballast aufgelöst, und aktuelle Versionen sind konkurrenzfähig, statt hinterherzuhinken.
Wo ESX zu kurz greift
- Weniger moderne Systeme eingebaut: Basis-ESX deckt die Grundlagen wie Jobs und einfaches Housing ab, es fehlen aber ein modernes Inventar, ein eingebautes Targeting-System, native Tank- und Fahrzeugschlüssel-Systeme, Wetterverwaltung und ein Handy. Diese setzt du aus separaten Ressourcen zusammen.
- Altlasten: ältere ESX-Scripts wurden mit veralteten Praktiken geschrieben, also kann eine ungepflegte Ressourcenliste die Performance immer noch belasten, selbst wenn der Kern in Ordnung ist.
ESX ergibt am meisten Sinn, wenn du es bereits betreibst. Wenn du einen Server mit eigenen ESX-Scripts und einer funktionierenden Datenbank hast, ist eine Abwanderung den Aufwand selten wert.
QBCore: der moderne Roleplay-Standard
QBCore wurde gebaut, um die unsaubereren Teile älterer Frameworks neu zu schreiben, mit Fokus auf klarere Struktur, Modularität und Optimierung. Ab etwa 2022 wurde es zum gängigen Ausgangspunkt für neue Roleplay-Server und bleibt ein sicherer, beliebter Standard.
Wo QBCore stark ist
- Mehr eingebaute Funktionen: es enthält die Grundlagen, die ESX hat, plus Systeme, die ESX ab Werk weglässt - ein modernes Inventar, eine dedizierte Target-Ressource, Fahrzeugtank- und Schlüsselsysteme, Wetterverwaltung und ein Admin-Menü.
- Saubererer, modularerer Code: die Struktur ist freundlicher zur Anpassung, was ein großer Teil davon ist, warum es sich durchgesetzt hat.
- Fokus auf Optimierung: effizientere Datenbankabfragen und Event-Behandlung als älterer Framework-Code.
Wo QBCore zu kurz greift
- Dünnere Dokumentation: da neuer als ESX, hat es weniger Jahre an Guides, Videos und Forenthreads, auf die es sich stützen kann.
- Verlangsamte Entwicklung: das ist der wichtige Punkt für 2026. Die aktive Entwicklung am originalen QBCore ist weitgehend zum Stillstand gekommen, und genau deshalb existiert QBox.
QBox: QBCore, neu aufgebaut auf dem ox-Ökosystem
QBox ist ein community-getriebener Fork von QBCore, erstellt von ehemaligen QBCore-Mitwirkenden, die angesammelte Performance-, Sicherheits- und Code-Qualitätsprobleme beheben wollten, statt das Original weiter zu flicken. Statt ein Monolith zu sein, ist es modular: seine Kern-Ressource qbx_core ersetzt qb-core, und die schwere Arbeit wird an zweckgebaute ox-Ressourcen delegiert.
Worauf QBox aufbaut
- ox_lib für gemeinsame Utilities und UI
- ox_inventory als Standard-Inventar
- oxmysql für den Datenbankzugriff
- ox_target für Interaktionen
Es zielt auf Lua 5.4 ab und liefert mehrere Dinge direkt in qbx_core, die bei QBCore separate Ressourcen brauchten, darunter Multicharacter-Auswahl, eine Server-Queue, Multijob- und Multigang-Unterstützung sowie Discord Rich Presence. Jede Komponente kann unabhängig aktualisiert werden, sodass ein einzelnes Update nicht den ganzen Server gefährdet.
Der Kompatibilitätsvorteil
QBox behält eine Bridge-Schicht für Abwärtskompatibilität mit den dokumentierten, korrekten Wegen der qb-core-Nutzung, sodass die meisten bestehenden QBCore-Scripts ohne Änderung darauf laufen. Die Hauptausnahmen sind Scripts, die sich tief in QBCore-Interna einklinken, statt die öffentliche API zu nutzen, und die kleinere Anpassungen brauchen können. In der Praxis bedeutet das, dass du eine moderne, aktiv gepflegte Basis bekommst und trotzdem auf die große QBCore-Script-Bibliothek zurückgreifen kannst.
Eine Anmerkung zum Ökosystem: das Overextended-Projekt hinter den ox-Ressourcen wurde 2025 eingestellt, aber Community-Maintainer hielten oxmysql, ox_lib, ox_inventory und ox_core am Leben, und 2026 wurde die aktive Entwicklung wieder aufgenommen. Der ox-Stack, von dem QBox abhängt, wird wieder gepflegt.
Performance: lies die Benchmarks sorgfältig
Performance ist der am meisten umstrittene Punkt, und die ehrliche Antwort lautet, dass es von der Version und davon abhängt, welche Scripts du betreibst. Jahrelang lautete die gängige Behauptung, dass QBCore ESX übertreffe. Neuere Benchmarks aus 2026 haben Teile dieser Geschichte umgekehrt: gut abgestimmtes, modernes ESX Legacy liefert starke rohe CPU-Werte, und QBox verbraucht dank Lazy Loading, weniger redundanter Polling-Loops und der optimierten ox-Utility-Funktionen deutlich weniger CPU als das originale QBCore.
Die praktische Erkenntnis ist nicht "Framework X ist immer am schnellsten." Es ist, dass deine Ressourcenliste und dein Hosting mehr zählen als das Framework-Etikett. Ein aufgeblähter Server läuft auf jedem Framework schlechter als ein schlanker. Für die Gewohnheiten, die Tick-Times tatsächlich bewegen, siehe unseren Guide zur Optimierung der FiveM-Server-Performance.
Der Entscheidungsleitfaden
Lässt man das Rauschen weg, läuft die Wahl auf deine Situation hinaus:
Du startest 2026 von Grund auf neu
Nutze eine moderne Basis aus der QBCore-Familie. QBox ist die zunehmend empfohlene Wahl für neue Server, weil es der aktiv gepflegte Nachfolger ist: modernes Lua, native ox-Integration, eine wachsende Script-Bibliothek und Kompatibilität mit den meisten bestehenden QBCore-Ressourcen. QBCore selbst bleibt ein vernünftiger, bekannter Standard, wenn du den größeren Pool an Guides möchtest, aber sei dir bewusst, dass seine Entwicklung sich verlangsamt hat.
Du betreibst bereits ESX mit eigenen Scripts
Bleib bei ESX. Wenn du einen funktionierenden Server mit eigenen Ressourcen und Live-Spielerdaten hast, ist eine Migration den Aufwand selten wert. Modernes ESX Legacy performt gut, und der Aufwand, alles zu konvertieren, überwiegt den Nutzen, es sei denn, du baust ohnehin von Grund auf neu.
Du betreibst bereits QBCore
Du musst nicht sofort migrieren. Aber wenn du einen größeren Umbau planst, ist der Wechsel zu QBox der natürliche Weg - er behält das vertraute QBCore-Denkmodell bei, während er die stillgelegten Interna durch gepflegte, moderne ersetzt, und die meisten deiner Scripts kommen über die Kompatibilitäts-Bridge mit.
Die Zusammenfassung in einer Zeile: neuer Server 2026, tendiere zu QBox (oder QBCore für den größeren Guide-Pool); bestehender ESX-Server, bleib bei ESX; bestehender QBCore-Server, wechsle zu QBox, wenn du das nächste Mal einen großen Umbau machst.
Bevor du dich festlegst
Egal, wohin du tendierst, ein paar Prüfungen ersparen dir später Ärger:
- Liste die herausragenden Systeme auf, die dein Server-Konzept braucht, und bestätige, dass starke Scripts für dieses Framework existieren. Das Framework ist für dein konkretes Thema nur so gut wie sein Ökosystem.
- Prüfe, was eingebaut ist gegenüber dem, was du anbauen müsstest. QBCore und QBox liefern mehr ab Werk als Basis-ESX, also weniger bewegliche Teile zu pflegen.
- Entscheide dich früh für dein Inventar. ox_inventory ist der Standard bei QBox und anderswo ein gängiges Add-on, und die Inventar-Wahl wirkt sich auf viele andere Scripts aus.
- Denk an die Migrationskosten. Es gibt kein gemeinsames Script-Format, also behandle das als langfristige Festlegung, nicht als Einstellung, die du später umlegst.
Fazit
Es gibt nicht das eine beste FiveM-Framework, nur das richtige für deine Situation. ESX gewinnt bei der Größe des Ökosystems und bleibt die sinnvolle Wahl für etablierte Server. QBCore ist der vertraute moderne Standard mit mehr Eingebautem als Basis-ESX. QBox ist die Richtung, in die die aktive Entwicklung geht, und kombiniert das QBCore-Modell mit einem gepflegten ox-Fundament und breiter QBCore-Kompatibilität. Stimme das Framework darauf ab, ob du von Grund auf neu startest oder bereits investiert bist, bestätige, dass die Scripts, die du brauchst, dafür existieren, und baue auf einer Basis auf, mit der du für die gesamte Lebensdauer des Servers gut leben kannst.
Wähle einmal, wähle für deinen tatsächlichen Plan und stecke deine Energie in den Server, statt das Fundament immer wieder zu hinterfragen.
