"My server is lagging" is one of the most common tickets we get for Satisfactory, and it usually comes with a request to bump the RAM. More RAM is rarely the fix. Most Satisfactory performance problems come down to CPU and a single setting, not memory. This guide breaks down what's actually happening and what to check before assuming you need a bigger plan.
Why TPS Drops Are a CPU Problem, Not a RAM Problem
Satisfactory's factory simulation, belts, machines, fluids, vehicle pathfinding, all of it, runs on a single CPU thread. The server does use multiple threads for networking and other background work, but the core tick that determines how smooth your factory feels is bound to one core. A developer confirmed this directly on Discord back in 2021: the game loop is fundamentally single-threaded, so one core always ends up doing more work than the rest, no matter how many cores the server has available.
This means adding more CPU cores or more RAM to a server won't speed up a factory that's outgrown its clock speed. What actually determines your ceiling is single-core clock speed.
Checking Your TPS
Satisfactory targets 30 ticks per second. There's no built-in TPS counter, but you can check frame timing with the console command stat unit. If frame time is consistently sitting above roughly 33ms, you're dropping below 30 TPS.
- 30 TPS: Normal, smooth.
- 20-30 TPS: Mildly degraded, occasional stutter.
- Below 20 TPS: Noticeably laggy, belts move in bursts.
- Below 10 TPS: Effectively unplayable.
Factory Changes That Actually Reduce CPU Load
- Consolidate belts. Several low-tier belts running in parallel cost more to simulate than one higher-tier belt carrying the same throughput.
- Switch trucks for trains. Trucks constantly recalculate pathfinding, which is expensive. Trains run fixed routes and are far cheaper to simulate. If you're running more than a couple of truck routes, converting to rail is one of the biggest single improvements available.
- Simplify pipe networks. Fluid simulation is heavier than belts, and every junction, valve, and pump adds a calculation point.
- Park unused vehicles. Every active vehicle adds pathfinding overhead whether or not a player is nearby.
- Build compact and vertical where practical. Long sprawling belt runs are more expensive to track than short, efficient ones.
Rubber-Banding and Desync: Check Network Quality First
Rubber-banding, players or items snapping between positions, and general desync are usually mistaken for server lag, but they're really a client-server sync issue, and the culprit is almost always the Network Quality setting.
When a RAM Upgrade Actually Helps
RAM isn't the direct cause of most lag complaints, but it does matter in a few specific situations:
- Autosave spikes. During an autosave, the server temporarily needs a few extra gigabytes above its normal baseline. If you're running close to your memory ceiling, that spike can crash the server. This is the single most common legitimate reason to upgrade RAM.
- Long-term memory growth. Satisfactory servers gradually accumulate memory usage over long uptimes, even with the same factory. Scheduled restarts, covered below, are the standard fix rather than adding more RAM.
- Large factory expansions. If you're about to substantially grow your factory and want headroom, more RAM is a reasonable precaution. It just isn't a fix for TPS drops you're already experiencing.
If TPS is dropping and RAM usage isn't near its ceiling, more RAM won't help. That's a CPU and factory complexity problem, covered above.
Other Things Worth Doing
Scheduled restarts: Set a Server Restart Schedule in Server Settings. A daily restart is a reasonable default; heavily built servers may benefit from restarting every 12 hours or so. This is the most effective long-term fix for the gradual memory growth mentioned above.
Autosave interval: If your server stutters on a suspiciously regular cycle, check whether it lines up with your autosave interval. Large factories can see a brief TPS dip while a save writes to disk. Increasing the interval in Server Settings reduces how often that happens, at the cost of losing slightly more progress if the server crashes between saves.
Quick Diagnostic Checklist
- Is the lag on a regular cycle matching your autosave interval? Increase the interval.
- Has the server been running for days without a restart? Restart it.
- Is RAM usage consistently near its ceiling? That's worth upgrading.
- Is Network Quality set to Ultra on the server and every connecting client?
- Did a mod get added recently? Automation and content mods can add meaningful CPU load, try disabling recent additions.
- How complex is the factory? Look at belt tiers, truck routes, pipe junctions, and idle vehicles.
If you've worked through all of this and TPS is still dropping, you've likely hit the single-core CPU ceiling for your current factory's complexity, at that point the options are optimizing further, splitting production across multiple servers, or accepting the trade-off of building at that scale. If you're not sure where your bottleneck is, no worries! Just open a support ticket and our team will be happy to take a look.