Stratum is a server-side fork of Vintage Story that promises better performance on busy multiplayer servers. We host a lot of Vintage Story servers, so we wanted real numbers instead of release-note claims. We built a repeatable benchmark and ran it where it matters: inside an ordinary 4-core, 6 GB game server on one of our production nodes, with other customers' servers running alongside. Then we kept piling on creatures until both servers fell over, to see which one fell over later.
Short answer: if your players explore a lot, or your world is full of creatures and you see lag spikes, Stratum is a real improvement. Budget an extra gigabyte of RAM for it.
What Stratum is
Stratum is an open-source (MIT) fork of the Vintage Story server. It is not a mod you drop into the Mods folder. Its launcher downloads the official server for the matching game version and patches a handful of core files on top. Your players keep using the normal client, your world keeps its save format, and server mods keep working because the modding API is unchanged.
The 1.22.6 and 1.22.7 releases list dozens of performance changes. The ones most likely to show up in a benchmark:
- World generation runs several chunk columns in parallel, with lock-free merging and bulk-copied rock strata.
- Lighting is batched, with AVX2 code paths for bulk chunk data.
- Entities skip work nothing reads: skeleton poses are computed lazily, far-away creatures tick less often, and ticking can be split across regions.
- Allocation is lower across the chunk scheduler and chunk setup, so the garbage collector has less to do.
Stratum also ships admin features (kits, homes, anticheat, backups, announcements, packet limits). We did not measure any of those.
How we tested
- Versions: the official Vintage Story 1.22.7 dedicated server against Stratum
v1.22.7-stratum.2, which patches that exact build. Both on .NET 10. - Where: a normal Vintage Story server created through our panel on our NY 8 node (AMD Ryzen 9 9950X, NVMe), with a typical plan's limits of 4 CPU cores and 6 GB of RAM, in the same image every Vintage Story server on our nodes uses. The node was serving customers at the time. This is the real environment, not a quiet lab machine.
- Workload: a small benchmark mod drives the server with no players connected, so every run does identical work: start a fresh world with a fixed seed, generate a 41 × 41 chunk-column area around spawn, idle, spawn 500 always-active creatures for 45 seconds, then restart and reload the same area from disk. A second series spawns creatures in steps up to 10,000 to find the breaking point.
- Runs: four per server, alternating vanilla and Stratum. Charts show the median, with every run drawn as a dot.
- Settings: defaults on both sides. On Stratum we only switched off the update checker, the usage report and the scheduled backups so they could not add disk or network activity mid-run.
No real players were connected, so Stratum's player-distance throttling and its network changes get no credit here. Forcing every creature active is harsher than a normal server, where most creatures are idle. Treat these numbers as the cost of the simulation itself. The mod, the harness, the chart script and the raw results are all in the benchmark repository if you want to run it yourself.
World generation: 21% faster, paid for in CPU
This is the headline result. New players exploring, a world reset or a pregen job all hammer world generation, and it is the part of Vintage Story that most often drags a server down.
| Vanilla | Stratum | Change | |
|---|---|---|---|
| Generate 1,681 columns | 39.9 s | 31.5 s | 21% faster |
| Throughput | 42.1 columns/s | 53.3 columns/s | +27% |
| Total CPU time, all threads | 44.4 s | 59.4 s | 34% more |
| Reload the same columns from disk | 1.53 s | 1.96 s | 0.4 s slower |
All four Stratum runs landed between 30.5 and 31.6 seconds. Vanilla ranged from 39.6 to 40.3. The gap is far larger than the run-to-run noise.
The CPU chart shows how, and what it costs. Vanilla generates terrain on one or two threads and leaves the other cores partly idle: 44 seconds of CPU over 40 seconds of wall-clock. Stratum keeps all four cores busy: 59 seconds of CPU in 31.5 seconds. On a 4-core plan the faster result is bought with CPU, not saved. Stratum's world generation is faster, not more efficient.
Loading already-generated chunks is not something Stratum speeds up. It was consistently about 0.4 seconds slower, once per restart. Not worth weighing.
Lag spikes with 1,500 creatures: much shorter
The server runs 30 ticks per second, which gives each tick a 33.3 ms budget. When a tick takes longer, the server falls behind and players feel it as rubber-banding and delayed block updates. The average tick is usually fine. The spikes are what players notice.
We loaded the generated area, let it settle, then spawned 500 creatures (wolves, drifters, deer, foxes and hares), flagged them always-active so their AI and physics ran at full rate, and measured every tick for 45 seconds. The area already held about 1,000 wild animals, so each server was ticking roughly 1,500 entities.
| Tick time, 500 active creatures | Vanilla | Stratum | Change |
|---|---|---|---|
| Mean | 5.03 ms | 4.25 ms | 15% lower |
| Median | 4.56 ms | 4.09 ms | 10% lower |
| 95th percentile | 6.95 ms | 5.23 ms | 25% lower |
| 99th percentile | 16.7 ms | 10.1 ms | 40% lower |
| Worst single tick, across runs | 159 to 215 ms | 67 to 87 ms | less than half |
| Ticks per second achieved | 29.8 | 30.0 | same |
The distribution chart tells the story better than the averages. Stratum's curve sits to the left of vanilla's the whole way and reaches 100% sooner: fewer slow ticks, and the slow ones are shorter. Both servers stayed under the 33 ms budget almost all of the time at this load. Vanilla crossed it a handful of times per run; Stratum did not cross it at all after the spawn itself.
We also timed every server subsystem. Entity simulation (AI, behaviours, despawn checks) cost 3.58 ms per tick on vanilla and 2.94 ms on Stratum, 18% cheaper. That is the lazy pose matrices and the allocation work paying off. With four cores, entity work dominates the tick, and that is where Stratum wins.
How many creatures before it breaks
Five hundred creatures did not get either server near its limit, so we ran a second series to find it. Same world, same 4-core, 6 GB server. After the idle phase the mod spawns always-active creatures in steps of 1,000, 2,000, 3,000, 4,000, 6,000, 8,000 and 10,000 in total, on top of the roughly 1,000 wild animals already there, and measures 30 seconds of ticks after each step. Three runs per server.
| Creatures spawned (plus ~1,000 wild) | Vanilla mean / p99 | Vanilla TPS | Stratum mean / p99 | Stratum TPS |
|---|---|---|---|---|
| 1,000 | 8.6 / 31.6 ms | 29.8 | 6.4 / 18.9 ms | 30.0 |
| 2,000 | 17.2 / 47.3 ms | 29.4 | 11.4 / 32.2 ms | 29.9 |
| 3,000 | 25.7 / 57.9 ms | 28.5 | 16.8 / 42.9 ms | 29.7 |
| 4,000 | 35.2 / 81.8 ms | 25.8 | 22.1 / 51.5 ms | 29.2 |
| 6,000 | 58.6 / 106 ms | 17.1 | 33.0 / 64.1 ms | 27.0 |
| 8,000 | 68.0 / 119 ms | 14.8 | 39.8 / 71.6 ms | 24.9 |
| 10,000 | 89.4 / 159 ms | 11.2 | 51.7 / 93.8 ms | 19.4 |
Each creature costs Stratum about 40% less, all the way up. Both lines are close to straight: every extra thousand creatures adds about 8 ms of tick time on vanilla and about 5 ms on Stratum. The ratio holds from 1,000 to 10,000, so it is not a trick that only works at small scale.
That is roughly twice the creature load at full tick rate. Vanilla's mean tick crosses the 33 ms budget between 3,000 and 4,000 spawned creatures. Stratum crosses it at 6,000. If "fine" means 29 TPS or better, vanilla manages 2,000 creatures and Stratum 4,000.
Past the breaking point, Stratum degrades more gracefully. At 10,000 creatures vanilla runs at 11 TPS, barely playable, with one tick in a hundred taking 160 ms or more. Stratum at the same load is at 19 TPS with a 94 ms p99. A server overrun by drifters is bad on both, but on Stratum it is still a server.
This is a main-thread test: at 10,000 creatures both servers used only about 1.5 of their 4 cores, because entity AI runs on the main thread in both. More cores would not have helped either of them. Memory under this load peaked at 2.6 GB on vanilla and 3.3 GB on Stratum, both inside the 6 GB plan.
Memory: budget an extra gigabyte
| Vanilla | Stratum | Change | |
|---|---|---|---|
| Peak working set | 1.76 GB | 2.69 GB | +53% |
| Managed heap after world generation | 1.22 GB | 1.93 GB | +59% |
| Managed heap after the creature phase | 1.17 GB | 1.99 GB | +69% |
| Peak working set, reloading the saved world | 1.43 GB | 1.29 GB | 10% less |
This is the clearest trade-off in the whole test, so we dug into where the extra memory goes.
It is a world-generation cost, not a per-chunk cost. When the same 1,681 columns were loaded from disk instead of generated, Stratum used about 140 MB less than vanilla. The extra 900 MB appears while terrain is being generated and then stays. A server whose map is mostly explored sits much closer to vanilla; a server with players pushing into new land does not.
Most of it is not live data. A heap dump taken 50 seconds after world generation found 1.40 GB of reachable objects on Stratum against 1.16 GB on vanilla. Stratum genuinely holds about 230 MB more for the same world, mostly the lighting buffers that let it light columns in parallel and the pooled arrays vanilla allocates and throws away. The rest is headroom the .NET garbage collector keeps because Stratum allocates in bigger bursts from more threads. With memory to spare, it has no reason to give it back.
What that means for your plan. Size for the peak, not the idle. If a plan is sized tightly for vanilla, Stratum will push it over while players explore. Below about 4 GB we would not recommend Stratum on memory grounds; above that, one tier of headroom is enough.
The small print: idle cost, garbage collection, startup
| Vanilla | Stratum | |
|---|---|---|
| Idle tick, mean | 1.45 ms | 2.05 ms |
| Idle CPU, all threads | 5.5% of one core | 13% of one core |
| GC pauses during world generation | 1,010 ms | 686 ms |
| GC pauses during the creature phase | 215 ms | 142 ms |
| Startup, fresh world | 16.7 s | 14.8 s |
| Startup, existing world | 10.9 s | 10.5 s |
Idle. With nothing happening, Stratum's tick is about 0.6 ms longer and it uses 7% more of a single core, for its region bookkeeping and background metrics. That is under 2% of the tick budget. Nobody will notice it on an idle server, and on a busy one it is already included in the numbers above.
Garbage collection. Stratum allocates far less short-lived garbage: 112 gen-0 collections during world generation against vanilla's 350, and total pause time a third lower there and under creature load. It does trigger a few more full collections, which fits the larger heap.
Startup was 11% faster on a fresh world and about the same on an existing one. Both servers held the 30 TPS target throughout the standard test.
Should you run Stratum?
Yes, if your players regularly explore new terrain, or you have a lot of loaded chunks and creatures and you see periodic lag spikes. Faster world generation, a much shorter tail on tick time and roughly double the creature headroom are exactly what a busy server benefits from, and Stratum does it without changing the save format or the client.
The one thing to check is memory. A small, mostly idle server gains little from Stratum, but loses nothing either: the idle overhead is a rounding error. The only way Stratum makes a small server worse is a plan sized so tightly for vanilla that an extra gigabyte during world generation pushes it over.
Either way: give it an extra gigabyte of RAM compared with vanilla, expect it to use your whole CPU allocation while terrain generates, keep backups of your world, and test your mod list on a copy first. Stratum is API-compatible, but it patches the content assemblies, and a mod that Harmony-patches the same code paths can force Stratum back to the vanilla terrain pass.