This guide covers how to size your hardware, find what is actually causing lag, and keep large FiveM servers stable during peak hours.
Who This Guide Helps
Server owners deciding how much hosting power they need before buying or upgrading. Whether you are launching a new project or troubleshooting a live server that slows down at 60+ players, the advice here applies.
How OneSync Changes Server Load
OneSync moves entity synchronization from clients to the server. Every additional player adds synchronization overhead on top of normal script execution. More players means more entity updates, more state bag changes, and more script triggers per tick.
The server needs consistent performance to stay smooth. It is not high average CPU usage that causes rubberbanding. It is spikes. A server sitting at 70% CPU steadily will feel better than one swinging between 30% and 95%.
OneSync Infinity uses roughly 25% to 30% more CPU than Legacy at the same player count. The tradeoff is worth it for the better entity management and higher player ceiling. If you are still deciding which OneSync mode to use, read our OneSync Explained guide for a full comparison.
Hardware Sizing
These baselines assume a standard RP server running QBCore or ESX, moderate vehicle counts, and roughly 50 to 80 active resources.
| Player Cap | RAM | CPU Cores (3.5 GHz+) | Notes |
|---|---|---|---|
| 32 players | 4 GB | 2 | Light RP, few custom vehicles |
| 64 players | 6 to 8 GB | 4 | Standard RP server |
| 128 players | 12 to 16 GB | 6 to 8 | Heavy RP, many resources |
| 200+ players | 24 to 32 GB | 8+ | Requires careful optimization |
Single-core CPU performance matters more than core count for FiveM. The game loop is primarily single-threaded, so a 4-core Ryzen at 5.0 GHz will outperform an 8-core Xeon at 3.0 GHz for this workload.
The Most Common Lag Sources
Before upgrading hardware, check whether your performance problems are actually caused by bad resources. Throwing money at bigger servers will not fix a script problem.
Heavy or poorly written scripts. A single resource with a Citizen.Wait(0) loop running expensive logic every frame can tank the entire server. Profile with resmon and look for resources consistently above 1ms.
Too many synced entities. Every synced entity costs server CPU. Servers that spawn hundreds of static props as networked entities instead of using server-side object creation waste synchronization budget on things that never move.
Framework bloat. Some QBCore and ESX forks ship with dozens of resources enabled by default. If your server does not use a feature, disable it. Every running resource consumes CPU even when idle.
For a detailed breakdown of specific lag causes and fixes, read FiveM server lag and rubberbanding fix.
Database Performance
At higher player counts, your database becomes a real bottleneck. Every inventory check, bank transaction, and character load hits the database. With 100+ players, that adds up fast.
Slow queries do not just slow down one feature. When a script waits synchronously for a database result, the entire server tick stalls. One slow query at the wrong time causes visible rubberbanding for every player on the server.
Practical fixes:
- Use
oxmysqlor a modern async database wrapper - Add indexes to columns you query frequently (identifier, charid, plate)
- Move heavy queries (logs, analytics) to a separate database connection
- Avoid
SELECT *when you only need one or two columns - Run your database on the same machine or a very low latency connection
Asset Bloat and Streaming
Custom vehicles, MLOs, and clothing packs are a major part of FiveM RP, but they come with real costs.
Memory impact. Every custom asset loaded on the server uses RAM. A server with 500+ custom vehicles and 50 MLOs can easily consume 8 GB of RAM before a single player connects.
Streaming pressure. Clients need to download and render these assets. Too many high-poly vehicles in one area cause frame drops and texture pop-in that players blame on "server lag" when the problem is actually client-side.
Keep asset quality high, but be selective. Five well-made custom vehicles look better and perform better than fifty hastily converted ones. Audit your asset packs regularly and remove anything players do not actually use.
What to Avoid
Do not advertise 100 slots before testing the server with real players. Stress test voice chat, inventories, vehicles, job scripts, and police tools with at least 20 to 30 concurrent players first.
Do not throw money at bigger hardware before profiling. If your server lags at 40 players because of a bad script, it will still lag at 40 players on a more expensive machine.
Do not copy another server's resource list and expect the same performance. Every combination of resources interacts differently, and what works for one community may not work for yours.
The Better Approach
Pick a hosting plan based on your expected player count and resource complexity, then measure during actual peak hours. Upgrade when CPU or memory is truly the bottleneck. Remove or fix bad scripts before spending more money.
Start with a realistic player cap. Run 48 slots for the first month. If you consistently fill them and performance stays good, bump to 64. Let your infrastructure grow with your community instead of over-provisioning for a population that does not exist yet.
Hosting That Fits
For large OneSync servers, you want strong single-core CPU performance and stable networking. If your community is in Europe, a Netherlands location is often a good average for mixed EU traffic.
Space-Node's FiveM hosting uses AMD Ryzen hardware with high single-core performance specifically to handle OneSync Infinity workloads. Our plans are sized from 16 up to 250 concurrent players and run on the Ryzen 9 7950X or 9950X in Europe (depending on stock), the Ryzen 9 7950X3D in the USA, the Ryzen 9 5950X in Singapore and Australia, and Ryzen 9 3900X-class hardware in India, with DDoS protection, panel access, and support included.