ESX vs QBCore vs QBOX: Technischer Framework-Vergleich 2026

Einführung

Die Wahl eines Frameworks ist die folgenreichste Entscheidung beim Aufbau eines FiveM-Servers. Sie bestimmt, welche Scripts du nutzen kannst, wie deine Entwickler Code schreiben, die Performance-Obergrenze deines Servers und die langfristige Wartbarkeit deines Stacks. 2026 dominieren drei Frameworks die Szene: ESX Legacy, QBCore und QBox. Jedes hat eigene Stärken, Kompromisse und ideale Einsatzgebiete.

Dies ist ein technischer Vergleich — kein Popularitätswettbewerb. Wir behandeln Architektur, API-Design, Performance, Ökosystem-Reife und Zukunftsausblick. Am Ende hast du ein klares Bild, welches Framework zu deiner spezifischen Situation passt.

Framework-Ursprünge und Philosophie

ESX Legacy

ESX (EssentialMode Extended) ist das älteste der drei, ursprünglich um 2017 veröffentlicht. ist der community-gepflegte Fork, der die ursprüngliche aufgegebene Version ersetzt hat. Die Design-Philosophie priorisiert breite Kompatibilität und Einfachheit — ESX-Scripts sind tendenziell geradlinig, server-autoritativ und auch für Anfänger leicht zu modifizieren.

ESX arbeitet mit einem Job-Grade-System, bei dem jeder Spieler einen Job und einen Grad innerhalb dieses Jobs hat. Dieses Modell passt gut zu traditionellen RP-Serverstrukturen und wurde über Jahre der Community-Beiträge verfeinert. Das GitHub-Repository für ESX Legacy ist unter github.com/esx-framework/esx_core verfügbar.

QBCore

QBCore startete 2020 als moderne Alternative zu ESX. Es führte eine stärker opinionated Architektur ein, ein eingebautes Inventarsystem, ein auf Citizen IDs zentriertes Spielerdatenmodell und eine Ressourcenstruktur, die konsistente Muster über Scripts hinweg förderte. QBCore wuchs schnell dank seiner aktiven Community, großen Bibliothek kostenloser Scripts und dem Eindruck eines saubereren Codebases.

QBCores Philosophie ist Kohäsion — Scripts sollen gemeinsamen Mustern folgen, gemeinsame Exports nutzen und sich mit dem Core-Spielerdatenobjekt integrieren. Der Kompromiss ist eine steilere Lernkurve für Entwickler, die von ESX oder Standalone-Scripting kommen.

QBox

ist das neueste der drei, ein Fork von QBCore mit erheblichen architektonischen Verbesserungen. Die Hauptziele waren Performance, Modularität und Korrektheit. QBox hat QBCores monolithischen Core in kleinere, unabhängig aktualisierbare Module aufgeteilt, ox_lib als erstklassige Abhängigkeit übernommen und strengere Muster für die Inter-Ressourcen-Kommunikation eingeführt. Es gibt einen offiziellen für Server, die den Übergang erwägen.

Architektur-Vergleich

Core-Struktur

Aspekt	ESX Legacy	QBCore	QBox
Core-Design	Monolithische Ressource	Monolithischer Core	Modular (aufgeteilte Ressourcen)
Spielerdatenmodell	Job + Grade + Accounts	CitizenID + Job + Gang	CitizenID + Job + Gang (verfeinert)
Inventar	Extern (ox_inventory empfohlen)	qb-inventory (eingebaut)	ox_inventory (eingebaut)
Primärsprache	Lua	Lua	Lua
Server-seitige Autorität	Teilweise	Teilweise	Stark
ox_lib-Abhängigkeit	Optional	Optional	Erforderlich

Datenbank-Ansatz

Alle drei Frameworks nutzen MySQL über oxmysql (der moderne Standard) oder das ältere mysql-async. Das Schema-Design unterscheidet sich erheblich:

• ESX: Spieler gespeichert mit Job, job_grade, Accounts-JSON-Spalte. Metadata lebt in mehreren Spalten.
• QBCore: Spieler gespeichert mit citizenid als Primärschlüssel, charinfo und metadata als JSON-Blobs. Einfacheres Schema, schwerer direkt abzufragen.
• QBox: Ähnlich wie QBCore, aber mit sauberer Trennung zwischen Charakterdaten und Spieler-Metadata. Leichter zu erweitern, ohne Core-Tabellen anzufassen.

API-Design und Entwicklererfahrung

ESX-API

