FiveM: ESX vs QBCore

You have the server running, txAdmin is asking which recipe to deploy, and the list offers ESX Legacy, QBCore and Qbox. It looks like a preference. It is not. Whichever you click decides your database schema, which scripts you can buy off the shelf, which Discord you will be asking for help in at two in the morning, and how much it will cost you to change your mind in a year.

The usual way people decide is the worst one: they pick whichever framework the tutorial they happened to watch was using. The second-worst is arguing about which is better, which is not a question with an answer. The question with an answer is which one carries the scripts you intend to run and matches how much Lua you are personally willing to write.

1. What a framework actually is, and when you do not need one

Strip the marketing away and a FiveM framework is three things: a database schema for players, a set of server exports and events that other resources call, and a bundle of starter resources that use both. It gives you persistent identity, money, jobs and grades, inventory, and a shared vocabulary so that a shop script written by a stranger knows how to take a thousand dollars off a player.

Which means a large number of servers do not need one at all. Racing, drift, freeroam, deathmatch, zombie survival, car meets — anything where a player's state does not have to survive a disconnect — runs perfectly well on standalone resources with no framework underneath. Installing ESX to run a drift server adds a database, a login flow and a maintenance burden to buy nothing. If you are still deciding what kind of server you are building at all, choosing a FiveM roleplay server in 2026 is a useful look at what the scene actually contains, and the live picture is in the FiveM listings and the measured FiveM statistics.

If it is roleplay, you need a framework. Writing your own is a two-year project that ends with a worse ESX.

2. The two schemas, which is genuinely the whole argument

Open the SQL each ships and the philosophical difference is right there in the column list.

ESX creates a users table keyed on identifier — the player's Rockstar licence. Character data lives in flat, typed columns: firstname, lastname, dateofbirth, sex, height, with job as a varchar(20) defaulting to unemployed and job_grade as an integer beside it. Money sits in an accounts blob, items in inventory, weapons in loadout.

QBCore creates a players table keyed on citizenid — a generated per-character string — with license as a separate indexed column. Almost everything else is JSON in a text field: charinfo, money, job, gang, position, metadata.

That difference is not cosmetic. Because QBCore keys on the character rather than the account, multiple characters per licence is the native case, and qb-multicharacter ships as part of the standard install. ESX bolts it on, though esx_multicharacter now ships inside esx_core alongside es_extended, esx_identity, esx_inventory, esx_skin and the menu resources, so this is much less of a gap than it was. Conversely, ESX's typed columns mean you can write a sane SQL query against jobs; QBCore's JSON means you are unpacking blobs to answer questions your admin panel should be able to answer directly.

3. Where the two projects actually stand in 2026

ESX Legacy is the busier project by a wide margin. Its esx_core repository shipped 1.13.5 in late May 2026 and reached 1.15.2 by early September — six tagged releases in roughly fifteen weeks, with real work in them rather than version bumps. One caution: search results are full of forks whose readme still says Official Repo For ESX-Legacy. The maintained one is esx-framework/esx_core.

QBCore is not dead, which is the claim you will see repeated, but it has slowed and it has moved. qb-core relocated from the qbcore-framework organisation to a new qbcore-fivem one in late August 2026, with documentation now at qbcore.org/docs. Real fixes landed through spring 2026 — a race condition that produced ghost characters on deletion, command middleware, paycheque threading, client loop CPU reductions — but the tempo is a few commits in a good month and none in several others, against an ESX tag roughly every fortnight.

And there is a third name you cannot sensibly ignore. Qbox (qbx_core) was started in September 2022 as a successor to qb-core, and its own readme is explicit that a bridge layer gives backwards compatibility with most QB resources for no effort. It hard-depends on oxmysql, ox_lib and ox_inventory, and ships multicharacter, multi-job and gang support, a queue system and persistent player vehicles in the core. All three are in Cfx.re's official txAdmin recipe list, so all three are one click away in the deployer.

4. The inventory choice decides more than the framework does

