https://rollupdb.com/tags/how-it-works/ Recent content in How It Works on RollupDB.com Hugo en-us Sat, 17 Oct 2026 00:00:00 +0000 https://rollupdb.com/how-rollupdb-was-tested-with-killed-processes-and-an-outside-reference/ Sat, 17 Oct 2026 00:00:00 +0000 https://rollupdb.com/how-rollupdb-was-tested-with-killed-processes-and-an-outside-reference/ <p>A database that throws data away on purpose had better be right about what it keeps. So RollupDB&rsquo;s tests ask two questions over and over. Is the answer the same one you&rsquo;d get from every raw reading? And does a write that was acknowledged survive the process dying, while one that wasn&rsquo;t leaves no trace?</p> <p>All the numbers below come from one recorded run on a 4-CPU Linux machine in GitHub&rsquo;s runners, Go 1.27.2. The script that made them and its full output are in the repository&rsquo;s <a href="https://github.com/rollupdb/rollupdb/tree/main/test/results">test/results folder</a>, so anyone can run it again and compare.</p> https://rollupdb.com/what-an-aggregate-database-keeps-when-the-raw-events-are-gone/ Sat, 17 Oct 2026 00:00:00 +0000 https://rollupdb.com/what-an-aggregate-database-keeps-when-the-raw-events-are-gone/ <p>Most databases keep what you put in. An aggregate database doesn&rsquo;t. It keeps what you&rsquo;ll ask about later, and only that. You tell it up front: for this stream of latencies, I want the count, the sum, the min and max, the mean, the variance and the 99th percentile, grouped by service. Then it&rsquo;s free to throw the individual readings away, because it already has what those readings were going to be used for.</p>