ESX exponiert seine API über ein Shared Object, das über Exports abgerufen wird:

local ESX = exports['es_extended']:getSharedObject()
local xPlayer = ESX.GetPlayerFromId(source)
xPlayer.addMoney(500)
xPlayer.setJob('police', 3)

Die API ist prozedural und leicht nachzuvollziehen. Jeder Funktionsaufruf ist explizit. Der Nachteil ist Verbosität — häufige Muster erfordern mehrere API-Aufrufe, und Fehlerbehandlung liegt komplett beim Script-Entwickler.

QBCore-API

QBCore nutzt ein ähnliches Export-Muster, zentriert aber alles um das Spielerdatenobjekt:

local QBCore = exports['qb-core']:GetCoreObject()
local Player = QBCore.Functions.GetPlayer(source)
Player.Functions.AddMoney('cash', 500)
Player.Functions.SetJob('police', 3)

Das Namespacing (QBCore.Functions, Player.Functions) ist strukturierter, erzeugt aber tief verschachtelte Aufrufketten. QBCore standardisiert auch die gemeinsame Konfiguration über QBCore.Shared-Tabellen, was Duplikation über Scripts hinweg reduziert.

QBox-API

QBox hat die API refaktoriert, um ox_libs Klassensystem und direkte Exports statt eines globalen Core-Objekts zu nutzen. Das reduziert Kopplung und ermöglicht Tree-Shaking — Ressourcen laden nur, was sie brauchen. Die bietet auch standardisierte UI-Komponenten (Fortschrittsbalken, Kontextmenüs, Benachrichtigungen), die die Notwendigkeit eliminieren, UI-Bibliotheken in einzelnen Scripts mitzuliefern.

-- QBox nutzt direkte Modul-Imports
local player = require '@qbox-core.modules.player'
local xPlayer = player.getPlayer(source)
xPlayer.addMoney('cash', 500)

Performance-Benchmarks

Metrik	ESX Legacy	QBCore	QBox
Core-Ressource-Tickrate	~1ms Durchschnitt	~0,8ms Durchschnitt	~0,4ms Durchschnitt
Spieler-Beitrittszeit	Mittel	Mittel	Schnell
Speicherbedarf (Core)	Höher	Mittel	Niedriger (modular)
Script-Ökosystem-Overhead	Variiert stark	Moderat	Niedriger (ox_lib geteilt)
Datenbank-Query-Muster	Legacy (teils ineffizient)	Modern (oxmysql)	Modern (oxmysql, optimiert)

QBoxs modulares Design bedeutet, dass nur geladene Module Speicher und Tick-Zeit verbrauchen. Auf einem Server mit 80+ Ressourcen wird dieser Unterschied messbar. ESX und QBCore sind jedoch beide stabil und können Server mit hoher Spielerzahl betreiben — der Performance-Unterschied wird erst bei Skalierung oder vielen gleichzeitigen Spielern bedeutsam.

Script-Ökosystem-Größe

Kategorie	ESX	QBCore	QBox
Kostenlose Scripts (GitHub)	Am größten	Sehr groß	Wachsend
Bezahlte Scripts (Tebex)	Am größten	Sehr groß	Wächst schnell
Native Kompatibilität	Hoch	Hoch	Mittel (etwas Portierung nötig)
ox_lib native Unterstützung	Teilweise	Teilweise	Vollständig
Script-Qualitäts-Untergrenze	Variabel	Variabel	Höher (strengere Muster)

ESX hat die größte absolute Script-Anzahl aufgrund seines Alters. Viele ESX-Scripts sind jedoch ungepflegte Forks aus 2018–2020. QBCores Ökosystem wird konsistenter gewartet. QBox hat das kleinste Ökosystem, aber die höchste durchschnittliche Script-Qualität, und die Anzahl nativer QBox-Ressourcen wächst 2026 rapide.

Inventarsystem-Integration

Die Inventar-Integration beeinflusst das gesamte Server-Feeling — wie Items gespeichert werden, wie Scripts mit Spielerinventaren interagieren und die Performance hochfrequenter Item-Operationen. Siehe unseren dedizierten für einen vollständigen Vergleich.

• ESX: Standard-Inventar ist einfach; die meisten Server ersetzen es durch ox_inventory oder lj-inventory
• QBCore: Liefert qb-inventory mit; viele Server wechseln zu ox_inventory für bessere Performance
• QBox: Liefert ox_inventory nativ mit; keine Migration nötig

Migrationspfade

ESX zu QBCore

