ESX vs. QBCore: Der große Vergleich für FiveM-Serverbetreiber

Die wichtigste Entscheidung vor dem ersten Spieler

Bevor du einen einzigen Spieler auf deinen Server einlädst, musst du eine Entscheidung treffen, die alles andere beeinflusst: das Framework. In der FiveM-Community gibt es zwei klare Favoriten — ESX und QBCore. Diese Wahl bestimmt, welche Scripts du nutzen kannst, wie dein Team entwickelt, wie die Datenbank aussieht und wie einfach oder schwer es wird, den Server langfristig zu pflegen.

Dieser Artikel ist kein oberflächlicher Vergleich. Wir schauen uns beide Frameworks technisch genau an, zeigen konkrete Unterschiede im Code und geben dir am Ende eine klare Entscheidungshilfe — ohne Fanboy-Bias.

Geschichte: Woher kommen ESX und QBCore?

ESX (EssentialMode Extended) geht zurück auf die Anfangszeit des FiveM-Roleplay. Es wurde ursprünglich von Gizz0r auf Basis des EssentialMode-Frameworks entwickelt und später von Arox und verschiedenen Community-Contributors übernommen und erweitert. ESX war über Jahre hinweg der unangefochtene Standard — wer einen RP-Server aufbaute, nutzte ESX. Entsprechend riesig ist das gewachsene Ökosystem an Scripts, Tutorials und Community-Wissen.

Durch dieses Wachstum entstanden auch Probleme: inkonsistente Code-Qualität über verschiedene ESX-Versionen (ESX Legacy, ESX 1.2, ESX 1.1), veraltete Datenbankstrukturen und eine gewachsene Codebasis, die schwer zu standardisieren war.

QBCore entstand als bewusste Reaktion darauf. Kakarot und das QBCommunity-Team begannen ein Framework von Grund auf neu zu entwickeln, mit dem Ziel sauberere Strukturen, ein einheitlicheres API-Design und ein modernes Item-System zu bieten. QBCore wurde schnell populär, insbesondere bei Entwicklern, die Wert auf Code-Qualität legen.

Datenbankstruktur: Wo der tiefste Unterschied liegt

Der vielleicht gravierendste technische Unterschied zwischen ESX und QBCore liegt in der Datenbankstruktur. Das hat direkte Auswirkungen auf Performance, Migration und wie Scripts Daten speichern.

ESX — die users-Tabelle

ESX speichert den Großteil der Spielerdaten in einer einzelnen users-Tabelle. Zusätzliche Daten wie Inventar, Jobs oder Bankkonten liegen in separaten Tabellen. Das Identifier-System basiert auf einem String (meist Steam-ID oder License), der quer durch alle Tabellen als Primärschlüssel genutzt wird.

-- Typische ESX users-Tabelle (vereinfacht)
CREATE TABLE IF NOT EXISTS `users` (
  `identifier`  VARCHAR(60)  NOT NULL,
  `accounts`    LONGTEXT     DEFAULT NULL,  -- JSON: cash, bank, black_money
  `inventory`   LONGTEXT     DEFAULT NULL,  -- JSON: items
  `job`         VARCHAR(50)  NOT NULL DEFAULT 'unemployed',
  `job_grade`   INT(11)      NOT NULL DEFAULT 0,
  `group`       VARCHAR(50)  NOT NULL DEFAULT 'user',
  `position`    TEXT         DEFAULT NULL,
  `skin`        LONGTEXT     DEFAULT NULL,
  PRIMARY KEY (`identifier`)
);

Das JSON-basierte Speichern von Accounts und Inventar direkt in der Tabelle ist ein bekanntes Performance-Problem bei großen Servern. Jedes Mal wenn ein Spieler sein Inventar ändert, wird ein großer JSON-Blob neu geschrieben. Das erzeugt erhebliche Datenbankload bei vielen gleichzeitigen Spielern.

QBCore — strukturierteres Datenmodell

QBCore nutzt eine players-Tabelle mit dem Identifier citizenid — einer generierten alphanumerischen ID statt direkter Steam/License-ID. Inventar-Daten werden üblicherweise in separaten Tabellen mit ox_inventory oder dem nativen QBCore-Inventory gespeichert.

