QBCore vs ESX Legacy vs Qbox: which framework to pick for a FiveM server in 2026
QBCore vs ESX Legacy vs Qbox: script support, install difficulty, performance, migration cost, and what to pick for a new server or a 2,000-player city.
"QBCore or ESX" has no single answer, but for most new servers the right answer is clearer than the arguments suggest. The deciding factor is not which framework is better written; it is what the scripts you will buy support and what your team already knows.
Short version
| ESX Legacy | QBCore | Qbox | |
|---|---|---|---|
| Script support | Widest, especially in Thai and SEA markets | Wide, especially western releases | Small, relies on QBCore compatibility |
| Player data model | Flat: accounts / inventory / loadout / job | Richer: PlayerData.metadata, charinfo, gang | Like QBCore, refined |
| Multi-character | Addon (esx_multicharacter) | Built in | Built in |
| Default inventory | ox_inventory (popular) or built in | qb-inventory / ox_inventory | ox_inventory |
| Install difficulty | Easy: core + oxmysql | Medium: many qb-* resources bundled with the core | Medium |
| Project direction | Stable, slow updates (1.13.x) | Several core maintainers moved to Qbox in 2023–24 | New, fast moving, still changing |
| Best for | Most servers, beginner to mid teams | Servers built on western QB script bundles | Teams that track upstream and want the newest stack |
ESX Legacy
Its strength is the ecosystem: most script shops support ESX first, the data model is flat, the database tables are standard (users, items, jobs), problems are easy to debug and help is easy to find.
Its weakness is the upstream 1.13.x core with long-standing gaps: saves on disconnect only, corrupt coordinates on disconnect, leaking callbacks, nothing against pre-restart dupes. Those are fixed by swapping the core for ESX Legacy Core — X3D Build (free, drop-in); details in the ESX Legacy guide.
QBCore
Its strength is built-in features: multi-character, per-player metadata, gangs, and many western scripts target QBCore first.
Its weakness is a core shipped with dozens of tightly coupled qb-* resources, so changing one affects others, and the migration of several core maintainers to Qbox since 2023 leaves the long-term direction unclear.
Qbox
A QBCore fork by former QBCore maintainers, standardised on ox_lib / ox_inventory / ox_target, cleaner code and better performance, but still new and changing often. Few scripts target Qbox directly; most rely on the QBCore bridge, which breaks when Qbox changes an API.
What a new server should pick
ESX Legacy in nearly every case, for one heavy reason: the scripts you will buy, the developers you will hire and the people who answer in Discord are mostly on the ESX side. You can launch in two weeks on ESX; QBCore/Qbox cost extra time hunting compatibility.
Pick QBCore if the core scripts you want (a western job/heist bundle, say) exist only as QB versions and your team already knows QB.
A 1,000–2,048-player city: which framework?
At this scale the framework name matters less than people think. ESX Legacy, QBCore and Qbox all run on OneSync Infinity up to 2,048 slots. Large servers do not fall over because of the core; they fall over because of resources written for 64 players: loops over every player every tick, SQL on every purchase, events that trust client values. Decide on these instead:
- What your hired developers know. A two-thousand-player city writes its core systems (HUD, inventory, jobs, economy) in-house anyway, so the framework your team is fluent in matters more than the catalog of ready-made scripts
- The stack around the core. ox_inventory and ox_lib work on both ESX Legacy and Qbox, so both sit on the same foundation for the heaviest parts (inventory and UI)
- Saving and the pre-restart economy lock. Whatever the framework, the core must save in rounds, not on every action, and close the dupe window before a txAdmin restart (ESX Legacy Core — X3D Build does both)
- Switching after launch means relaunching the city. Expensive at 64 players, close to impossible at two thousand, because tens of thousands of player records have to be converted
The straight answer: ESX Legacy if your team knows ESX and wants the existing Thai script ecosystem; Qbox if your team writes nearly everything itself and wants the ox stack as the standard. If you are heading the QB way, start with Qbox rather than classic QBCore, since it was designed around ox_lib/ox_inventory from the start. Whichever you choose, every script must pass the vetting rules in the 2,000-player section of the server budget post before it goes into the city.
Can you switch later?
Yes, but it is expensive: different tables (users vs players), different inventory structures, every script swapped for the other version. In practice it is a new server. Deciding once before launch matters more than people expect.
Why X3D builds for ESX and standalone only
We chose to make every script work deeply with ESX Legacy (server-side checks, automatic inventory detection, tested on a live server) instead of thin bridges for every framework. Scripts that do not need a core, such as X3D Environment, X3D Loading Screen, X3D Lockpick and X3D Safe Cracking, are standalone and run on any framework including QBCore.
FAQ
Is ESX slower than QBCore? Upstream 1.13.x has linear lookups, which the X3D Build turns into O(1). In practice performance depends on the scripts you install more than the core.
Does ox_inventory work on all three? Yes; ox_inventory supports ESX, QBCore and Qbox.
What do I need to open a server and what does it cost? Read what scripts you need to open a FiveM server.