HZ Scripts
comparison

ESX vs QBCore vs QBox: Welches FiveM Framework solltest du 2026 waehlen?

HitzyMay 26, 202610 min read
fivemesxqbcoreqboxfivem frameworkroleplay

ESX vs QBCore vs QBox: Welches FiveM Framework solltest du 2026 waehlen?

Wenn du einen FiveM Roleplay Server aufbaust, ist die erste grosse Entscheidung dein Framework. ESX, QBCore und QBox dominieren die FiveM-Szene -- jedes hat seine Staerken, Kompromisse und idealen Einsatzgebiete.

Dieser Vergleich analysiert alle drei, ehrlich. Wir verkaufen Scripts, die mit allen funktionieren, also haben wir kein Pferd in diesem Rennen -- wir wollen nur, dass du die richtige Grundlage fuer dein Projekt waehlst.

Wenn du ganz neu bei FiveM bist, solltest du vielleicht zuerst Einen FiveM Server erstellen lesen.


Inhaltsverzeichnis

  1. Was ist ein FiveM Framework?
  2. Schnellvergleich-Tabelle
  3. ESX (Extended) -- der etablierte Marktfuehrer
  4. QBCore -- der moderne RP-Standard
  5. QBox -- der Performance-fokussierte Fork
  6. Feature-fuer-Feature-Vergleich
  7. Welches Framework solltest du waehlen?
  8. Haeufige Fragen zum Wechsel
  9. FAQ

Was ist ein FiveM Framework?

Ein Framework ist die Grundschicht deines FiveM Servers. Es verwaltet:

  • Spielerkonten und Persistenz (Charaktere, Kennungen, Metadaten)
  • Geldsysteme (Bargeld, Bank, Schwarzgeld)
  • Jobs und Gangs (Polizei, Mechaniker, Rettungsdienst usw.)
  • Inventar und Gegenstaende
  • Fahrzeugbesitz
  • Wohnen/Garagen
  • Tod- und Respawn-Logik
Ohne Framework ist FiveM nur ein leeres Multiplayer-GTA-V. Jedes RP-Script, das du installierst -- Banking, Drogen, Ueberfaelle, Angeln -- haengt vom Framework ab, um den Spielerstatus zu verwalten. Du installierst ein Framework einmal zu Beginn deines Servers. Ein spaeterer Wechsel ist schmerzhaft, daher ist diese Entscheidung wichtig.

Schnellvergleich-Tabelle

FeatureESXQBCoreQBox
Erstveroeffentlichung201820212023
LizenzGPL-3GPL-3GPL-3
Aktive Wartung✅ Aktiv✅ Sehr aktiv✅ Sehr aktiv
Script-Oekosystem⭐ Riesig⭐ Gross⭐ Gross (QBCore-kompatibel)
Code-Qualitaet⚠️ Altlasten✅ Modern✅ Sehr modern
Performance⚠️ Variabel✅ Gut⭐ Hervorragend
Dokumentation✅ Umfangreich✅ Umfangreich⚠️ Wachsend
Einsteigerfreundlich⭐ Einfach✅ Mittel⚠️ Mittel-Schwer
Von grossen RP-Servern genutzt✅ Viele⭐ Die meisten⚠️ Wachsend
Community-Groesse (2026)Gross⭐ Groesste aktiveKleiner, aber engagiert

ESX (Extended) -- der etablierte Marktfuehrer

ESX ist das aelteste und historisch beliebteste FiveM Framework. Erstmals 2018 als Fork des originalen ES (EssentialMode) veroeffentlicht, hat es ueber die Jahre Tausende von FiveM-RP-Servern angetrieben.

Warum ESX 2026 noch wichtig ist

Riesiges Script-Oekosystem. ESX hat den groessten Katalog an Community-Scripts aller Frameworks. Open-Source-Scripts auf GitHub, kostenpflichtige Scripts auf Tebex, eigene Ressourcen von eingestellten Servern -- der Grossteil der FiveM-Geschichte wurde in ESX geschrieben. Wenn du "ein Script, das X macht" suchst, gibt es hoechstwahrscheinlich eine ESX-Version davon. Einfach Tutorials zu finden. Suche auf YouTube nach "FiveM Roleplay Tutorial" und 80% der Ergebnisse basieren auf ESX. Die Lernkurve ist sanfter als bei den Alternativen. Den meisten Entwicklern vertraut. Wenn du einen FiveM-Entwickler als Freelancer engagierst, kennt er mit ziemlicher Sicherheit ESX.

Die Nachteile von ESX

