<?xml version="1.0" encoding="utf-8" standalone="yes"?><rss version="2.0" xmlns:atom="http://www.w3.org/2005/Atom"><channel><title>Database Systems on The Coders Blog</title><link>https://thecodersblog.com/categories/database-systems/</link><description>Recent content in Database Systems on The Coders Blog</description><generator>Hugo</generator><language>en-us</language><lastBuildDate>Sat, 09 May 2026 15:58:12 +0000</lastBuildDate><atom:link href="https://thecodersblog.com/categories/database-systems/index.xml" rel="self" type="application/rss+xml"/><item><title>Boosting Performance: Removing fsync from Local Storage</title><link>https://thecodersblog.com/removing-fsync-from-local-storage-engine-2026/</link><pubDate>Sat, 09 May 2026 15:58:12 +0000</pubDate><guid>https://thecodersblog.com/removing-fsync-from-local-storage-engine-2026/</guid><description>&lt;p&gt;Performance gains can be substantial when understanding and carefully tuning low-level I/O operations.&lt;/p&gt;
&lt;p&gt;For decades, &lt;code&gt;fsync()&lt;/code&gt; has been the bedrock of data durability in POSIX-compliant systems. It’s the grumpy gatekeeper of your data, ensuring that everything you’ve written isn&amp;rsquo;t just sitting in some volatile memory buffer, waiting to vanish with the next power hiccup. This unwavering commitment to safety, however, comes at a steep performance cost. For applications where raw speed is paramount, especially within custom storage engines, the question isn&amp;rsquo;t &lt;em&gt;if&lt;/em&gt; &lt;code&gt;fsync()&lt;/code&gt; is a bottleneck, but &lt;em&gt;how profoundly&lt;/em&gt; it cripples throughput. We&amp;rsquo;re going to dive deep into the mechanics of bypassing this stubborn API for local storage, understanding the trade-offs, and identifying the specific scenarios where this aggressive optimization is not just viable, but potentially revolutionary.&lt;/p&gt;</description></item></channel></rss>