Four reasons we’re really excited about FoundationDB

vectors are fun

As you might have heard, FoundationDB became publicly available this week. As we’ve discussed in the past, we’re very excited here at OpenSource Connections about this emerging database. After experimenting with the beta, we can definitely assert FoundationDB represents an important milestone – combining ACID style transactions with the scalability of today’s NoSQL key-value stores. Why is this important? Here’s four reasons why you ought to be paying attention:

1. Unopinionated Transactions

Most applications need transactions. A big part of application design is mapping the application’s expectation of transactionality to the transactional features the database provides. Unfortunately, many of the new NoSQL databases frequently have rigid transactionality features. HBase, for example, only gives you transactionality guarantees for a single row. If you can map your application to HBase’s opinions, then you’ll get the awesome performance that HBase promises. If you can’t then you’ll need to find another database for your application.

FoundationDB lets you tune the dial in whichever direction your application requires. A transaction may be a simple operation impacting a single key/value pair. Or a transaction might be a complex operation impacting multiple parts of your database. The decision is the programmers. In effect FoundationDB lets the application’s opinions on transactions reign. Moreover, when multiple applications share the same data store, each applications opinion matters. FoundationDB was built around few assumptions about what you’ll need, understanding that every application is different when it comes to transactions.

2. Unopinionated Normalization

Databases these days come with very specific notions of how you ought to (de)normalize your data. In columnar data stores like HBase, the opinion is that keeping everything in a single row, as denormalized as possible, is the best and safest way to use the database. Relational data stores, of course, expect high levels of normalization, with data broken up based on the normal forms I’m sure you learned at school. Normalization is often good – it helps us avoid duplication and update anomalies. And sometimes denormalization is good – its frequently simpler to manage in a distributed system – avoiding the performance cost of joining across multiple nodes in the store.

FoundationDB lets you decide on the appropriate level of (de)normalization based on what the application calls for. Do you need very wide rows of data? That’s fine; FoundationDB will happily store a giant BLOB away for you. Do you need to clump together related keys/values in the database? That’s also great, FoundationDB can achieve this through the sorted and hierarchical nature of its keys. Would you rather give each piece of data its own id, turning FoundationDB into redis? That’s perfectly ok too. You start to get the feeling that FoundationDB serves your diverse needs rather than your application conforming to its narrow opinions of how data should be stored. This kind of thinking in the NoSQL space is certainly refreshing!

3. Layers with opinions – Your applications opinions

Of even greater importance, I’m excited that FoundationDB lets me build the layers that bake in the transactional/normalization opinions I need for my application. I can define, in code, the subtle tradeoffs that defined how I store data. Instead of choosing half-a-dozen different databases each with a slightly different set of features, promises, and tradeoffs, I build layers on top of a single data store, thus avoiding the burgeoning complexity of dealing with many duplicated databases.

Building the layers is not a hard task that requires low-level database knowledge. The API is elegant, simple, has multiple language bindings, and is well documented. The storage model is simple and unobtrusive. This makes it straight-forward to wrap in a completely different data storage abstraction. For example, FoundationDB has replaced the backend storage engine of SQLlite with FoundationDB. You may think you’re talking SQL, but in reality, there’s a piece of FoundationDB client code sitting underneath the SQLite query parser. Suddenly a small embedded database has turned into a distributed, scalable data store!

4. The People

Most importantly, we’re impressed with the team. After interacting with the FoundationDB, including hosting a hackathon with the team, I can verify that it’s a great group of folks. The FoundationDB team combines the two features I find most valuable in technologists:

  1. They are really smart and deep technically
  2. They are human beings: friendly, outgoing, humble, and can communicate

When the founder takes a personal interest in bugs you find, or technical feedback you provide, you know you’ve found a technology that feels like home. It seems every member of the team interacts frequently community site they’ve setup, helping with support issues and triaging bugs. It’s a good sign for me to see a product company so engaged with the community around their product.

Closing Thoughts

In short, we’re excited for the future of this new company and new technology! Do you have questions about FoundationDB and how it stacks up against other (No)SQL solutions? We’d love to hear from you or leave us a comment below!