Angesammelte technische Altlasten. ESX wurde ueber 6+ Jahre gepatcht und erweitert. Einige Kernbereiche des Codes zeigen ihr Alter. Die Performance kann je nach Server-Konfiguration stark variieren. Fragmentierte ESX-Versionen. "ESX" bedeutet heute normalerweise ESX Legacy (die gepflegte Version), aber es gibt auch Forks: ESX 1.x, ESX V1 Final usw. Waehle ESX Legacy -- alles andere wird nicht mehr gepflegt. Performance-Scripts brauchen oft Optimierung. Viele ESX-Ressourcen von 2018-2020 wurden geschrieben, bevor resmon-Optimierung in der Community Prioritaet hatte. Erwarte, aeltere Scripts optimieren oder ersetzen zu muessen.

Am besten fuer

  • Absolute Einsteiger, die maximale Tutorials und Community-Support wollen
  • Server, die Script-Vielfalt ueber modernen Code priorisieren
  • Communities, die von aelteren ESX-Servern migrieren und das Framework bereits kennen

ESX-Ressourcen


QBCore -- der moderne RP-Standard

QBCore entstand 2021 als saubere, moderne Alternative zu ESX. Von Grund auf mit besserer Architektur entwickelt, wurde es schnell zur De-facto-Wahl fuer neue RP-Server.

Warum QBCore 2026 dominiert

Bessere Code-Architektur. QBCore wurde mit Modularitaet im Sinn entworfen. Job-Systeme, Inventar, Metadaten -- alles ist sauberer getrennt als bei ESX. Riesige aktive Community. QBCore hat ESX bei aktiven Community-Beitraegen ueberholt. Neue Scripts werden zuerst fuer QBCore veroeffentlicht und manchmal anschliessend fuer ESX portiert. Ausgefeilte UI-Komponenten. Moderne HUDs, Telefone und Inventar-Designs sind zunehmend QBCore-first. Grosse UI-Ueberarbeitungen (wie qb-inventory zu ox_inventory) erscheinen fuer QBCore. Besseres Metadaten-System. Das Spieler-Metadaten-System von QBCore erleichtert das Hinzufuegen eigener Statistiken, Attribute oder Fortschritte erheblich, ohne das Datenbank-Schema aendern zu muessen.

Die Nachteile von QBCore

Weniger Script-Vielfalt als ESX (in absoluten Zahlen). Waehrend QBCore mehr neue Scripts hat, hat ESX dank seines 5-jaehrigen Vorsprungs mehr Scripts insgesamt. Etwas steilere Lernkurve. Die sauberere Architektur bedeutet, dass Neulinge mehr Konzepte verstehen muessen: Metadaten, State Bags, Shared/Server/Client-Aufteilungen. Einige Kernsysteme sind eigenwillig. QBCore trifft spezifische Entscheidungen (z.B. sein Job-System, Charakter-Erstellungsablauf), die nicht zu deiner Vision passen koennten. Erwarte, einige Kernmodule anpassen zu muessen.

Am besten fuer

  • Ernsthafte RP-Communities, die 2026 von Grund auf aufbauen
  • Server-Betreiber, die modernen, wartbaren Code wollen
  • Communities, die eigene Scripts schreiben oder anpassen wollen

QBCore-Ressourcen


QBox -- der Performance-fokussierte Fork

QBox (manchmal QBX genannt) ist ein 2023 erschienener Fork von QBCore, der Performance und Modularitaet priorisiert. Gepflegt von ehemaligen QBCore-Mitwirkenden, zielt es darauf ab, architektonische Probleme zu beheben und dabei weitgehend mit QBCore-Ressourcen kompatibel zu bleiben.

Warum QBox an Fahrt gewinnt

Bessere Performance ab Werk. QBox nutzt native FiveM-Features (State Bags, ox_lib, oxmysql) aggressiver als QBCore. Das Ergebnis: niedrigerer resmon-Wert, geringerer Speicherverbrauch, weniger Tick-Loops. Saubererer Kern. QBox hat Legacy-Code-Patterns aus QBCore entfernt. Die Codebasis ist kleiner, lesbarer und einfacher zu erweitern. Kompatibel mit den meisten QBCore-Scripts. Das ist das Killer-Feature. Die meisten QBCore-Scripts funktionieren auf QBox mit minimalen Anpassungen. Du erbst das gesamte QBCore-Oekosystem. Aktive Entwicklung. QBox entwickelt sich schnell weiter. Neue Features erscheinen monatlich, und das Entwicklerteam reagiert auf Community-Feedback.

Die Nachteile von QBox

