ESX or QBCore: which framework for your roleplay server?

You're about to start a FiveM roleplay server and immediately run into the big question: ESX or QBCore? Both frameworks are free, open source and written in Lua. Both power thousands of successful roleplay servers. And yet the choice feels heavy, because switching afterwards costs a lot of time and frustration. No wonder you want to get this right the first time.

So let's put the two frameworks side by side honestly: no fanboy story, just the practical differences you'll actually notice as a server admin. With concrete advice per server type at the end.

ESX in short

ESX, in full es_extended, is the older of the two and grew into the standard framework of the FiveM world, especially in Europe. The actively maintained version is called ESX Legacy and has been thoroughly cleaned up and sped up compared to the old versions the framework once owed its sluggish reputation to. Anyone who wrote off ESX in 2020 is selling today's framework short.

ESX's great strength is maturity. Virtually every roleplay concept has been built on it at some point, so you'll find an existing script for almost any feature: police and ambulance jobs, economies, housing, garages, you name it. Also nice: because many Dutch and European servers run ESX, there's relatively plenty of local knowledge and help to be found in the community.

QBCore in short

QBCore is the younger framework and has grown extremely fast in recent years, especially in the English-speaking scene. It's modular from the ground up: the core (qb-core) stays compact and virtually all functionality lives in separate qb-resources that are easy to replace or customise. The standard components, such as inventory, phone and jobs, feel more modern out of the box than the classic ESX equivalents.

The ecosystem around QBCore is young but very active. Many new scripts nowadays appear with QBCore support first. The flip side: the framework changes faster. Core updates can break dependent resources, meaning you'll have to update and test more often as an admin. There are also forks of QBCore by now that chart their own course; so when buying scripts, always check exactly which variant they were built for.

The comparison, part by part

Community and documentation

ESX has the longest history and therefore the biggest archive of forums, tutorials and Discord channels. Downside: a lot of that information covers outdated versions, so you sometimes find solutions that no longer quite apply to ESX Legacy. QBCore has less of an archive, but its active community is large and the documentation is relatively current. If you're looking for help in Dutch, with ESX you'll often find someone who recognises your problem just that bit faster.

Script availability

Quantitatively, ESX wins: there's simply more, free and paid. Qualitatively the picture is mixed. Many free ESX scripts are old and poorly maintained, while the QBCore offering is on average younger and fresher. Serious script developers nowadays often release their work for both frameworks anyway, sometimes via a compatibility layer. For niche concepts, it pays to check before choosing your framework whether the scripts you absolutely want are even available.

Performance

Time for an honest reality check: the framework itself is rarely your bottleneck. Both ESX Legacy and QBCore run fine on a well-configured server. What makes servers slow are poorly optimised scripts, far too many resources at once and heavy database queries. A tight QBCore server with fifty well-considered resources outperforms an ESX server with two hundred stacked scripts, and the exact same applies the other way around. So don't choose your framework based on performance claims from YouTube videos, but keep your resource list critically short.

Learning curve

QBCore is usually a bit friendlier for beginners: the structure is more consistent and the standard resources work together more logically. ESX takes a bit more figuring out, mainly because you'll encounter old and new scripts mixed together, each with their own approach. If you (or a teammate) are already reasonably comfortable with Lua and SQL, the difference is small and it mostly comes down to taste.

Updates and maintenance

ESX Legacy is developed calmly and predictably: updates do come, but they rarely break existing scripts. QBCore moves faster, and you'll notice. After a core update, some of your resources may start complaining, and then it's up to you to figure out which script needs a new version. If you enjoy tinkering with your server, that's perfectly manageable. If you mainly want everything to just keep running, weigh this seriously in your choice.

Switching from one framework to the other

Short answer: it's possible, but don't get your hopes up. ESX and QBCore use different database structures for players, items, vehicles and jobs. Conversion tools exist that take part of the work off your hands, but in practice you'll still spend days to weeks migrating data, replacing scripts and re-testing every feature. For a server with an active community, that means downtime, bugs and grumbling from your players.

Our advice: treat the framework choice as semi-permanent. If in doubt, first set up a test server with both frameworks and a handful of scripts you really want to use. An afternoon of clicking around and testing yourself says more than ten comparison videos by others.

Which framework suits your server?

• Dutch roleplay server with classic jobs and an economy: ESX. The biggest range of proven scripts and the most local knowledge and examples.
• New server with a modern interface and current scripts: QBCore. The young ecosystem fits better with what's being released now.
• Small server for a group of friends: QBCore. Quick to set up, and the standard components are usable right away.
• Server with its own development team: makes little difference. You'll customise everything anyway; pick the framework your team has the most experience with.
• Existing ESX server having doubts: stay. The migration costs rarely outweigh the benefits.

One final nuance: more and more scripts are built standalone and work on both frameworks. The more standalone resources you use, the less the framework choice weighs. The foundation, such as jobs, inventory and player data, always remains framework-bound though, so escaping the choice entirely isn't possible.

Hosting that can handle your framework

Whichever framework you choose: a roleplay server with a database, dozens of resources and a growing community needs a solid machine. At MC-Node your FiveM server runs on our own hardware with NVMe storage in the Previder data centre in Hengelo, DDoS protection included. All plans can be cancelled monthly, so you're not tied to anything if your project turns out differently than planned. How much you need mainly depends on your number of resources and players: a bare test server needs little, a full roleplay server with a database and dozens of scripts clearly more.

Want to calmly experiment with ESX and QBCore side by side first? Then the free Free plan or a small plan is an ideal testing ground. Once you go live with real players, you simply grow into a bigger plan. Check out all FiveM server plans from MC-Node and start building today.