Thanks to Etienne Laurin, there is now a Haskell client for RethinkDB: check out the release announcement on Haskell-Cafe.

The first version of the protocol definition is arcane and undocumented (a new spec proposal is in the works), so he took on the daunting task of reverse engineering the existing published drivers. Etienne and is the first community member to release a RethinkDB community driver.

Note: this is a blog post from November 2012, and much of the information here is outdated. RethinkDB has official packages for Ubuntu, Centos, Debian, and OS X (both prebuilt and via Homebrew); current versions of RethinkDB use a JSON-based protocol rather than Protobufs; in addition to the official client drivers for Python, Ruby and JavaScript, we have community-supported drivers for a variety of languages including C#, Clojure, Dart, Go, Haskell, Java, Lua, Perl, PHP and Scala; RethinkDB has geospatial support; and while RethinkDB supports “upserts,” the insert command now uses a different syntax.

We received a lot of questions in past few days since our release. While my colleagues are busy expanding support for other Linux distros, squashing bugs, and improving the documentation), I thought I’d use this time to answer some of the most common questions we received.

The challenge

Follow the installation instructions to set up the server. Then, in a language of your choice, write an automated fuzzer that sends randomized traffic to the database server with the purpose of discovering a crash. The fuzzer can use rethinkdb admin to reshard or replicate the database, one or more rethinkdb clients to send randomized queries, direct TCP access to send faulty traffic to the server, or a combination of approaches. We will consider all candidates whose fuzzer manages to expose a server crash.

There are many exciting database products that make developing scalable applications much, much friendlier and easier. After three years of work, our humble contribution to the field is out. RethinkDB is built to store JSON documents, and scale to multiple machines with very little effort. It has a pleasant query language that supports really useful queries like table joins and group by, and is easy to setup and learn.

A central challenge in developing a high performance database is to maximize the efficiency at which hardware resources are used. By implementing a new optimization in how RethinkDB handles disk writes - the patch log - we were able to achieve an additional 50% increase in query throughput. The following graph compares the sustainable performance of RethinkDB for a mixed read/write workload (roughly 10% write operations) with and without the patch log. In both cases we configured the system to be bound by the disks’ write bandwidth.