ESX vs QBCore: which one to choose

The problem

You're about to set up a FiveM roleplay server and you don't know whether to start with ESX or QBCore. Every tutorial and every community recommends a different one, and you're afraid of choosing wrong and having to redo everything.

The cause

ESX and QBCore are the two most widespread roleplay frameworks. They solve the same problem (players, jobs, money, inventory, database) but with slightly different APIs and philosophies. The choice matters for which resources you can use as-is, but it does NOT change the concepts you actually need to learn. Many people frame it as a tribal war when they are really equivalent tools.

The solution

The same example (get the player and give them money) in ESX and in QBCore, side by side. You'll see the logic is identical; only the API names change:

-- =====================================================
--  SAME RESULT, TWO FRAMEWORKS
--  Get the player by their server id and give them $500
-- =====================================================

-- ---------- ESX (Legacy) ----------
local ESX = exports['es_extended']:getSharedObject()

RegisterCommand('pay', function(source)
    local xPlayer = ESX.GetPlayerFromId(source)   -- player object
    if not xPlayer then return end

    xPlayer.addMoney(500)                          -- give money (cash)
    local job = xPlayer.job.name                   -- job name
    print(('ESX -> %s got paid, job: %s'):format(source, job))
end)

-- ---------- QBCore ----------
local QBCore = exports['qb-core']:GetCoreObject()

RegisterCommand('pay', function(source)
    local Player = QBCore.Functions.GetPlayer(source)  -- player object
    if not Player then return end

    Player.Functions.AddMoney('cash', 500)             -- give money (cash)
    local job = Player.PlayerData.job.name             -- job name
    print(('QBCore -> %s got paid, job: %s'):format(source, job))
end)

-- Takeaway: client-server, validating 'source' on the server and
-- never trusting the client are THE SAME in both. Only the signature changes.

Step by step

1. 1.What ESX is: the veteran framework (ESX Legacy is the maintained version). Its biggest strength is sheer size: a HUGE base of resources, free and paid scripts, tutorials and a community with years of mileage. If you're looking for a specific resource, chances are it exists for ESX.
2. 2.What QBCore is: a more modern framework, born later and with a core that is more integrated in some areas (player metadata, jobs and needs systems that ship more cohesively). It has its own very active qb-* resource ecosystem.
3. 3.Both run on top of the ox ecosystem: oxmysql (database access), ox_lib (UI and server utilities), ox_inventory (modern inventory) and ox_target (look-at interaction). You can use these resources with either ESX or QBCore, so the framework choice doesn't lock you into a specific inventory or target.
4. 4.API equivalence table — same concept, different name:
5. 5. • Get player: ESX.GetPlayerFromId(src) ↔ QBCore.Functions.GetPlayer(src)
6. 6. • Give money: xPlayer.addMoney(500) ↔ Player.Functions.AddMoney('cash', 500)
7. 7. • Job name: xPlayer.job.name ↔ Player.PlayerData.job.name
8. 8. • Identifier: xPlayer.identifier ↔ Player.PlayerData.citizenid
9. 9. • Shared object: exports['es_extended']:getSharedObject() ↔ exports['qb-core']:GetCoreObject()
10. 10.How to choose (honest recommendation): don't pick a side. Learn the CONCEPTS first —client-server architecture, events, always validate on the server, never trust the client, security— because they are IDENTICAL in both. Then choose the framework based on the actual resources you want to use: look at which scripts (jobs, economy, inventory) fit your idea and check which one they're built for.
11. 11.Rule of thumb: if the resources you like are mostly ESX, start with ESX; if they're qb-*, start with QBCore. Migrating logic between them is feasible because only the API signatures change, not the way you think.

Related guides