The day you bump sv_maxclients from 32 to 128 is the day you find out which of your "fine" scripts were only fine because nobody was watching. Real fivem server scaling has almost nothing to do with the slot number — that line takes ten seconds to edit. Everything that actually breaks lives downstream of it: your tick budget, your moderation team, your database pool, and an economy that suddenly has four times as many hands printing money. Quadrupling your population doesn't quadruple your problems. It squares some of them.
The slot number is the easy 1%
Above 32 slots you are no longer running plain FiveM — you need OneSync, and above ~48 concurrent you want OneSync Infinity specifically, not "On". Infinity is what gives you culling, entity ownership at scale, and the population routing that keeps 128 players from all syncing every prop in the city to each other. Set it in server.cfg with set onesync on (or onesync_enableInfinity 1 on older artifacts), raise sv_maxclients, and confirm your CFX deployment/license actually permits the count. That's the whole "scaling" part everyone fixates on. The slot count is a promise to players; the rest of this article is whether you can keep it.
Your tick budget gets tighter with every player
FiveM's main server logic runs effectively single-threaded. Every script's per-frame work shares one budget, and that budget is measured in milliseconds per tick. A script that costs 0.4ms at 32 players doesn't stay at 0.4ms — anything that loops over online players, entities, or owned vehicles scales with population. At 128, that same script can be eating 2-3ms, and three of those together will blow past your frame and start producing the dreaded "server thread hitch" warnings.
- Audit under real load, not empty. An empty server lies. Profile at 48+ concurrent with resmon 1 and the server-side txAdmin performance graph, and watch which resources climb as players join. Continuous performance tooling like the monitors on 0resmon-tebex.io exists precisely because the script that melts at 128 looked perfect on opening night.
- Hunt per-player loops. Any Citizen.Wait(0) thread that iterates GetPlayers() is a time bomb. Convert polling to events, raise wait intervals, and cache anything you can.
- Budget headroom. Aim to keep total server tick well under 50% at peak so a player surge or a script spike has somewhere to go.
Moderation does not scale linearly — it scales worse
This is the part owners never plan for. Player count grows linearly; conflicts grow with the number of interactions, which grows roughly with the square of population. Double the players and you don't double the reports — you can triple or quadruple them. A staff team that comfortably handled 32 players will drown at 96, and an undermoderated server hemorrhages its good roleplayers first because they're the ones who care when rule-breaking goes unpunished.
- Keep a real ratio. Plan for roughly one active staff member per 15-25 concurrent players, and remember staff need to actually be online at peak, not just on the roster.
- Tooling over headcount. A good report/ticket system (ps-dispatch-style staff alerts, an in-game /report, txAdmin action logs, Discord ticket bots) lets a small team punch above its weight. A bigger population also makes you a bigger, juicier target — the security and anti-DDoS thinking on febex.io stops mattering "eventually" and starts mattering the week you trend on the server list.
- Write rules that scale. Vague rules force staff to adjudicate every edge case by hand. Specific, enforceable rules let them act fast and consistently.
Population is an inflation engine
Four times the players means four times the legal-job faucet pouring cash into the same economy, but your money sinks usually stay fixed. The result is predictable: prices that felt balanced at 32 turn into pocket change at 128, the in-city market floods, and new players arrive into a world where everyone already owns the supercar. Inflation doesn't announce itself — you notice when nobody bothers with the entry-level jobs anymore.
- Re-price against the hour. Recheck what one hour of legal work pays versus the cost of your aspirational items every time you add a population tier.
- Add sinks that consume, not store. Repairs, rent, fees, consumables, and event entry fees remove money permanently; player-to-player trading just moves it.
- Watch the elite gap. Bigger populations widen the rich-poor spread fast. Community events and seasonal content — the kind of recurring programming covered on shop-tebex.io — give late arrivals a reason to log in that isn't "out-grind the veterans".
Infrastructure stops being invisible
At 32 players almost any VPS coasts. At 128, three resources become real constraints. Single-thread CPU is king — FiveM cares about per-core clock speed far more than core count, so a high-GHz dedicated core beats a pile of slow shared vCPUs every time. Bandwidth scales with players times sync volume; budget real upstream, because a city packed with vehicles and props at 128 pushes serious traffic. And your database goes from afterthought to bottleneck.
- oxmysql connection pool: the default connectionLimit (often 4-5) will queue queries under load. Raise it sensibly and make sure MySQL/MariaDB's max_connections is higher than the sum of every resource's pool.
- Kill synchronous queries. One blocking .fetchSync in a hot path stalls the whole server thread. Go async everywhere.
- Batch and index. Save inventories and positions on intervals or events, not every frame, and index the columns you query. An unindexed lookup that's instant on a small table crawls once 128 players have filled it.
What to actually check at each tier
Don't jump 32 to 128 in one night. Climb it and verify at each step. At 48: confirm OneSync Infinity is genuinely on, re-profile tick budget under real load, raise the oxmysql pool. At 64: staff ratio and report tooling become the limiter — fix moderation before you advertise more slots, and recheck CPU steal on your host. At 96: economy inflation and DB query latency are your top risks; audit sinks and add indexes. At 128: bandwidth, hitch warnings under peak, and onboarding throughput — can a new player still find help and a first job when the city is full? Each tier exposes a different weakest link, and the discipline of scaling is fixing that link before you sell the next 32 slots. Grow into the number; don't just type it.