Die häufigste Server-Migration. Spielerdaten erfordern ein Migrationsscript, um Accounts in QBCores Inventarformat zu konvertieren. Die meisten Scripts erfordern eine framework-spezifische Version oder einen Fork. Rechne mit 2–4 Wochen Entwicklungszeit für eine vollständige Server-Stack-Migration.

QBCore zu QBox

Eine chirurgischere Migration. QBox ist ein QBCore-Fork, daher sind die Spielerdaten-Schemata ähnlich. Die Hauptarbeit liegt im Aktualisieren von Ressourcen-Imports, Ersetzen qb-spezifischer UI-Aufrufe durch ox_lib-Äquivalente und Auditing von Scripts auf QBox-Kompatibilität. Siehe den offiziellen .

ESX zu QBox

Die schwierigste Migration. Im Wesentlichen den Server von Grund auf mit einem neuen Datenmodell neu aufbauen. Nur empfehlenswert bei einem kleinen, frisch gewischten Server.

Welches Framework solltest du wählen?

Szenario	Empfehlung
Erster Server, Anfänger-Entwickler	ESX Legacy
Etablierter Server, große kostenlose Script-Bedürfnisse	QBCore
Neuer Server, Performance-Fokus, moderne Muster	QBox
Großes Team, langfristige Wartbarkeit als Priorität	QBox
Bestehender ESX-Server, keine Migration	ESX Legacy (behalten, optimieren)
Bestehender QBCore-Server, Upgrade erwägen	QBox (migrieren)

Deinen Server einrichten

Unabhängig davon, welches Framework du wählst, erfordert eine solide Basis mehr als nur den Core. Siehe unseren und unsere Übersicht der für ein vollständiges Bild, wie ein produktionsreifer Server-Stack aussieht.

Für Premium-Scripts, die vorkonfiguriert und mit allen drei Frameworks kompatibel sind, stöbere im .

Zukunftsausblick (2026 und darüber hinaus)

ESX Legacy wird aufgrund der installierten Basis-Trägheit noch Jahre lang nach absoluter Serverzahl dominant bleiben. QBCore wird weiterhin starke Community-Aktivität und Script-Veröffentlichungen sehen. QBox positioniert sich als Framework der Wahl für neue Projekte — seine architektonischen Entscheidungen stimmen mit der Richtung überein, in die sich die FiveM-Entwickler-Community bewegt: modulare Ressourcen, ox_lib als gemeinsamer Standard und strengere Server-Autoritätsmuster.

Der Trend über alle drei Frameworks ist die Konvergenz hin zu ox_lib für UI und Utility-Funktionen. Wenn du heute einen neuen Server startest, gibt dir QBox den zukunftssichersten Ausgangspunkt.

FAQ

Kann ich QBCore-Scripts auf einem QBox-Server nutzen?

Viele QBCore-Scripts funktionieren auf QBox mit kleineren Anpassungen, da QBox ein Fork ist. Die Hauptänderungen betreffen das Aktualisieren von Import-Pfaden und das Ersetzen von qb-spezifischen UI-Aufrufen durch ox_lib-Äquivalente. Prüfe die GitHub-Issues jedes Scripts auf QBox-Kompatibilitätshinweise vor der Migration.

Ist ESX 2026 tot?

Nein. ESX Legacy wird aktiv gepflegt und hat die größte installierte Basis aller FiveM-Frameworks. Tausende Server nutzen ESX erfolgreich 2026. Es ist nicht die modernste Wahl für neue Projekte, aber weit davon entfernt, tot zu sein.

Beeinflusst die Framework-Wahl die Spielererfahrung?

Direkt weniger als man denkt — Spieler erleben die Scripts, die auf dem Framework aufbauen, nicht das Framework selbst. Indirekt beeinflusst die Framework-Wahl, welche Scripts du installieren kannst, wie poliert diese sind und die Server-Performance unter Last — alles Dinge, die Spieler bemerken.

Was ist ox_lib und warum benötigt QBox es?

ox_lib ist eine gemeinsame Ressourcen-Bibliothek, die vom Overextended-Team gepflegt wird. Sie bietet UI-Komponenten (Fortschrittsbalken, Kontextmenüs, Radialmenüs, Benachrichtigungen), Utility-Funktionen und klassenbasierte OOP-Muster für Lua. QBox hat es als erstklassige Abhängigkeit definiert, um das UI zu standardisieren und doppelten Code im Ökosystem zu eliminieren. Erfahre mehr im .