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 →

Akiban is acquired by FoundationDB

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.

Backbone On Akiban

Posted by .

Backbone.js is a popular library for creating Javascript based web applications. It comes with REST based persistence support built-in and works great against Akiban.


Todo? Why Not!

A nice and simple todo application is the Hello, World of the web frameworks. Backbone’s has one that lives in their main repo (demo, code) and hits all the salient points: simple, functional, and well documented.

HTML5 based localStorage is use to keep the items around past a refresh. With a trivial amount of work, we can have that talking to Akiban instead.

The backbone-todo-akiban GitHub repo goes along with this post. As a starting point, the base-example tag has the LocalStorage portion removed.


Interlude: CORS and Authentication

In the ever evolving world of web applications and services, sometimes user and server security can butt heads in unexpected ways. A web app that talks directly to a database, often called a two-tier architecture, is a relatively new and fun way to develop. It takes the web server out of the equation and generally keeps things quite simple.

Basic authentication is an old stand by for HTTP based authentication and still has plenty of usage when used across an SSL connection. In fact, this is the default mode Akiban Server. A newer technology for ensuring browser side safety is called Cross-Origin Resource Sharing, shortened to CORS, and makes sure client side code doesn’t request something from somewhere it shouldn’t.

Unfortunately, these two don’t exactly play well together! There is a great blog post from Kinvey that talks about the catch-22 when CORS meets authentication, basic or otherwise. I won’t repeat any of that content here, but a recent commit on Akiban Server resolved our handling of the problem.


Database Model

The model contains three fields. A string and a boolean, for the title and done flag, along with an integer for the entry id.

I’ve created a public DataSpace that you can copy to get started. The repo also has two files, added in the model-def tag. The model.json file can be applied RESTfuly through the model resource or model.sql can be created through SQL. These are just two ways to represent the same underlying entity definition.


Connecting to Akiban

Two small tweaks, found in the sync-akiban tag, are needed.

The first is related to the CORS and authentication issue noted above. We must pass another flag to jQuery.ajax which we can do by overriding the Backbone.Sync method.

  var backboneSync = Backbone.sync;
  Backbone.sync = function(method, model, options) {
    _.defaults(options || (options = {}), {
      xhrFields: { withCredentials: true }
    backboneSync(method, model, options);

The second is to set the default URL for the Todos collection.

  url: "http://db1.akiban.com:8091/v1/entity/todos",

You’re all set if running from try.akiban.com. If running elsewhere, e.g. locally, replace the host and/or port as needed.



That’s it! Viewing this in your favorite browser should present a log-in window when using the defaults. Just input the credentials from the DataSpace Deployment and you should be on your way.

What is happening:

  • Viewing or refreshing
    • GET to the collection URL, all entities are returned in JSON
  • Adding
    • POST to the collection URL, a new entity is created and its id is returned in JSON
  • Checking done or not done
    • PUT to the collection URL and entity id, the stored entity is updated
  • Removing
    • DELETE to the collection URL and entity id, the stored entity is destroyed

How’s that for easy? As always, this is just scratching the surface and there is much more to cover. For example, tired of creating your model up front? Stay tuned for posts on the Builder Resource.

Client Libraries: Parenthesis Edition

Posted by .

Because Akiban Server supports mostly standard ANSI SQL using the Postgres network protocol, existing client libraries usually work, but there are a few things to watch out for, illustrated here by ones from Lisp-like languages.


The org.clojure/java.jdbc library uses JDBC, which is pretty well shaken out with Akiban, because we use it for our internal testing. But there are some incompatibilities in our dialect of SQL, such as:

  • CREATE TABLE does not allow columns with just VARCHAR. You have to either give a length or use TEXT to represent an unbounded text string.
  • Akiban does not support DDL inside a transaction; auto-commit needs to be left on. This isn’t something we’re proud of, but we haven’t fixed it yet.

To show these, we have a fork of Heroku’s simple Shouter application. The changes needed were small, and would still work with a real Postgres system. You don’t have to provision the Akiban service using Heroku, but you can. And if you do, the environment variable will be AKIBANSERVER_DATABASE_URL instead of just DATABASE_URL.


The tutorial should just work, including clsql:def-view-class, provided the :port keyword is added to clsql:connect: "15432" for the native driver and 15432 for clsql-postgresql-socket.

The most significant type-related problem is wall-time, which turns into TIMESTAMP WITHOUT TIME ZONE; we don’t support the time zone clause yet.


To get the Quickstart to work, give :port 15432 to connect-toplevel.

Because Akiban only supports standard syntax for literal strings, (setq s-sql:*standard-sql-strings* t) is needed.

In the country class, :col-type string will turn into TEXT, which is supported, but not as a primary key, because it has potentially unlimited length. :col-type (string 256) will turn into VARCHAR(256), which is fine.

Top 5 tech updates this week

Posted by .

This week’s update in a nutshell:

  • Easier to add and work with descriptions
  • New node.js DataSpace in the SpaceStation – implements Akiban Direct!
  • Simpler to Copy a DataSpace from the SpaceStation to your personal set
  • Drag & Drop of nested JSON with in-line data load is in – provisions auto-increment columns for unique/identifying fields and means you can simply drag & drop your JSON to arrive at a fully deployed DataSpace that’s ready to code against
  • Finally, updates to our Team portal’s content and upcoming overhaul of the product documentation

Simple Blog Application with Akiban and JugglingDB

Posted by .

Earlier this week, we developed a simple beta version of our adapter for jugglingdb. I decided to take an existing sample blog application built on MongoDB and port it to Akiban using our jugglingdb adapter. We deployed the application on heroku where you can see it running here.

Basically, its a simple blog application with a single entity at the moment – User. Each user has 0 or many articles that they have written. User management is done using the awesome passport library. Persistent session storage is using the Akiban Direct via the Akiban connect store. The code for this sample application is on github. If you like to run a local copy, simply clone the repository and update the configuration for the application as specified in the README.

We created a public dataspace for this application that you can easily copy and deploy yourself. Simply click the Copy button on this dataspace and you will wind up with your own private copy of this space along with a sandbox deployment. To get the application up and running against your dataspace deployment, update the config/config.js file with the appropriate Akiban connection details.

We are actively working on more sample applications with more functionality to show more of the unique features the Akiban service provides. If anyone has any ideas or something they would like to see, please do let us know. Ari also mentioned last week that we are offering Amazon gift cards and Raspberry Pis for early adopters who develop an application on Akiban.