<?xml version="1.0" encoding="utf-8" standalone="yes"?>
<rss version="2.0" xmlns:atom="http://www.w3.org/2005/Atom">
  <channel>
    <title>Posts on RollupDB.com</title>
    <link>https://rollupdb.com/posts/</link>
    <description>Recent content in Posts on RollupDB.com</description>
    <generator>Hugo</generator>
    <language>en-us</language>
    <lastBuildDate>Sat, 17 Oct 2026 00:00:00 +0000</lastBuildDate>
    <atom:link href="https://rollupdb.com/posts/index.xml" rel="self" type="application/rss+xml" />
    <item>
      <title>How RollupDB Was Tested With Killed Processes and an Outside Reference</title>
      <link>https://rollupdb.com/how-rollupdb-was-tested-with-killed-processes-and-an-outside-reference/</link>
      <pubDate>Sat, 17 Oct 2026 00:00:00 +0000</pubDate>
      <guid>https://rollupdb.com/how-rollupdb-was-tested-with-killed-processes-and-an-outside-reference/</guid>
      <description>&lt;p&gt;A database that throws data away on purpose had better be right about what it keeps. So RollupDB&amp;rsquo;s tests ask two questions over and over. Is the answer the same one you&amp;rsquo;d get from every raw reading? And does a write that was acknowledged survive the process dying, while one that wasn&amp;rsquo;t leaves no trace?&lt;/p&gt;&#xA;&lt;p&gt;All the numbers below come from one recorded run on a 4-CPU Linux machine in GitHub&amp;rsquo;s runners, Go 1.27.2. The script that made them and its full output are in the repository&amp;rsquo;s &lt;a href=&#34;https://github.com/rollupdb/rollupdb/tree/main/test/results&#34;&gt;test/results folder&lt;/a&gt;, so anyone can run it again and compare.&lt;/p&gt;</description>
    </item>
    <item>
      <title>RollupDB Adds SQL, Automatic Rollups and Streams That Can Change</title>
      <link>https://rollupdb.com/rollupdb-adds-sql-automatic-rollups-and-streams-that-can-change/</link>
      <pubDate>Sat, 17 Oct 2026 00:00:00 +0000</pubDate>
      <guid>https://rollupdb.com/rollupdb-adds-sql-automatic-rollups-and-streams-that-can-change/</guid>
      <description>&lt;p&gt;RollupDB 0.4.0 is out. Since the first release three things have been added, one per version: rollups that run on their own, stream definitions you can change after the fact, and a read-only SQL interface over the retained buckets. Each one came out of the same question: what does someone need on day thirty that they didn&amp;rsquo;t need on day one?&lt;/p&gt;&#xA;&lt;p&gt;The short answer is that people forget to run &lt;code&gt;advance&lt;/code&gt;, they find out their retention was wrong, and they want to ask questions the JSON query wasn&amp;rsquo;t shaped for. So now &lt;code&gt;rollupdb serve&lt;/code&gt; rolls up every stream once a minute, a stream can take a new version with different retention or an added sketch, and every stream is a SQL view.&lt;/p&gt;</description>
    </item>
    <item>
      <title>RollupDB Launches as an Open Source Database for Years of Statistics</title>
      <link>https://rollupdb.com/rollupdb-launches-as-an-open-source-database-for-years-of-statistics/</link>
      <pubDate>Sat, 17 Oct 2026 00:00:00 +0000</pubDate>
      <guid>https://rollupdb.com/rollupdb-launches-as-an-open-source-database-for-years-of-statistics/</guid>
      <description>&lt;p&gt;RollupDB 0.1 is out, under the Apache License 2.0. It&amp;rsquo;s an aggregate database in one file: you tell it which statistics matter, and it keeps those for years while it lets the raw events go. Seconds fold into minutes, minutes into hours, hours into days. A query a year later still gets the right count, the right extremes and a percentile with a stated error.&lt;/p&gt;&#xA;&lt;p&gt;The pitch is simple, and the numbers are what make it worth trying. In the recorded test, five years of readings from two services, 2.8 million of them, took 207 MB as raw JSON lines. The RollupDB file holding all of it was 15.4 MB, with seconds for the last day, minutes for the last day, hours for the last week and a bucket per day going back the full five years.&lt;/p&gt;</description>
    </item>
    <item>
      <title>What an Aggregate Database Keeps When the Raw Events Are Gone</title>
      <link>https://rollupdb.com/what-an-aggregate-database-keeps-when-the-raw-events-are-gone/</link>
      <pubDate>Sat, 17 Oct 2026 00:00:00 +0000</pubDate>
      <guid>https://rollupdb.com/what-an-aggregate-database-keeps-when-the-raw-events-are-gone/</guid>
      <description>&lt;p&gt;Most databases keep what you put in. An aggregate database doesn&amp;rsquo;t. It keeps what you&amp;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&amp;rsquo;s free to throw the individual readings away, because it already has what those readings were going to be used for.&lt;/p&gt;</description>
    </item>
    <item>
      <title>Why the Project Is Called RollupDB</title>
      <link>https://rollupdb.com/why-the-project-is-called-rollupdb/</link>
      <pubDate>Sat, 17 Oct 2026 00:00:00 +0000</pubDate>
      <guid>https://rollupdb.com/why-the-project-is-called-rollupdb/</guid>
      <description>&lt;p&gt;A rollup is what monitoring people have called this for decades. You take sixty one-second readings and roll them up into one minute. Then sixty minutes into an hour, and so on, until a year of data fits on a page. Spreadsheets do it with subtotals, OLAP cubes do it along their dimensions, and every metrics system that ever ran out of disk has done it to its old data.&lt;/p&gt;</description>
    </item>
  </channel>
</rss>