-- QBCore players-Tabelle (vereinfacht)
CREATE TABLE IF NOT EXISTS `players` (
  `id`          INT(11)      NOT NULL AUTO_INCREMENT,
  `citizenid`   VARCHAR(50)  DEFAULT NULL,
  `cid`         INT(11)      DEFAULT NULL,
  `license`     TEXT         DEFAULT NULL,
  `name`        TEXT         DEFAULT NULL,
  `money`       TEXT         DEFAULT NULL,
  `charinfo`    TEXT         DEFAULT NULL,
  `job`         TEXT         DEFAULT NULL,
  `gang`        TEXT         DEFAULT NULL,
  `position`    TEXT         DEFAULT NULL,
  `metadata`    TEXT         DEFAULT NULL,
  PRIMARY KEY (`id`),
  KEY `citizenid` (`citizenid`)
);

Das Metadata-Feld in QBCore ist ein mächtiges Konzept: Es erlaubt das Speichern beliebiger strukturierter Daten pro Spieler, ohne Datenbank-Schema-Änderungen. Scripts können eigene Metadaten hinzufügen ohne neue Tabellen zu erstellen.

Das API-Design: Wie Scripts mit dem Framework kommunizieren

Hier sieht man den philosophischen Unterschied besonders deutlich. Vergleichen wir eine einfache Operation — Geld zum Spieler hinzufügen:

ESX

-- Server-seitig in ESX
local xPlayer = ESX.GetPlayerFromId(source)
if xPlayer then
  xPlayer.addAccountMoney('bank', 5000)
  -- Oder: xPlayer.addMoney(5000)  für Cash
end

QBCore

-- Server-seitig in QBCore
local Player = QBCore.Functions.GetPlayer(source)
if Player then
  Player.Functions.AddMoney('bank', 5000, 'job-payment')
  -- Der dritte Parameter ist ein Reason-String für Logging
end

QBCore hat hier den Vorteil des eingebauten Reason-Parameters — jede Geldtransaktion wird mit einem Grund geloggt, was bei Exploit-Untersuchungen extrem hilfreich ist. ESX bietet das nicht standardmäßig.

Das Item-System: Metadaten machen den Unterschied

Eines der stärksten Features von QBCore ist das moderne Item-System mit Metadaten-Support. Items können individuelle Eigenschaften tragen:

-- QBCore: Item mit Metadaten erstellen
Player.Functions.AddItem('weapon_pistol', 1, false, {
  ammo = 30,
  attachments = {'flashlight', 'suppressor'},
  serial = '7A3F-9B2C',
  quality = 95.5
})

-- Item-Metadaten auslesen
local item = Player.Functions.GetItemByName('weapon_pistol')
print(item.info.serial) -- '7A3F-9B2C'

ESX kann das in der Basis-Version nicht. Für ähnliche Funktionalität braucht man in ESX zusätzliche Scripts wie esx_inventoryhud oder externe Inventory-Systeme. QBCore hat das ab Werk.

Das Ökosystem: Script-Verfügbarkeit im Vergleich

Das ist der Bereich, in dem ESX nach wie vor einen klaren numerischen Vorteil hat — aber QBCore hat massiv aufgeholt.

ESX-Ökosystem

• Jahrzehnte akkumulierter Community-Scripts — die meisten Jobs, Systeme und Features gibt es bereits
• Tausende kostenlose GitHub-Repositories speziell für ESX
• Viele günstige Tebex-Scripts von kleinen Entwicklern, die ESX zuerst supporten
• Große Auswahl an deutschen Scripts für den DACH-Markt
• Sehr viele Tutorials auf YouTube, speziell auf Deutsch

QBCore-Ökosystem

• Das offizielle QBCommunity-Repository bietet bereits einen kompletten Server-Stack: qb-inventory, qb-banking, qb-phone, qb-police, qb-ambulancejob, qb-mechanic u.v.m.
• Viele professionelle Script-Anbieter entwickeln primär oder dual für QBCore
• ox_lib, ox_inventory und das Overextended-Ecosystem sind QBCore-kompatibel und extrem gut optimiert
• Neuere Scripts erscheinen oft zuerst für QBCore

