RethinkDB: the push-based document database, and what its maintenance record means for adoption

The problem RethinkDB solves: live query results without a polling loop

Most databases answer a query and stop. If an application wants to know that a row changed, it polls on a timer, or it runs a separate message broker and writes the fan-out logic itself. RethinkDB takes the position that the database should hold the subscription. The README describes it as the first open-source scalable database built for realtime applications, exposing a model where the developer tells the database to continuously push updated query results to applications without polling for changes.

The audience follows from that. This is for teams building collaborative editors, live dashboards, chat-like interfaces and activity feeds, where the state a client displays is a query result that keeps changing. The README points at examples including a realtime liveblog, a collaborative photo sharing whiteboard, an IRC bot in Go, and watching Instagram cats in realtime. The underlying storage is schemaless JSON documents, so the shape of a record is the application's problem rather than the database's.

It is a distributed system with automatic failover, and it is a NoSQL store, both of which the README states plainly. What it is not is a general-purpose replacement for a relational database with strong multi-table transactional semantics as the primary design goal. The pitch is narrower than "a database": it is a database whose distinguishing feature is the push model.

How the changefeed mechanism works and what the ReQL layer sits on

The mechanism is a changefeed attached to a query. Instead of the client issuing a read and receiving a finite result set, it registers interest in a query and the server sends updates as the underlying data changes. That inverts the usual data flow: the application holds an open stream per subscription, and the write path on the server is responsible for evaluating which subscriptions are affected.

Queries are written in ReQL, the project's query language, documented at the ReQL API page linked from the README. ReQL is the layer that makes the push model usable, because a feed is attached to a query expression rather than to a raw table, which means filtering and transformation happen server-side before results reach the client. The README's ten-minute guides exist for JavaScript, Python, Ruby and Java, and those four are the official drivers. Everything else, including C#, C++, Clojure, Elixir, Go, Haskell, PHP, Rust and Scala, is a third-party driver maintained by the community, which is a meaningful distinction when you are choosing a language.

The server itself is written in C++ and built with a make-based system. The top-level Makefile is a thin wrapper: it computes the source tree root, then delegates to mk/main.mk, with additional build documentation in mk/README.md. On the storage side, the README credits ZeroTier with sponsoring per-table configurable write aggregation, including the ability to set a write delay to infinite to create a memory-only table. That is a real knob and it tells you something about the design intent: the project is willing to trade durability for write throughput on a per-table basis.

Building RethinkDB from source on Debian or Ubuntu

The README gives a build path rather than a package-manager one-liner for the server itself. On Ubuntu or Debian, the dependency list is explicit:

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

After the dependencies, configure and build. The --allow-fetch flag lets the build download what it needs, and you can select Clang instead of GCC at configure time:

./configure --allow-fetch
make -j4
sudo make install

The README notes that make -j4 DEBUG=1 produces a debug build, and that you can run the binary from the build tree directly at ./build/debug_clang/rethinkdb instead of installing. If you are on Windows or FreeBSD, the README redirects you to WINDOWS.md and mk/README.md rather than covering those platforms inline.

For a first real use, the quickstart is the place the project points you: rethinkdb.com/docs/quickstart for a thirty-second version, or the ten-minute guides per language. A typical first exercise is to open a table, insert a document, and then attach a changefeed to a filtered query so you can watch the feed emit when the matching document changes. The README does not spell out that sequence itself; it delegates to the guides.

Running RethinkDB in Docker and the port question

The README does not document a Docker workflow. There is a packaging/ directory and a snap/ directory in the repository, which tells you the project ships packaging definitions, but the README's own instructions are the source build plus the links to rethinkdb.com. If you want a container, the honest position is that the repository layout suggests packaging exists and the README is silent on the exact image, tag or command.

The same caution applies to the network port. RethinkDB's driver port is commonly discussed as 28015, and the web administration interface on 8080, but neither number appears in the README text. Do not copy a port from a blog post into a firewall rule without confirming it against the project's own documentation, because the client port and the cluster port are different things and mixing them up produces connection errors that look like authentication failures.

What the README does give you is the community channel: Slack, Twitter, and IRC at #rethinkdb on Freenode. For a project of this age, the community channel is often where the operational details live rather than in the repository.

The maintenance question: a 2023 release and a 2026 push

This is the part that decides most adoption conversations, so it is worth being precise. The most recent release listed is v2.4.4, dated 2023-12-11. Before that, v2.4.3 on 2023-02-05 and v2.4.2 on 2022-05-07. The repository is not archived, and the last push was on 2026-03-28, so work is happening in the tree. But a push is not a release, and the gap between the newest tagged release and the current date is the number a team should be looking at when it plans upgrades.

