ESX vs QBCore vs QBOX: Technical Framework Comparison 2026
Introduction
Choosing a framework is the single most consequential decision when building a FiveM server. It determines which scripts you can use, how your developers write code, the performance ceiling of your server, and the long-term maintainability of your stack. In 2026, three frameworks dominate the scene: ESX Legacy, QBCore, and QBox. Each has distinct strengths, trade-offs, and ideal use cases.
This is a technical comparison — not a popularity contest. We'll cover architecture, API design, performance, ecosystem maturity, and future trajectory. By the end, you'll have a clear picture of which framework fits your specific situation.
Framework Origins and Philosophy
ESX Legacy
ESX (EssentialMode Extended) is the oldest of the three, originally released around 2017. ESX Legacy is the community-maintained fork that replaced the original abandoned version. Its design philosophy prioritizes broad compatibility and simplicity — ESX scripts tend to be straightforward, server-authoritative, and easy to modify even for beginner developers.
ESX operates on a job-grade system where every player has a job and a grade within that job. This model maps cleanly onto traditional RP server structures and has been refined over years of community contributions. The GitHub repository for ESX Legacy is available at github.com/esx-framework/esx_core.
QBCore
QBCore launched in 2020 as a modern alternative to ESX. It introduced a more opinionated architecture, a built-in inventory system, a player data model centered on citizen IDs, and a resource structure that encouraged consistent patterns across scripts. QBCore grew rapidly due to its active community, large free script library, and the perception that it represented a cleaner codebase.
QBCore's philosophy is cohesion — scripts are expected to follow shared patterns, use shared exports, and integrate with the core player data object. The tradeoff is a steeper learning curve for developers coming from ESX or standalone scripting.
QBox
QBox is the newest of the three, forked from QBCore with significant architectural improvements. Its primary goals were performance, modularity, and correctness. QBox disaggregated QBCore's monolithic core into smaller, independently updatable modules, adopted ox_lib as a first-class dependency, and introduced stricter patterns for inter-resource communication. There is an official migration guide from QBCore to QBox for servers considering the transition.
Architecture Comparison
Core Structure
| Aspect | ESX Legacy | QBCore | QBox |
|---|---|---|---|
| Core design | Monolithic resource | Monolithic core | Modular (split resources) |
| Player data model | Job + grade + accounts | CitizenID + job + gang | CitizenID + job + gang (refined) |
| Inventory | External (ox_inventory recommended) | qb-inventory (built-in) | ox_inventory (built-in) |
| Primary language | Lua | Lua | Lua |
| Server-side authority | Partial | Partial | Strong |
| ox_lib dependency | Optional | Optional | Required |
Database Approach
All three frameworks use MySQL via oxmysql (the modern standard) or the older mysql-async. The schema design differs significantly:
- ESX: Players stored with job, job_grade, accounts JSON column. Metadata lives in multiple columns.
- QBCore: Players stored with citizenid as primary key, charinfo and metadata as JSON blobs. Simpler schema, harder to query directly.
- QBox: Similar to QBCore but with cleaner separation between character data and player metadata. Easier to extend without touching core tables.
API Design and Developer Experience
ESX API
ESX exposes its API through a shared object retrieved via exports:
local ESX = exports['es_extended']:getSharedObject()
local xPlayer = ESX.GetPlayerFromId(source)
xPlayer.addMoney(500)
xPlayer.setJob('police', 3)The API is procedural and easy to reason about. Every function call is explicit. The downside is verbosity — common patterns require multiple API calls, and error handling is left entirely to the script developer.
QBCore API
QBCore uses a similar export pattern but centers everything around the player's data object:
local QBCore = exports['qb-core']:GetCoreObject()
local Player = QBCore.Functions.GetPlayer(source)
Player.Functions.AddMoney('cash', 500)
Player.Functions.SetJob('police', 3)The namespacing (QBCore.Functions, Player.Functions) is more structured but creates deeply nested call chains. QBCore also standardizes shared configuration through QBCore.Shared tables, which reduces duplication across scripts.
QBox API
QBox refactored the API to use ox_lib's class system and direct exports rather than a global core object. This reduces coupling and enables tree-shaking — resources only load what they need. The ox_lib integration also provides standardized UI components (progress bars, context menus, notifications) that eliminate the need to bundle UI libraries in individual scripts.
-- QBox uses direct module imports
local player = require '@qbox-core.modules.player'
local xPlayer = player.getPlayer(source)
xPlayer.addMoney('cash', 500)Performance Benchmarks
| Metric | ESX Legacy | QBCore | QBox |
|---|---|---|---|
| Core resource tick rate | ~1ms avg | ~0.8ms avg | ~0.4ms avg |
| Player join time | Medium | Medium | Fast |
| Memory footprint (core) | Higher | Medium | Lower (modular) |
| Script ecosystem overhead | Varies widely | Moderate | Lower (ox_lib shared) |
| Database query patterns | Legacy (some inefficient) | Modern (oxmysql) | Modern (oxmysql, optimized) |
QBox's modular design means only loaded modules consume memory and tick time. On a server running 80+ resources, this difference becomes measurable. However, ESX and QBCore are both stable and capable of running high-population servers — the performance delta only becomes meaningful at scale or with many concurrent players.
Script Ecosystem Size
| Category | ESX | QBCore | QBox |
|---|---|---|---|
| Free scripts (GitHub) | Largest | Very large | Growing |
| Paid scripts (Tebex) | Largest | Very large | Growing fast |
| Native compatibility | High | High | Medium (some porting needed) |
| ox_lib native support | Partial | Partial | Full |
| Script quality floor | Variable | Variable | Higher (stricter patterns) |
ESX has the largest absolute script count due to its age. However, many ESX scripts are unmaintained forks from 2018-2020. QBCore's ecosystem is more consistently maintained. QBox has the smallest ecosystem but the highest average script quality, and the number of native QBox resources is growing rapidly in 2026.
Community Activity and Support
| Dimension | ESX Legacy | QBCore | QBox |
|---|---|---|---|
| GitHub stars | High | Very high | High (growing) |
| Discord activity | Large, mixed quality | Large, active | Smaller, high signal |
| Documentation quality | Moderate | Good | Good |
| Core update frequency | Moderate | Active | Very active |
| Breaking changes | Rare | Occasional | More frequent (early stage) |
Inventory System Integration
Inventory integration affects the entire server feel — how items are stored, how scripts interact with player inventories, and the performance of high-frequency item operations. See our dedicated inventory scripts guide for a full comparison.
- ESX: Default inventory is basic; most servers replace it with ox_inventory or lj-inventory
- QBCore: Ships with qb-inventory; many servers switch to ox_inventory for better performance
- QBox: Ships with ox_inventory natively; no migration needed
Migration Paths
ESX to QBCore
The ESX-to-QBCore migration is the most common server transition. Player data requires a migration script to convert accounts to QBCore's inventory format. Most scripts require a framework-specific version or fork. Expect 2-4 weeks of development time for a full server stack migration.
QBCore to QBox
This is a more surgical migration. QBox is a QBCore fork, so player data schemas are similar. The main work involves updating resource imports, replacing qb-specific UI calls with ox_lib equivalents, and auditing scripts for QBox compatibility. Refer to the official QBCore to QBox migration guide.
ESX to QBox
The hardest migration. Essentially rebuilding the server from scratch with a new data model. Only recommended if you're starting with a small, freshly wiped server.
Which Framework Should You Choose?
| Scenario | Recommended |
|---|---|
| First server, beginner developers | ESX Legacy |
| Established server, large free script needs | QBCore |
| New server, performance focus, modern patterns | QBox |
| Large team, long-term maintainability priority | QBox |
| Existing ESX server, not migrating | ESX Legacy (keep, optimize) |
| Existing QBCore server considering upgrade | QBox (migrate) |
Setting Up Your Server
Regardless of which framework you choose, a solid foundation requires more than just the core. See our complete FiveM server setup guide and our overview of essential FiveM scripts for a complete picture of what a production-ready server stack looks like.
For premium, pre-configured scripts compatible with all three frameworks, browse the VertexMods shop.
Future Outlook (2026 and Beyond)
ESX Legacy will remain dominant by raw server count for years due to installed base inertia. QBCore will continue to see strong community activity and script releases. QBox is positioned as the framework of choice for new projects — its architectural decisions align with where the FiveM development community is heading: modular resources, ox_lib as a shared standard, and stricter server-authority patterns.
The trend across all three frameworks is convergence toward ox_lib for UI and utility functions. If you start a new server today, building on QBox gives you the most future-proof starting point.
FAQ
Can I use QBCore scripts on a QBox server?
Many QBCore scripts work on QBox with minor modifications, since QBox is a fork. The main changes needed are updating import paths and replacing qb-specific UI calls with ox_lib equivalents. Check each script's GitHub issues for QBox compatibility notes before migrating.
Is ESX dead in 2026?
No. ESX Legacy remains actively maintained and has the largest installed base of any FiveM framework. Thousands of servers run ESX successfully in 2026. It's not the most modern choice for new projects, but it is far from dead.
Does the framework choice affect player-facing experience?
Directly, less than you'd think — players experience the scripts built on the framework, not the framework itself. Indirectly, framework choice affects which scripts you can install, how polished those scripts are, and server performance under load — all of which players notice.
What is ox_lib and why does QBox require it?
ox_lib is a shared resource library maintained by the Overextended team. It provides UI components (progress bars, context menus, radial menus, notifications), utility functions, and class-based OOP patterns for Lua. QBox made it a first-class dependency to standardize UI and eliminate duplicate code across the ecosystem. Learn more in the ox_lib complete guide.
Mantente al Día
Recibe los últimos tutoriales de FiveM, lanzamientos de mods y actualizaciones exclusivas en tu correo.
Sin spam. Cancela cuando quieras.