What it is
QBCore was built around 2021 as a more opinionated, more modern alternative to ESX. It standardized around oxmysql for database access (rather than the older mysql-async), introduced a cleaner Player object pattern via QBCore.Functions, and shipped a coherent set of qb-* resources (qb-inventory, qb-menu, qb-target, qb-policejob, qb-banking) so a new server could be operational with minimal external dependencies.
Server-side, you typically grab the framework with QBCore = exports['qb-core']:GetCoreObject(), then access players with QBCore.Functions.GetPlayer(source). Player methods follow a verb-driven API (Functions.AddMoney, Functions.AddItem, Functions.SetMetaData) and metadata is a first-class concept rather than the bolted-on pattern it became in ESX.
QBCore's growth from 2022 onward made it the default target for a large generation of scripts — anything labeled "qb-" or "qb compatible" assumes the QBCore environment. A meaningful subset of new servers from 2023 onward pick QBCore over ESX as their starting point.
When to choose QBCore
- You want a more opinionated, more cohesive default resource set than ESX provides out of the box.
- Your team prefers verb-driven, namespaced APIs (Functions.AddMoney) over ESX's xPlayer.addMoney style.
- You're starting a new server in 2025–2026 and want a modern, well-maintained baseline without the QBox migration learning curve.
- You want metadata-driven design (player metadata, item metadata) as a first-class concept rather than a community pattern bolted on top.
Version timeline
QBCore 1.0
2021
Initial public release, qb-* family established.
QBCore Modernization (2022–2023)
2023
ox_inventory adoption surge, oxmysql canonicalized, performance tuning.
QBCore today
2026
Stable, large script ecosystem, parallel community drift toward QBox for greenfield work.
Signature code patterns
Get a player and add money
local Player = QBCore.Functions.GetPlayer(source)
if Player then
Player.Functions.AddMoney('cash', 500, 'gift-from-admin')
TriggerClientEvent('QBCore:Notify', source, 'You received $500', 'success')
endServer callback (modern)
QBCore.Functions.CreateCallback('myresource:hasItem', function(source, cb, itemName)
local Player = QBCore.Functions.GetPlayer(source)
local item = Player.Functions.GetItemByName(itemName)
cb(item ~= nil and item.amount > 0)
end)Common pitfalls
Player object null on join
QBCore.Functions.GetPlayer(source) returns nil for the brief window between connection and full player load. Always nil-check before using methods, or hook the QBCore:Server:PlayerLoaded event to know it's safe.
Metadata vs PlayerData
Player.PlayerData.metadata is a free-form table you can extend, but writes to it must go through Player.Functions.SetMetaData('key', value) to fire the proper sync event — direct assignment leaves clients out of sync.
qb-target vs ox_target
Many qb-* scripts ship with qb-target as the assumed target system, but ox_target is a drop-in superior performer. If you swap, audit every exports['qb-target'] call site — the export shapes differ in subtle ways.
Quasar Academy support for QBCore
First-class support
Quasar Academy treats QBCore as a first-class target. Code review on Elite covers QBCore-specific architecture (Player.Functions, metadata, qb-target ecosystem) and the Developer path's milestone projects can target QBCore if you ask in onboarding.
Common questions about QBCore
- Is QBCore better than ESX?
- Better is the wrong frame. QBCore is more opinionated and more cohesive out of the box; ESX has the larger ecosystem of compatible scripts. Pick by ecosystem fit and team familiarity, not by which is "newer."
- Should I migrate from QBCore to QBox?
- QBox is essentially QBCore with breaking changes that force ox_lib and ox_inventory. If those forced changes solve a real problem you have (perf, bridge complexity), migrate. Otherwise, stay. See /compatibility/qbcore-vs-qbox.
- Does Quasar Academy ship QBCore-specific milestones?
- Yes. Developer-path students can pick QBCore as their primary framework during onboarding, and milestone projects are scoped to the QBCore Player object and qb-* resource patterns.
- Can I run qb-* scripts under ESX?
- No, not without a bridge layer (qbx-esx-bridge or similar). The Player object shape, event names, and shared object lifecycle differ. Bridges work for a subset of cases but introduce their own debugging surface.
- Is QBCore still being updated in 2026?
- Yes. The QBCore organization continues active maintenance, though community attention for greenfield projects is increasingly split between QBCore and QBox. Both are viable production choices.