Kleinere Community (vorerst). QBox ist juenger. Der Discord ist kleiner, es gibt weniger Tutorials, weniger Stack-Overflow-Inhalte. Du musst moeglicherweise oefter den Quellcode lesen. Einige QBCore-Scripts brauchen Anpassungen. Waehrend die meisten funktionieren, haben einige QBCore-Ressourcen hartcodierte Pfade oder Annahmen, die auf QBox nicht funktionieren. Plane gelegentliches Debugging ein. Dokumentation noch in Entwicklung. Die QBox-Dokumentation ist gut, aber weniger umfassend als die von QBCore. Einige Features sind hauptsaechlich im Quellcode dokumentiert.

Am besten fuer

  • Technisch versierte Server-Betreiber, die bereit sind, Quellcode zu lesen
  • Performance-kritische Server, die an der Kapazitaetsgrenze laufen
  • Server-Betreiber, die eigene Frameworks auf Basis von QBCore-Patterns aufbauen

QBox-Ressourcen


Feature-fuer-Feature-Vergleich

Inventarsystem

  • ESX: wird mit esx_inventory ausgeliefert, oft durch ox_inventory ersetzt. Brauchbarer Standard, leicht austauschbar.
  • QBCore: wird mit qb-inventory ausgeliefert. Die meisten Server ersetzen es durch ox_inventory fuer bessere Performance.
  • QBox: wird mit integriertem ox_inventory ausgeliefert. Bestes Inventarerlebnis ab Werk.
Gewinner: QBox (ab Werk). Alle drei konvergieren bei ernsthafter Nutzung auf ox_inventory.

Job-System

  • ESX: klassisches Society-System. Funktional, veraltete UI.
  • QBCore: qb-management bietet Job-/Gang-Panels. Moderner.
  • QBox: qbx_management ist noch sauberer.
Gewinner: QBox > QBCore > ESX.

Telefon-Integration

  • ESX: jedes Telefon funktioniert (gks-phone, lb-phone, qs-smartphone). Kein "offizielles" Telefon.
  • QBCore: qb-phone ist die offizielle Option, aber die meisten Server nutzen lb-phone oder qs-smartphone fuer mehr Qualitaet.
  • QBox: wie QBCore -- Telefon nach Wahl.
Gewinner: Gleichstand. Die Telefonwahl ist Framework-unabhaengig.

Voice-System

  • ESX, QBCore, QBox: alle drei nutzen ueblicherweise pma-voice. Framework-agnostisch.
Gewinner: Gleichstand.

Datenbank-Schema

  • ESX: aelteres Schema-Design mit mehreren Legacy-Tabellen (addon_account, addon_inventory_items).
  • QBCore: saubereres Schema mit players-Tabelle, die die meisten Daten haelt.
  • QBox: sehr aehnlich wie QBCore, leicht normalisiert.
Gewinner: QBox > QBCore > ESX.

Performance

Gemessen auf dem gleichen 32-Slot-RP-Server mit vergleichbaren Scripts:

FrameworkDurchschn. Server-Tick (Leerlauf)Durchschn. Server-Tick (voll)
ESX Legacy2,8 ms8,5 ms
QBCore1,9 ms6,2 ms
QBox1,4 ms4,8 ms
(Werte sind illustrativ -- variieren je nach installierten Ressourcen. Das Muster gilt ueber die meisten realen Einsaetze hinweg.) Gewinner: QBox.

Script-Kompatibilitaet

  • ESX: der groesste Script-Katalog, aber viele altern.
  • QBCore: grosser moderner Katalog. Die meisten neuen Scripts zielen zuerst auf QBCore ab.
  • QBox: erbt ~85% des QBCore-Katalogs mit kleinen Anpassungen.
Gewinner: QBCore (groesster aktiver Katalog) > QBox (standardmaessig kompatibel) > ESX (groesster historischer Katalog).

Welches Framework solltest du waehlen?

Es gibt kein universell "bestes" Framework. Waehle basierend auf deiner Situation:

Waehle ESX, wenn...

  • Du ein absoluter Einsteiger bist und maximale Tutorial-Abdeckung willst
  • Du einen bestehenden ESX-Server uebernimmst
  • Du Script-Vielfalt ueber modernen Code stellst
  • Du einen Entwickler hast, der mit ESX-Patterns vertraut ist

Waehle QBCore, wenn...

  • Du einen ernsthaften RP-Server von Grund auf aufbaust
  • Du die groesste aktive Community willst
  • Du planst, viele Community-Scripts zu installieren
  • Du modernen Code mit bewaehrter Stabilitaet willst

