rrdtool 1.x is the round robin database that predates modern time series stores

A fixed size file that never grows

The core idea of RRDtool is a database of time series data that is maintained rather than accumulated. The README describes it as a little program for easily maintaining a database of time-series data, and it explains the problem it solves: it is pretty easy to gather status information from all sorts of things, ranging from the temperature in your office to the number of octets which have passed through the FDDI interface of your router, but it is not so trivial to store this data in an efficient and systematic manner. The answer is a circular file. The data you collect is written into a preallocated file, and as new samples arrive the oldest ones are overwritten, so the file size is chosen once when the database is created and the retention period follows from the data source interval and the consolidation policy. That fixed size is still the reason many monitoring stacks keep RRDtool files around.

The charting side is half the project

The tool does not come as a library with a separate front end, it comes with a charting program for drawing pretty graphs based on the data stored, and the data analysis part of RRDtool is based on the ability to quickly generate graphical representations of the data values collected over a definable time period. That combination is the reason the project is described as a tool rather than a format. The graph is the interface: you ask for a time range and a consolidation function, the tool walks the ring buffer and produces an image or an XML document, and everything from a dashboard to a PDF report is built on that. The examples directory in the repository shows the range of consumers, with Perl scripts for four charts, big tops, min and max, piped data and shared data, a Python example, a CGI demo and a `rrdcached/` directory, so the tool is expected to be driven from scripts rather than called by hand.

The build is autotools, and the docs are pod files

The source tree is the classic GNU layout, with `configure.ac`, `Makefile.am`, `m4/`, `conftools/`, a `bootstrap` script and a `debian/` directory, which means building it on an unusual platform is a matter of having the autotools installed rather than a modern build system. The compile instructions point at `doc/rrdbuild.pod`, a Perl POD document, and the general documentation also lives in the `doc/` directory as pod files, which is why the contributing guidance asks that new features come with an update to the documentation pod files. The same convention appears in the tutorial material: Alex van den Bogaerdt's rrdtutorial for a slower introduction, his cdeftutorial, and Steve Rader's rpntutorial, all of which are said to be available from the doc directory. The format of the data files themselves is documented in `src/rrd_format.h`, which the README points to and describes as having a lot of comments in it.

Bindings and a cached daemon live in the same tree

Three directories in the repository point at the parts of the project that are less obvious. The `bindings/` directory holds the language bindings, which is how a Perl, Python, Ruby or PHP program ends up manipulating RRDs without shelling out to the command line tools. The `examples/rrdcached/` directory is about the caching daemon, a separate program that keeps the round robin files open and serves the graph requests, so that a large number of clients asking for the same graph do not each have to open and read the file themselves. And the `etc/` directory holds the packaged configuration. The `po/` directory carries the translations, and the `win32/` directory with `WIN32-BUILD-TIPS.txt` and an MSYS2 build script in the root shows that Windows is built through that route rather than through the autotools path. The `tests/` directory and a `.travis.yml` alongside GitHub Actions workflows for Linux builds show the test coverage is tracked with codecov.

This branch is for maintenance, not for new features

The contributing section is explicit about where work goes. Contributed feature and bug patches are most welcome, and since rrdtool lives on github it is now very easy to create pull requests. Work from the master branch unless you are creating bugfixes, and no new features should go into the 1.2, 1.3 and 1.4 branches. If you contribute new features, make sure to also update the documentation pod files. So the 1.x line is the maintenance line, and new functionality goes elsewhere. The release history is consistent with that: v1.11.0 came out on 2026-08-07, v1.10.3 on 2026-05-25 and v1.10.2 on 2026-05-19, so the branch is still being released at a decent pace, and the last push to the master branch was on 2026-08-07 as well. The most recent released version is stated to be always available from the maintainer's own download site.

Three mailing lists for three audiences

The project organises its community into three lists, and the split tells you where a question belongs. `rrd-announce` is a low volume announcements list for stable releases only, `rrd-users` is for discussion amongst people who use RRDtool in their applications, and `rrd-developers` is for people who actually hack the code. One cross-posting rule is stated: postings to rrd-announce will always be cross-posted to rrd-users and rrd-developers as well, so an announcement reaches everyone but a discussion does not. To subscribe you send a message with the subject subscribe to the relevant list request address. The author is Tobias Oetiker, and the licence is GPL 2.0, with the copyright, contributors and changes files all in the repository root alongside a `THREADS` file that presumably documents the threading model the code uses.

Editorial conclusion

Adopt RRDtool 1.x if you are maintaining something that already depends on it, since the file format and the command line interface are the contract and the 1.x line still ships releases. Do not adopt it for a new time series project if you need to query across arbitrary time windows or store irregular data, because the round robin model fixes the retention at creation time and assumes regular intervals. Verify first which version your existing installation uses, since the file format has changed across the 1.x line, and read src/rrd_format.h before you write anything that parses the files directly.

Frequently asked questions

Official sources

1. License: GPL-2.0
2. oetiker/rrdtool-1.x on GitHub
3. Project website
4. README
5. Releases