We’ve been actively recruiting for four months now, and if there is one thing we’ve learned, it’s that Jeff Atwood wasn’t kidding about FizzBuzz.

Among our friends in the startup community, RethinkDB has the rep for having the toughest interview process on the block. And it’s true - the interview process is something we won’t compromise on. We’re prepared to turn away as many people as it takes to build a superb development team. We wrote that much in an earlier post. In the past few months we ran into people that thought we have ridiculously high standards and are hiring rocket scientists who also double majored in quantum mechanics and computer science. We don’t. We just won’t hire programmers that can’t code.

There are two types of non-blocking thread synchronization algorithms - lock-free, and wait-free. Their meaning is often confused. In lock-free systems, while any particular computation may be blocked for some period of time, all CPUs are able to continue performing other computations. To put it differently, while a given thread might be blocked by other threads in a lock-free system, all CPUs can continue doing other useful work without stalls. Lock-free algorithms increase the overall throughput of a system by occassionally increasing the latency of a particular transaction. Most high- end database systems are based on lock-free algorithms, to varying degrees.

By contrast, wait-free algorithms ensure that in addition to all CPUs continuing to do useful work, no computation can ever be blocked by another computation. Wait-free algorithms have stronger guarantees than lock-free algorithms, and ensure a high thorughput without sacrificing latency of a particular transaction. They’re also much harder to implement, test, and debug. The lockless page cache patches to the Linux kernel are an example of a wait-free system.

We were honored to give a closing keynote talk at MySQL Conference & Expo 2010, and wanted to share the video with you. Why start a new database company? What is RethinkDB all about? What will database technology look like twenty years from now? In this talk we explore these questions, present some of the exciting technology we’ve been developing at RethinkDB, and show how it fits into our larger vision of what database systems may look like in the future.

2010 will be an incredibly exciting year for database technology. The amount of stored information has long been increasing exponentially, presenting unprecedented challenges for modern technology companies. Dropping RAM prices and affordable multicore CPUs have drastically changed the hardware profile of a typical server machine from what it was only five years ago. The emergence of solid-state drives is about to revolutionize database systems, enabling new kinds of applications we can barely envision today.

April Fools! We aren’t switching to Lisp (as much as we love the language). We couldn’t resist having a bit of fun.

Over the past few months we’ve had many architectural discussions about the future of database technology. It quickly became apparent to us that C++, the language we used to develop RethinkDB, is not sufficiently expressive to build the next-generation database product. We realized that in order to design the database system of the future, we need to use a programming language of the future as well.