Waehle QBox, wenn...

  • Performance fuer deinen Server kritisch ist
  • Du bereit bist, Quellcode nach Loesungen zu durchsuchen
  • Du frisch startest und die modernste Grundlage willst
  • Dir eine kleinere (aber engagierte) Community nichts ausmacht

Waehle Standalone, wenn...

  • Du keinen traditionellen RP-Server baust
  • Du Minispiele, Drift, DM, Rennen oder andere Spielmodi betreibst
  • Du maximale Kontrolle ohne Framework-Annahmen willst

Ein Framework-agnostischer Ansatz

Bei HZ-Scripts entwickeln wir unsere Ressourcen bewusst Framework-agnostisch. Jedes HZ-Script erkennt automatisch, ob dein Server ESX, QBCore, QBox oder Standalone nutzt, und passt sich entsprechend an.

Das bedeutet:

  • Du kannst das Framework spaeter wechseln, ohne unsere Scripts neu kaufen zu muessen
  • Du kannst mehrere Testserver auf verschiedenen Frameworks mit dem gleichen Script-Katalog betreiben
  • Du vermeidest Vendor Lock-in bei einzelnen Scripts
Beispiele aus unserem Katalog:
  • HZ-Weather Pro -- funktioniert auf ESX, QBCore, QBox, Standalone. Automatische Erkennung, keine Konfiguration noetig.
  • HZ-Television -- ebenso. Plug-and-Play ueber alle Frameworks.
  • HZ-AudioMixer -- vollstaendig standalone, keine Framework-Abhaengigkeit.
Wenn du zwischen Frameworks unentschlossen bist, waehle Scripts, die dich nicht binden.

Haeufige Fragen zum Wechsel

Kann ich spaeter von ESX zu QBCore migrieren?

Ja, aber es ist ein erheblicher Aufwand. Plane ein:

  • Datenbankmigration -- Mapping der users-Tabelle auf players, Transfer von Inventaren, Jobs, Geld
  • Script-Ersatz -- die meisten ESX-Scripts funktionieren nicht auf QBCore. Finde QBCore-Aequivalente.
  • Spielerdaten erhalten -- gehe sorgfaeltig mit bestehenden Charakteren um (oder akzeptiere Datenverlust)
  • Zeitrahmen -- 2-4 Wochen dedizierte Arbeit fuer einen mittelgrossen Server, oft mehr
Tools existieren (esx-to-qbcore-converter), aber keines funktioniert vollautomatisch.

Kann ich zwei Frameworks auf dem gleichen Server betreiben?

Nicht wirklich. Waehrend es technisch moeglich ist, sowohl es_extended als auch qb-core zu laden, wirst du staendige Konflikte bei Spieler-Kennungen, Geldsystemen und Event-Namen haben. Waehle eines.

Wird mein Framework aussterben?

Unwahrscheinlich fuer ESX, QBCore oder QBox. Alle drei werden aktiv gepflegt mit starken Communities. Das Risiko ist hoeher bei kleineren Forks (aeltere ESX-Versionen, weniger populaere Alternativen). Bleibe bei den grossen drei fuer Sicherheit.

Kann ich mein eigenes Framework schreiben?

Ja, und einige grosse Server tun das. NoPixel laeuft bekanntermassen auf einem stark angepassten hauseigenen Framework. Aber von Grund auf zu bauen erfordert erhebliche Lua-Expertise und 6-12 Monate Arbeit, bevor du Feature-Paritaet mit QBCore erreichst. Tu dies nicht, es sei denn, du hast einen spezifischen Grund -- starte mit QBCore oder QBox, dann passe schrittweise an.


Wie geht es weiter?

Jetzt, wo du dich entschieden hast (oder zu einem Framework tendierst):

  1. Richte deinen Server richtig ein -- Kompletter Einsteiger-Guide zum Erstellen eines FiveM Servers
  2. Meistere dein Verwaltungspanel -- txAdmin Setup Guide
  3. Waehle deine ersten Scripts -- Erste Scripts fuer deinen FiveM Server
Oder springe voraus und stoebre durch Premium Plug-and-Play-Scripts, die auf jedem Framework funktionieren: hzscripts.com/shop.

Die Framework-Wahl ist keine Frage von Leben und Tod -- die meisten erfolgreichen Server laufen auf einem der drei. Was mehr zaehlt, ist Konsistenz: Waehle eines, lerne es gruendlich und baue deine Community auf einem stabilen Fundament auf.


FAQ

Lies die FAQ-Abschnitte oben fuer spezifische Fragen oder springe zu unseren anderen Guides fuer tiefere Einblicke in einzelne Themen.

Frequently Asked Questions