We're incredibly excited to announce that Akiban has been acquired by FoundationDB. Together we are closing the gap between SQL and NoSQL in our quest to disrupt the database market.

Read more in our blog post →

Posted by .

We’re excited to announce that Akiban has been acquired by FoundationDB.


We are joining FoundationDB to build a scalable SQL/NoSQL system, fusing the benefits of NoSQL, namely horizontal scale and simpler data models, with the advantages of relational – ACID guarantees and the expressive SQL query language. We are expecting to release the Akiban SQL layer on top of FoundationDB very soon.

A few months ago, we started working with FoundationDB’s team and product. We were extremely impressed. Less than three days into it we had a few instances of our SQL/object engine running directly on top of a FoundationDB cluster as our storage backend. We were looking at an incredible opportunity.

We dug deeper. FoundationDB is a four-year-old startup that built a second generation K/V store: A fault tolerant, scalable, and transactional – ordered K/V store that packs impressive performance. There are three “firsts” here:

  1. The first “first” is that these guys take fault tolerance seriously – FoundationDB is built using a concurrent language called Flow and a unique simulation technology that uses Flow to simulate in testinga large range of software and hardware failures, including network partitions. It’s this combination that make it possible to handle the complexity and sheer amount of simulation needed to verify that the system is resilient in every single dimension of failure.

  2. A second “first” is the transactional nature of the system. The FoundationDB architecture separates the different subsystems for storage, logging, transaction management and interface, making each independently scalable and testable. Specifically impressive is the approach to scaling transaction processing. It introduces completely new ideas in this realm that make it possible to spread transaction processing and conflict detection across nodes in a scalable and fault tolerant fashion.

  3. The third “first” is the ordered nature of the system. FoundationDB is not a hash table like so many other K/V stores such as memcache or Riak. Foundation keeps keys ordered making scans possible and highly efficient. This may sound like a small capability compared to the scale, fault tolerance or transactionality of FoundationDB – but it is probably as hard to achieve. The ordered nature means that indexes can be created and queries can run against FoundationDB, yes – even SQL. The only other K/V system of any size that is ordered is hbase, but it is seriously lagging behind foundation in terms of data consistency, transactions, performance or flexibility of data modeling.

FoundationDB represents a real advance beyond what first generation K/V stores provide. And that is where the fit with our own technology becomes so interesting.

Akiban SQL capabilities are a perfect fit for such a storage layer. Akiban thinks about objects (Table-Groups in our lingo) and stores them as a set of nested flat relational rows and stores them clustered together, like an object. So for example a customer is stored with it’s orders, items, etc as a hierarchy of rows. This structure has several advantages:

  1. First, it allows for a sophisticated query optimization and execution model. Because objects are no longer fragmented into physical tables joins between logical rows within an object become free – joining a customer row with his orders rows is a free sequential operation without the usual join latencies. An algebra and optimizer unique to Akiban executes the queries without incurring joins. With FoundationDB as our storage layer, this join elimination becomes an even bigger advantage, eliminating latencies we would otherwise incur accessing the FoundationDB substrate over the network.

  2. Second is our ability to access objects directly through a REST API. Because an object is stored as a set of sequential rows, a single request can get all of it. The same locality is true for writing or updating an object, say through an ORM. Running on top of the FoundationDB substrate, this yields automatic benefits because the FoundationDB’s client will route the request to the correct storage node for pretty seamless scale. Without Akiban’s automatic collocation, it would be hard to ensure that the related data stays together for efficient access.

The combined magic is that Akiban’s collocation of data and latency elimination are a perfect fit for FoundationDB’s over-the-network massively scalable storage. Our stack has become a stateless interface into an incredibly powerful backend.

The promise to scale the database as easily as scaling web-servers is here. To learn more check out our Founder’s blog and FoundationDB’s blog. To get involved and try it out please visit the website and sign up for the early adopter program.