Windrose SSD Disk Writes on Dedicated Servers: The RocksDB Write-Amplification Issue
One of the most discussed technical problems in early Windrose hosting has nothing to do with crashes, invite codes, or world corruption. It is about how much data the game writes to disk. Shortly after the Early Access launch, players and a few hardware-focused testers noticed that Windrose was writing an unusually large amount of data to storage during normal play. Tom's Hardware, PC Gamer, GameSpot, and others picked up the story, and the headline figure that circulated was up to 108 GB per hour of writes in the worst pre-patch case. Kraken Express responded quickly with patch 0.10.0.4 on April 30, 2026, which reduced the write rate substantially. For anyone running a Windrose dedicated server, this is worth understanding properly, because a server that is online around the clock writes far more total data over its lifetime than a casual single-player session ever will.
Fast Read
Windrose stores world state in a RocksDB-backed save system. Before the 0.10.0.4 patch it could write extreme amounts of data to disk. The patch cut in-game write rates by roughly 60 to 75 percent. However, community testing of a later build still measured a dedicated server writing tens of GB per hour even while idle. For most users this is a non-emergency, but for a 24/7 hosted world it is a real consideration. This is a software behavior, not a fault in your install or your drive.
What the issue actually was
Windrose runs on the R5 engine and persists world state into a RocksDB key-value store rather than into a single flat save file. Community analysis of the early build pointed to a configuration problem inside that save system: multiple RocksDB databases ran at once, and the world database was operating with a very small write-ahead log budget for the amount of state a survival sandbox constantly changes. The practical effect was write amplification. Small, frequent state updates were being committed to disk far more aggressively than necessary, and backup snapshots were piling up under the save profile folder. Several testers reported dozens of backup files clustered within a single minute on the worst pre-patch builds.
On a desktop running a short solo session, this mostly showed up as constant background disk activity. On a dedicated server that never stops, the same pattern compounds over days and weeks.
Where the writes land on disk
The save data and its backups accumulate under the R5 save profile tree. On a self-hosted Windows machine the path looks like this:
C:\Users\<username>\AppData\Local\R5\Saved\SaveProfiles\Default\
RocksDB\ (the live world database)
... (rotating backup snapshots)
This is the same save tree referenced in the Windrose save transfer and world recovery guide. The RocksDB folder is where the heavy write activity concentrates, which is why drive choice and backup retention both matter for a long-lived hosted world.
What the 0.10.0.4 patch changed
The fix shipped on April 30, 2026 was application-side rather than a change to RocksDB itself. In plain terms, the game was tuned to hold more data in memory and flush to disk less aggressively. The patch notes simply stated that disk usage during gameplay had been reduced, alongside fixes for idle-server CPU usage and connection problems. The measured result, reported by community testers and the press, was a write-rate reduction of roughly 60 to 75 percent. After the patch, in-motion writes were reported at around 10 to 16 MB/s, dropping below 1 MB/s when a character is standing still.
| State | Approx. write rate | Notes |
|---|---|---|
| Pre-patch, active play | up to ~108 GB/hour at worst | The widely quoted launch-era figure |
| Post-patch, in motion | ~10 to 16 MB/s | Roughly a 60 to 75 percent reduction |
| Post-patch, character idle | under ~1 MB/s | Near quiet when nothing is changing |
| Post-patch, dedicated server idle | ~35 GB/hour reported on one test | Server behavior differs from a paused client |
Why a dedicated server is a different case
The most important nuance for hosting is that a dedicated server does not behave like a paused single-player client. When you stop moving in single-player, writes drop to almost nothing. A dedicated server is different. One community test of a later build (reported as 0.10.0.5) measured a server writing roughly 69.6 GB over a two-hour idle window with no players connected, which works out to about 35 GB per hour while doing nothing useful. That is a large improvement over the worst pre-patch numbers, but it is still meaningful for a machine that is meant to stay online continuously.
This is not surprising in principle. A persistent server keeps the world simulation alive and continues to commit state even when no one is logged in. It is exactly the kind of always-on workload where total bytes written accumulate quietly in the background. None of this damages your world data or risks corruption. It is purely a question of how many bytes the storage device absorbs over time.
Perspective matters. A modern TLC NVMe SSD is typically rated for hundreds of terabytes of writes. At 35 GB/hour a server would take a very long time to approach that limit, and managed hosting providers run on hardware and storage tiers built for sustained write workloads. The concern is real but it is a slow-burn one, not a same-week failure risk.
How to measure it yourself
If you want to know what your own setup is actually doing rather than trusting headlines, measure it directly. The goal is to capture a clean baseline and a clean active number, then compare.
- Open Task Manager and watch the Performance tab for the drive while the server runs idle, then again with players online.
- On Windows, use a SMART-reporting tool such as CrystalDiskInfo to read the drive's total host writes. Note the value, wait a measured interval, and read it again to get a real GB/hour figure.
- Confirm you are attributing writes to Windrose specifically and not to other background software. Screen-capture tools and similar always-on utilities also write continuously, so isolate the game's process before drawing conclusions.
Measuring before and after a patch, or on your specific build, is far more reliable than extrapolating from a single viral number. Several of the loudest early estimates were back-of-envelope math that did not hold up once people tested carefully.
Practical guidance for hosting a Windrose world
You do not need to panic, but a few sensible choices reduce both wear and uncertainty:
- Stay current on patches. The 0.10.0.4 change was a large reduction, and the developers have signalled continued work on disk usage. Keep your server build up to date, following the safe update process so you do not break a build match with your crew.
- Prefer durable storage. A TLC NVMe drive handles sustained writes better than a budget QLC drive. This is a normal consideration for any always-on game server, not a Windrose-specific demand.
- Keep your backup set lean and intentional. Retain a few clear restore points rather than letting an unbounded pile of snapshots accumulate. See the backup and recovery guide for a sane structure.
- Consider stopping idle servers. If a private crew only plays on weekends, an always-on server is writing for nothing the rest of the week. A panel that lets you stop and start the world cleanly avoids pointless idle writes entirely.
- Do not over-react. A short solo or co-op session on a patched build is not a hardware emergency. The total writes only become notable on a server left running continuously for a long time.
What this is not
Heavy disk activity can be confused with other Windrose problems, so rule those out before assuming this is your issue.
- The server crashes after a day or two of uptime. That is a separate publisher-session problem, not disk wear. See the fatal crash after uptime guide.
- The server slows down over a long session. That is memory pressure, covered in performance decay and 32 GB RAM.
- The world fails to load after a restart. That is a world-state problem, not write volume. See stuck on loading screen and world load crashes.
FAQ
Will Windrose actually destroy my SSD?
Not in any realistic short timeframe on a patched build. At post-patch rates a modern SSD's rated endurance would take a very long time to reach. The concern is meaningful mainly for a server left running 24/7 over many months, not for normal play.
Did the patch fully fix it?
It fixed most of it for in-game play, reducing writes by roughly 60 to 75 percent. A later community test still measured a dedicated server writing tens of GB per hour while idle, so the server case is improved but not eliminated.
Does this happen on the client when I join someone else's server?
The heaviest writes are on the machine that holds the authoritative world, which is the host or dedicated server. A pure client that is only rendering and sending input writes far less than the host.
How do I check my own write rate?
Read your drive's total host writes with a SMART tool like CrystalDiskInfo, wait a measured interval, and read it again. That gives you a real GB/hour number for your exact build instead of relying on viral estimates.
Should I stop my server when no one is playing?
If your crew plays in bursts, yes. An idle server still commits world state, so stopping it cleanly between sessions avoids writes that produce no value.
Sources
- Tom's Hardware: Windrose excessive disk writing and the new patch
- PC Gamer: Windrose SSD lifespan and the fresh patch
- PC Guide: Windrose still has a disk usage problem after the fix (idle dedicated server test)
- Windrose Steam store page
Looking for managed Windrose server hosting? Supercraft runs Windrose dedicated servers on durable storage with daily backups, instant setup, and 5 region options, plus clean start and stop so an idle world is not writing for nothing. Plans from $5.99/mo.