RethinkDB: changefeeds, a 2023 release, and a broken apt-get line

The last push was in March 2026 and the last release was in 2023

Two dates define this project's current state, and they are a long way apart.

The repository is not archived, and the last push was on 2026-11-01. The most recent releases are v2.4.4 from 2023-12-11, v2.4.3 from 2023-02-05 and v2.4.2, named Night Of The Living Dead, from 2022-05-07. So there has been a commit to the tree within the last few days and there has not been a release in close to three years.

Those two facts are not the same, and the difference decides what kind of project this is for you. The code is still being worked on, so bug reports and contributions are not landing in a tomb. But nobody is cutting releases, which means a fix in a commit does not reach you as a package, and upgrading means building.

The support channels tell the same story from a different angle. The README points at the community page on the project site, GitHub issues, Slack, Twitter, and IRC on Freenode. That list is the contact sheet of a project from the middle of the last decade, and a Freenode channel is not where a new contributor will find anyone today.

So: adopt it if you want the realtime model and are willing to run it. Do not adopt it because a vendor supports it.

The documented apt-get line swallows its own second half

The build section opens with a dependency install, and it does not work as written. Here is the block exactly as it appears:

    sudo apt-get install build-essential protobuf-compiler \
        # python \  # for older distros
        python3 python-is-python3 \
        libprotobuf-dev libcurl4-openssl-dev \
        libncurses5-dev libjemalloc-dev wget m4 g++ libssl-dev

A backslash at the end of a line continues the command onto the next one. The next line begins with a hash, so the shell treats the whole line as a comment. The net effect is that the continuation is consumed by the comment, the command ends after the first line, and the package list from python3 onwards becomes a second command that will fail on its own.

Paste this into a fresh Ubuntu or Debian machine and you get build-essential and protobuf-compiler installed, then an error, and a second half of the list that was never passed to the package manager. Nothing warns you that the list was truncated, which is what makes it worth knowing about before you spend an evening on a build failure.

The general list that follows in prose is the complete set: GCC or Clang, Protocol Buffers, jemalloc, Ncurses, Python 2 or Python 3, libcurl, libcrypto from OpenSSL, and libssl-dev. Note that it still says Python 2 or Python 3, which dates the document.

Pushing query results instead of polling is the entire idea

Everything else in this database follows from one sentence in the README. RethinkDB exposes a database access model in which the developer can tell the database to continuously push updated query results to applications without polling for changes.

That is the whole proposition, and it is a different shape from the query-then-refetch loop that dominates document stores. A query result is not a snapshot you fetch and throw away; it is a live cursor that stays open and emits changes as the underlying data moves. The README's own examples lean on it, including an IRC bot in Go built with changefeeds.

The advantages are real: no polling interval to tune, no wasted round trips when nothing changed, and a server that knows which results somebody is watching. The commitment is equally real, and it is worth being concrete about it. A live cursor consumes a server-side resource for as long as it is open, so a client that crashes without closing leaves work behind until the server notices. A consumer that restarts has to re-subscribe, and a long-running feed has to deal with a result set that is changing underneath it. None of that is a reason to avoid changefeeds. It is a reason to know that the simple query and the live query are two different animals in the same API.

What the design does not do is make the storage model unusual. It stores schemaless JSON documents, which is the part every competitor shares.

Four official drivers, and TypeScript is not one of them

The driver story is precise and worth checking before you commit, because the query language is the thing being bound, not just a socket.

There are four official drivers with ten-minute guides: JavaScript, Python, Ruby and Java. Alongside them the README lists community drivers for nine more languages: two for C# and .NET, plus C++ with librethinkdbxx, Clojure, Elixir, Go with GoRethink, Haskell, PHP, Rust with reql, and Scala.

So thirteen languages in total, four of them with first-party drivers. The language the database is written in, C++, is not among the official four, and TypeScript is not named at all. If your codebase is TypeScript, the JavaScript driver is the obvious starting point, and the community list is where you look next. That is not a criticism so much as a fact about a project whose four-language core predates the current mainstream.

Two other details follow from the design. The query language is ReQL, with its own API documentation page separate from the docs, which means a driver is a binding for a whole language rather than a thin wrapper over SQL. And the quickstart is a thirty-second tour on the project site, with the language guides as the next step, so the intended order is: see it run, then pick your language.

The root Makefile is a shim that hands the build to mk/main.mk

The build system is two files, and the one you land on is the smaller one. The root Makefile says so in its own comments: build instructions are on the project website, there is more in mk/README, and this file sets up the environment before delegating to mk/main.mk.

