Dropping fsync: How We Made Storage Faster and a Bit Riskier

Developers at Fractal Bits shared their journey of removing fsync from their local storage engine. If you've ever waited for a database to sync to disk, you know the pain — fsync can be a real drag, especially on cloud volumes. The team decided that for their use cases, data consistency isn't as critical as speed, so they simply turned off synchronization. The result? A performance boost of several times. But as they say, no pain, no guarantees.

What is fsync and why you might want to kill it

fsync is a system call that forces the OS to flush buffers to disk. Without it, data can linger in memory like socks in a dryer and vanish on a power outage. But if you're dealing with temporary data or can afford losing the last few writes, ditching fsync gives a huge speed gain. Fractal Bits went all in and removed it entirely, relying on their application to rebuild state after a restart.

What about safety?

Of course, this isn't for everyone. If you're writing a banking system or medical records, don't try this at home. But for analytical databases, caches, or logs — why not? The developers note they added extra integrity checks and use journaling to minimize risks. In the end, their engine runs like a Ferrari without brakes — fast and thrilling.

Our take

Fractal Bits' story is a great example of trading strict guarantees for speed when you know your requirements. But before replicating, make sure your boss won't ask you to recover data from a backup on a Friday evening.

METABYTE studio comment: If your database starts to feel like Russian roulette, maybe it's time to rethink the architecture. We help you balance speed and reliability so you don't wake up in a cold sweat after a late-night deploy.