The practical consequence is that you should treat RethinkDB as a stable, slowly moving dependency rather than one that will hand you fixes on demand. If you hit a bug in v2.4.4, the path is the issue tracker and, potentially, building from main. The README's build instructions make that feasible, but running an unreleased build in production is a different risk posture from running a tagged release, and the project does not document a supported upgrade path from a source build to a release.

There is also the licensing wrinkle. The README states that RethinkDB is licensed by the Linux Foundation under the Apache 2.0 license, with portions licensed by Google and others under their respective agreements. The repository metadata, by contrast, reports NOASSERTION, meaning the automated classifier could not confirm a licence. Those two statements are not contradictory, but they mean you should read COPYRIGHT and the licence files yourself rather than trusting a badge. This is not legal advice; it is a note that the two signals disagree.

When RethinkDB is the wrong tool

If your application is a conventional CRUD system with occasional reporting, the changefeed machinery is cost you are not using. A relational database gives you joins, constraints and a mature migration story that RethinkDB does not position itself around, and the schemaless document model means schema discipline is your responsibility rather than the database's.

If you need a relational model with real foreign keys and ad-hoc SQL, this is the wrong choice. If you need a mature ecosystem of managed hosting and a large body of operational tooling, the README's own framing as a community-supported project with Slack and IRC as the help channels is a signal about where support comes from. And if your team's tolerance for running a source build is low, the release cadence is a real constraint rather than a hypothetical one.

There is also a subtler failure mode. A push model means the server is doing work per subscription. The README does not document subscription limits, backpressure behaviour, or what happens when a client cannot keep up with a feed. Those are exactly the questions you need answered before putting a feed in front of a large number of concurrent clients, and the README does not answer them.

Alternatives and how their approach differs

The most direct comparison is with MongoDB, which is the other schemaless JSON document store that people reach for first. MongoDB's model is request and response: you query, you get a result, and change notification is a feature layered on top rather than the organising principle. RethinkDB's organising principle is the feed. If your application is fundamentally about watching a query change, the two are not equivalent even though both store documents.

Against PostgreSQL, the difference is sharper. PostgreSQL is a relational database with a mature query planner and a very long operational history; its approach to realtime is to notify on channels and let you build the fan-out yourself. RethinkDB does the fan-out in the database. If you need joins and constraints, PostgreSQL wins on capability. If you need a filtered query result streamed to many clients, RethinkDB removes a whole tier of code.

Against Redis, the difference is durability and query model. Redis is an in-memory data structure store with pub/sub, and pub/sub there is fire-and-forget messaging rather than a query subscription. RethinkDB evaluates a ReQL query and pushes its results, which means the client receives state rather than events. That distinction matters for reconnection: a state stream can be reconciled, an event stream cannot be replayed unless you built that yourself.

Firebase is the closest in spirit, since it also pushes data to clients. The difference is deployment: Firebase is a hosted service, and RethinkDB is software you run. If you want someone else to operate the push infrastructure, that is a different trade.

Upgrade cost and what to verify before you commit

Upgrading means building. The README's path is ./configure --allow-fetch, make -j4, sudo make install, and the dependency list includes protobuf, jemalloc, ncurses, libcurl and OpenSSL. That is a build toolchain you need to keep working, and it is a heavier upgrade story than pulling a new container tag. The repository does contain packaging/ and snap/ directories, so packaged distribution exists in some form, but the README does not document it.

The upgrade cadence is the other cost. With the newest release at v2.4.4 from 2023-12-11, planning an upgrade means watching for a tag rather than expecting one. If your organisation requires a supported release channel with a vendor behind it, the README does not describe one; it describes a Linux Foundation project with community channels.

On licensing, the README says Apache 2.0 under the Linux Foundation, with portions under other agreements. The repository metadata says NOASSERTION. Read COPYRIGHT and the per-directory licence headers before you ship, particularly if you are redistributing a modified build, because the portions under other agreements may carry obligations the Apache 2.0 text alone does not describe.

Editorial conclusion

Adopt RethinkDB when the changefeed model is the point of your application and you can pin a released version such as v2.4.4. Do not adopt it if your roadmap depends on frequent upstream releases or on a vendor support contract, because the newest release listed is from 2023-12-11 even though the repository was pushed to on 2026-03-28. Before committing, verify the licence text in the COPYRIGHT file and the license field the project uses, since the repository metadata reports NOASSERTION while the README states Apache 2.0.

Frequently asked questions

Official sources

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