What it does before delegating is more interesting. It tests for a GNU Make feature to enforce a floor:

ifeq (,$(filter else-if,$(.FEATURES)))
	$(error GNU Make >= 3.8.1 is required)
endif

The `else-if` conditional is how you probe which Make you are running, so a BSD make or an old GNU Make fails immediately with a named requirement rather than a syntax error three files later. That is a well-chosen failure mode, and it also means this build is not portable to make variants.

Then it reconstructs paths, collapsing the relative `../` segments that appear when a build is started from a subdirectory, and assembles the real command line: make with the target makefile in mk/, plus --no-print-directory, --warn-undefined-variables, --no-builtin-rules and --no-builtin-variables, passing TOP and CWD through explicitly.

Two consequences. Reading the root Makefile tells you nothing about the available targets, because the targets live in the other file. And --warn-undefined-variables means a misspelled variable produces a warning instead of silently expanding to an empty value, which is exactly the behaviour you want in a build this layered. The copyright header at the top of the file dates from 2010 to 2013, which is the era the system was designed in.

A write delay of infinite gives you a memory-only table

The donor list at the end of the README contains one of the more unusual features in any database, credited to a specific pull request.

ZeroTier sponsored the development of per-table configurable write aggregation, including the ability to set a write delay to infinite to create a memory-only table, in pull request 6392. So in this database, durability is a per-table decision: a table can be configured to buffer writes and flush them on an interval, or configured never to flush, in which case the data lives in memory only.

That is genuinely useful and it is a sharp edge. For caches, derived indexes, realtime fan-out state and anything you can rebuild, a memory-only table is the right tool and costs you no disk writes. For anything you would be upset to lose, misconfiguring that delay is silent until the process stops.

The rest of the donor list describes what the project depends on rather than what it does, and it is worth reading in that light. Digital Ocean provides the infrastructure behind download.rethinkdb.com and update.rethinkdb.com, which means where you fetch builds from rests on a sponsor's account. Atlassian provides the licence that lets the project run its internal vulnerability tickets, and Netlify the one that let it migrate rethinkdb.com. DNSimple handles DNS, and CNCF is listed as a donor.

None of that is a criticism. It is a reminder that a foundation-run project of this age is held together by donated services, and that the fastest way to find out what is still running is to read the support list.

Apache 2.0 with portions under other licences, and no Dockerfile at the root

The licensing statement is more careful than a single licence line, and it explains why the repository's licence field carries no standard identifier.

RethinkDB is licensed by the Linux Foundation under the open-source Apache 2.0 license, and the next sentence says portions of the software are licensed by Google and others and used with permission or subject to their respective license agreements. There is a COPYRIGHT file at the root of the tree for the detail. If you redistribute a build, the file to read is that one, not the Apache 2.0 label.

The repository layout tells you what a build produces and what is missing. There is a configure script, the mk/ build system, src/, test/, demos/, external/ for vendored dependencies, packaging/ for distribution packages, scripts/, and a snap/ directory for the Snap package. WINDOWS.md and mk/README.md cover Windows and FreeBSD builds, which tells you the instructions in the README are the Unix ones and the others are documented separately.

There is no Dockerfile at the top level. That matters more than it sounds, because container installs are a common way to try this database. The packaging routes the repository does document are system packages and a Snap, so a container recipe is something you will be assembling yourself rather than copying from here.

And the changelog is NOTES.md, a hand-maintained file of changes and feature explanations. For a project whose newest release is from December 2023, that file is where you find out what actually happened, because the release page will not tell you much.

Editorial conclusion

RethinkDB fits a realtime application that wants query results pushed rather than polled and is prepared to own the operational side of a C++ database, because the changefeed model is a real architectural advantage and there is no substitute for it in a document store that does not push. Do not adopt it expecting an active release cadence: the last push was on 2026-11-01 and the last release was v2.4.4 on 2023-12-11, so budget for running the code yourself rather than upgrading into fixes. Check your language against the driver list before committing, since the four official drivers are JavaScript, Python, Ruby and Java and TypeScript is not among them. Read COPYRIGHT rather than assuming a single licence, since the project states Apache 2.0 with portions licensed by others. And if you build from source, fix the dependency command first: as written, a backslash and a comment swallow the second half of the package list.

Frequently asked questions

Official sources

1. Issues
2. Project website
3. README
4. Releases
5. rethinkdb/rethinkdb on GitHub