RethinkDB
The realtime document database: JSON rows, ReQL chaining, and change feeds that push.
RethinkDB is a document database whose defining feature is push: clients subscribe to queries and the server streams result updates as data changes. ReQL embeds query construction in the programming language as chained expressions, storage uses append-friendly B-trees with MVCC snapshots, and the cluster shards and replicates tables automatically.
ReQL: queries as code
Queries are language-native chains (r.table().filter().map()) — composable, refactorable with the app, no string-building.
Changefeeds
Subscriptions on tables, filters, or unions stream every change to the result set — the realtime push that defined RethinkDB.
Automatic sharding and replication
Tables declare replicas and shards; the cluster balances, elects primaries, and handles failover without manual placement.
Geospatial queries
Native points, lines, polygons with intersections and near-queries — indexed with R-trees, not just lat/lon math in app code.
Queries that push
A changefeed is a standing query: subscribe once, and every insert, update, or delete that changes the result streams to the client. Dashboards, collaborative apps, and notifications drop from backend polling loops to a single subscription call.
Feeds compose with the query language — filter the feed, transform the output, union across tables. The server computes deltas, not full re-queries.
r.table('orders').changes().run(conn)
→ { old_val: {...}, new_val: {...} } per change
Storage and consistency
Tables shard across the cluster with per-shard B-tree storage; replicas elect a primary per table shard group. Writes acknowledge per write-acknowledgment settings and MVCC snapshots give consistent reads — the realtime push rides on the same MVCC versioning.
The project paused active development in 2020 but remains deployed and its realtime-push + ReQL design still teaches the pattern every subsequent realtime database adopted.
Diagrams
[caption] The push is the feature: standing queries stream deltas.
A write lands on the table primary, replicates to secondaries, updates indexes, and every subscribed changefeed receives the delta.
Each table shards across servers with configurable replicas; primaries elect per shard range.
[caption] Illustrative shard/replica layout for one table on a 3-server cluster.
Each table shards across servers with configurable replicas; primaries elect per shard range.