In der Praxis ist die verfügbare Script-Auswahl für beide Frameworks heute ausreichend für jeden Servertyp. Der Qualitätsdurchschnitt liegt bei QBCore-Scripts tendenziell höher, die reine Quantität spricht noch für ESX.

Performance im Detail

Beide Frameworks haben einen ähnlichen Performance-Footprint wenn sauber konfiguriert. Die größten Performance-Unterschiede entstehen durch die Qualität der installierten Scripts, nicht durch das Framework selbst.

Dennoch gibt es Unterschiede:

• State Bags: QBCore nutzt FiveM State Bags für viele Spieler-Daten, was den Event-Overhead reduziert. ESX kommuniziert mehr über klassische Netzwerk-Events.
• oxmysql vs. mysql-async: Beide Frameworks können mit modernen Async-MySQL-Bibliotheken betrieben werden, aber QBCore-Scripts sind öfter von Anfang an auf oxmysql optimiert.
• Zentralisiertes State-Management: QBCore hält mehr Spielerdaten im Server-Memory, was DB-Abfragen reduziert aber RAM-Verbrauch leicht erhöht.

Migration: Der kritische Punkt

Die häufigste Frage bestehender Server-Betreiber: "Wir laufen auf ESX — sollen wir zu QBCore wechseln?" Die ehrliche Antwort: Das ist eine Entscheidung, die nicht leichtfertig getroffen werden sollte.

Eine vollständige Migration bedeutet:

1. Datenbank-Migration: Alle Spielerdaten müssen konvertiert werden. Inventar-Strukturen, Account-Systeme, Job-Daten — alles ist inkompatibel. Community-Tools wie qb-legacy-convert existieren, aber jeder Server ist anders konfiguriert.
2. Script-Austausch: Kein ESX-Script läuft nativ auf QBCore. Jedes Script muss entweder durch eine QBCore-Version ersetzt oder manuell portiert werden. Bei einem Server mit 30+ Scripts kann das Monate dauern.
3. Spieler-Kommunikation: Eine Migration bedeutet für Spieler oft Datenverlust oder Änderungen an ihren Charakteren. Das kostet Community-Vertrauen.
4. Test-Phase: Mindestens 4-6 Wochen auf einem Entwicklungsserver testen, bevor du live gehst.

Empfehlung: Wenn dein Server läuft und Spieler hat — migriere nicht ohne triftigen Grund. Optimiere stattdessen deinen bestehenden Stack. Wenn du neu anfängst, wähle von Anfang an das Framework, das besser zu deinen langfristigen Zielen passt.

Wann ESX die richtige Wahl ist

• Du oder dein Team hat bereits ESX-Erfahrung und gute ESX-Scripts
• Du willst schnell starten mit minimalem Entwicklungsaufwand
• Du benötigst spezifische Scripts, die nur für ESX verfügbar sind
• Dein Budget für Scripts ist begrenzt und ESX bietet mehr günstige Optionen
• Du richtest dich an ein deutschsprachiges Publikum mit ESX-Erfahrung

Wann QBCore die richtige Wahl ist

• Du startest von Null und willst ein modernes, zukunftssicheres Fundament
• Du hast Entwickler im Team, die Wert auf Code-Qualität legen
• Du planst eigene Script-Entwicklung und willst gute Referenz-Implementierungen
• Du willst das ox_lib/ox_inventory-Ecosystem nutzen
• Metadaten auf Items und strukturiertes State-Management sind für deine Server-Vision wichtig

Fazit: Es gibt kein "besser" — nur "besser für dich"

Nach Jahren intensiver Community-Diskussionen ist die nüchterne Wahrheit: Beide Frameworks können exzellente FiveM-Server tragen. Die besten deutschen RP-Server laufen auf beiden. Was entscheidet, ist nicht das Framework allein, sondern die Qualität der Scripts, die Erfahrung des Teams und die Sorgfalt beim Setup.

Wähle ESX wenn du Erfahrung damit hast und schnell starten willst. Wähle QBCore wenn du Wert auf Struktur legst und langfristig eine moderne Codebasis willst. Und egal was du wählst: Investiere in Qualität — nicht im Sinne des teuersten Scripts, sondern im Sinne des am besten gepflegten.