This is the part nobody tells first-time owners. In practice the inventory resource is the single most invasive dependency on a roleplay server: shops, crafting, stashes, vehicle storage, weapons-as-items and half your job scripts all bind to it.

The one the ecosystem has largely standardised on is ox_inventory — Qbox hard-depends on it, ESX supports it — and its readme lists exactly four supported frameworks: ox_core, esx, qbox and nd_core. QBCore is not on that list. QBCore servers run qb-inventory, which is maintained and works, but the ecosystem's centre of gravity has drifted somewhere QBCore is not.

That single fact explains most of the migration traffic in the scene better than any argument about code quality.

5. The script market is one market with two labels

Browse the Cfx.re releases board on any given day and the pattern is immediate: the same release is tagged esx and qbcore, increasingly qbox as well, because sellers have no interest in halving their market. Compatibility across ESX and QBCore is close to table stakes for a commercial script now. The idea that one framework has vastly more scripts than the other was true years ago and is largely no longer the deciding factor.

What is the deciding factor is that most of what is posted is paid, and paid means escrowed. Cfx.re's asset escrow encrypts Lua, YFT, YDD and YDR files; the resource is delivered through Tebex, tied to your Cfx.re account, and refuses to start elsewhere with an entitlement error. Since Keymaster was fully retired on 1 December 2025, keys, assets and subscriptions all live in the Cfx.re Portal.

You are not choosing a framework. You are choosing a database schema, the set of scripts you can buy without hiring anybody, and a migration bill you will pay later if you get this wrong.

The consequence is the thing to plan around: you cannot read an escrowed script, cannot patch it, and cannot convert it to another framework. If the seller ships an ESX build and a QBCore build you buy the right one. If they only ship one, that script is a vote for that framework.

6. Documentation, and how much is expected of you

ESX documents at docs.esx-framework.org, QBCore at qbcore.org/docs, Qbox at its own project docs. All three are reference material rather than teaching material: they tell you what an export returns, not how to design a job. Expect to read Lua either way.

The real difference is support surface. ESX's larger, older user base means the error you are staring at has almost certainly been asked before. Qbox's is smaller but more technical. QBCore's is large but currently spread across an org move and a fork.

7. Migration is the reason any of this matters

Changing framework later is not a setting. Every player row has to be rebuilt — identifier to citizenid, accounts to a money JSON blob, typed name and birthdate columns folded into charinfo — and every open-source script you run needs its framework calls rewritten. Escrowed scripts cannot be converted at all; you rebuy or you replace. Owned vehicles, properties, gang and job data each carry their own conversion, and anything you get wrong shows up as missing player property, which is the fastest way to lose a community.

Nobody should plan on doing this. Assume the first choice is the only choice, and choose accordingly.

8. The recommendation, by situation

First server, no developer, learning as you go: ESX Legacy. Most active development, largest pool of people who can answer your question, ox_inventory supported, and the shallowest path from a txAdmin deploy to something players can actually log into. Start there. Install FiveM properly first if you have not.

A team with at least one competent Lua developer, building for the next two years: Qbox. The ox stack is where the ecosystem is heading, the bridge means you are not locked out of the QB script library, and the code is the most modern of the three. Do not choose it if nobody on the team can read a stack trace.

Already running QBCore: stay, or move to Qbox. Do not migrate QBCore to ESX. The schema rewrite is total and the payoff is not there. Qbox is the cheap move because the bridge does most of the work, and it puts you back on the maintained inventory.

The ecosystem is genuinely fragmented — three mainstream frameworks plus ox_core and nd_core, with oxmysql, ox_lib and ox_inventory as the shared layer beneath all of them — and a paid script market means part of your dependency list is commercial rather than technical. Whichever you pick, your performance problems will come from your resources and not your framework, which is where FiveM milliseconds actually go, and the day your listing vanishes it is usually an artifact or query fault, covered in why your FiveM server shows as offline.

When you have something worth joining, add it free. And if you are choosing partly with one eye on what comes next, read GTA 6 roleplay servers before you let that reasoning influence a decision you are making today.