there must be a better way

When you start a company, you don’t really know what to expect. Just like having a baby, you know it is bound to have some of your DNA, but what personality it will take and how it will grow is quite unknown and exciting.

I started Akiban because I wanted to tackle a simple problem. Relational databases don’t handle objects very well, but objects are how we describe the world. In technical terms, I knew that logical normalization is good but that physical normalization into distinct tables is wrong for most workloads. It’s a frustration that's encountered in almost every software project and usually means ugly band-aides - and it's been one of the major drivers for NoSQL. I can say with some amount of pride that we’ve solved that problem in a deep and elegant way.  

The FoundationDB acquisition is an exciting moment for me. We’re making a leap in a speed that is hard to imagine - because two incredibly compatible stories and technologies are coming together.

As I write this, our unique database stack is running as a stateless service on top of FoundationDB’s scalable backend. Through close collaboration and over a short amount of time, we are now capable of delivering scale, high-availability, fault tolerance and very high-concurrency because multiple Akiban SQL engines can run in parallel against FoundationDB. Not bad. Especially considering that at present, no one in the NoSQL market is able to support operational SQL. The technical fit, that we describe in more depth on the Akiban blog and FoundationDB blog, is quite striking.

I have learned a tremendous amount at Akiban. I love technology and now see that the business side of it is as equally important, and that engineers must play an active role in defining it. I tend to worry about the wrong things - so I might as well not bother worrying. I also know that years of perseverance and patience stand behind every “overnight success” we hear about. Most importantly, I see how it is all about the people and that we are all so fortunate to be surrounded by incredible individuals - co-workers, investors, clients, friends, advisors, competitors, community. For me, this has been the best part of it all.

The mongoose quick start guide is interesting in that it encapsulates an insight very cleanly:

Developers are looking for a flexible schema, NOT for no schema.

Here's an extract from the first few lines of the quick start guide:

So the first concept after connecting to a database is... yes, defining a schema. By making NoSQL systems "schemaless" the ORMs or mapping layer must assume that responsibility and the developers, whether knowingly or not, assume the responsibility for data evolution and data quality. The ease of prototyping is offset by the difficulty in managing and evolving.

Here's a suggestion for a better approach in the database itself: make it easy for a developer to create schemas, not just tables but of rich objects, and make schema evolution seamless. The advantages of knowing what data one has are that queries become a pleasure and data evolution and data quality are much much easier.

I started thinking about this again when I came across this blog post from hortonworks espousing no schema. In his words "A schema is not needed when you write data; instead the schema is applied when using the data for some application, thus the concept of “schema on read”, because "Changing the schema is a significant undertaking, one that most IT organizations don’t take lightly". What he forgets to mention is what happens when we loaded a lot of data and have no idea of what's there.

A smart system will learn the data as it arrives and automatically allow the schema to evolve. Such a system will retain the benefits of fast development, with the advantages of powerful querying and data quality.

One of the big advantages of the Akiban Service is very fast SQL against native object data (what I technically call nested tuples).

This weekend we had a chance to get chartio working directly against an Akiban deployment. Because we are not 100% compatible with the postgres protocol there were a few loose ends that needed tightening. A little work by our Mike McMahon combined with a bit of advice from Dave Fowler and his team at chartio, and the beauty of running fast SQL reports against object/JSON data comes to life. Here is a sample chartio dashboard working against the employees ‘default’ space that is deployed with every new account.

Check it out: https://github.com/akiban/akiban-server

http://sandhill.com/article/database-as-a-service-the-next-frontier-in-the-cloud-2/

Suggestions for maintaining an empty in-box, a goal that has tantalized many since the dawn of e-mail. This article describes the only approach that sort of worked for me, with the addition of quickly skipping what seemed unimportant. Will Mailbox finally change that? I doubt it, but it's good to finally see a head on attempt.