Head-to-head
ESX vs QBCore, Which FiveM substrate should you actually pick?
Real trade-offs, not vibes. Decision tree, side-by-side differences, migration cost, and a verdict you can act on.
At a glance
ESX (Legacy + Modern)
Largest catalog · since 2017
One of the largest FiveM ecosystems and script catalogs, classic xPlayer pattern.
QBCore Framework
Modern standard · since 2021
Modern, opinionated successor to ESX, strong community, large script catalog.
Decision tree
Walk these in order. The first one that's true makes the decision for you.
- 1
Are you porting/inheriting an existing FiveM script catalog?
→ ESX if catalog is ESX-heavy; QBCore if catalog is QB-heavy. Don't port the catalog to fit the framework, fit the framework to the catalog.
- 2
Does your team have prior framework experience?
→ Match the framework to existing knowledge; the cognitive switching cost is the dominant variable, not technical merit.
- 3
Do you want a more opinionated, cohesive default resource set?
→ QBCore. ESX leaves more architectural choices to you.
- 4
Do you need the largest possible community-tutorial / forum-answer pool?
→ ESX. The catalog of 5+ year old answers is meaningfully larger.
Key differences
| Aspect | ESX | QBCore |
|---|---|---|
| Player API style | xPlayer.addMoney(500), verb on object | Player.Functions.AddMoney('cash', 500, 'reason'), namespaced + reason argument |
| Default inventory | esx_inventoryhud or ox_inventory | qb-inventory or ox_inventory |
| Database adapter | Mixed: mysql-async on legacy, oxmysql on modern | Canonically oxmysql |
| Metadata pattern | Bolted-on community pattern | First-class via Functions.SetMetaData |
| Maturity / age | ~8 years (since ~2018) | ~5 years (since ~2021) |
| Default UI helpers | Community NUI templates, varies | qb-menu / qb-input ship with the core |
Migration cost
What it actually costs to switch in either direction.
Player object reshape, event renames, inventory schema changes, metadata migration. Plan multi-week effort for a working server.
Same magnitude in reverse, with the added pain of moving from a more cohesive default set to one that requires more glue.
Verdict
Choose ESX if
Choose ESX if your script ecosystem is ESX-heavy, your team has ESX experience, or you value the largest community knowledge base.
Choose QBCore if
Choose QBCore if you're starting fresh in 2025-2026 with no legacy catalog, want a more opinionated default resource set, or prefer namespaced APIs.
Either is fine if
Either works for the same kind of server. Frame the choice by ecosystem and team familiarity, not by which is "better."
Common questions
- Is QBCore a fork of ESX?
- Conceptually inspired by ESX but not a literal fork. QBCore reimplemented the player-economy-inventory pattern with its own API surface and resource family.
- Which has more compatible scripts on Tebex?
- ESX still has the larger total catalog by virtue of age, though QBCore's catalog has grown faster since 2022. For any specific script category, check both before choosing.
- Can a developer skilled in one pick up the other quickly?
- Yes. The mental model transfers within a week of focused work. The friction is in idioms (xPlayer.addMoney vs Player.Functions.AddMoney) more than in concepts.
Read deeper on either framework
Still on the fence?
FiveM Coach by Quasar supports ESX and QBCoreas first-class targets. Take the free assessment and we'll recommend based on your actual project, not theory.