We spoke with Dave Rosenthal, CEO of FoundationDB, over a conference call last week. Dave gave us an overview of FoundationDB and its business activities. FoundationDB is a NoSQL database with a shared nothing architecture.The product is designed around a “core” database, with additional features supplied in “layers.” The core database exposes an ordered key-value store with transactions. The transactions are able to read or write multiple keys stored on any machine in the cluster while fully supporting ACID properties. Transactions are used to implement a variety of data models via layers.
Who are you and what do you do?
We’re FoundationDB and we’re a database software startup tackling fundamental computing problems in the big data scene. We’re not a data science company per se’ – we’ve built a database itself – the core storage substrate that can be used in an operational capacity to generate the data to fill big interactive data analysis platforms and applications. We are especially concerned with the types of applications that require a lot of random writes and reads, and random database access versus just doing batch processing and scanning through data.
We think of ourselves as an operational database, rather than an analytical database, though due to its design FoundationDB is good at both.
How did you come up with this idea?
We previously started a company called Visual Sciences whose primary product was a high performance data analytics tool. It got its first major adoption in the field of web analytics, and it had a very rich graphical data analysis interface. What ended up happening was that Visual Sciences went through a series of acquisitions and was ultimately acquired by Adobe. Essentially, the product that my co-founder and I (along with the rest of the team) built for Visual Sciences is called “Adobe Insight.” It’s basically a high performance data analysis platform for ad-hoc queries on big data sets, and is used by some of the largest companies in the world. So, we were coming off of that start-up that we had worked at for almost 10 years, and then started looking into building a new company. One of the things we asked ourselves was what database should we use for our new products?
At this time, 2009 or so, NoSQL was starting to become a buzzword and we began looking in a lot of NoSQL databases out there. We became pretty excited by their distributed designs and the fault tolerance of many of these systems. Unfortunately, when we really started to use them, we realized that a lot of them made sacrifices that we didn’t want to make. The problem that we saw was that all of the NoSQL databases had given up on the transactions and ACID properties that traditional databases had used for decades. Having observed this problem, we wanted to build a NoSQL database that had those capabilities.
One thing led to another and we really thought that a good next startup would be to tackle this big problem in the NoSQL database market.
What is your business model?
It’s pretty simple. We want to build the best NoSQL database in the world and get everybody out there using it. Our license model is on a “per process basis”, which means that when you run a FoundationDB database process on a server, depending on how many of them you are using in your cluster each month, the price changes. The other thing we are excited about is that we allow people to use up to 6 server processes even in a production environment for free, and unlimited usage in non-production environments.
What makes FoundationDB unique?
What makes us unique is really the fact that there is no other NoSQL database out on the market that has these transactional guarantees that we offer. There are a couple of companies that have some transactional capabilities – MarkLogic, VoltDB for example – but we’re really the only NoSQL database on the market that is designed to be used all the time using transactions across the entire database.
The technical differentiator is that by supporting ACID transactions, it allows us to deliver a variety of data models and languages on top of a common engine. For example, we will be launching a SQL engine this year that allows you to have a true ANSI SQL database on top of our NoSQL database. That’s something that nobody in the industry can do because they don’t have that transactional capability. That is what is special about our product.
Are there any case studies you can talk about?
The one that comes to mind is on a company called Locality. Locality is an online marketplace that tries to collect all of the local service businesses in one place where users can search based on a number of criteria. If, for example, if you wanted to find a full list of your local dry cleaners, or hairdressers, you would go onto Locality and it would give you comprehensive pricing as well as customer satisfaction information.
At the time we started talking with them, Locality’s lead back-end engineers were looking for new database tools to reach their performance and reliability goals. The engineers at Locality started searching for a NoSQL database that would meet all the database requirements they had — flexibility, scalability, fault tolerance, etc — but they thought they had to compromise on other key features like transactional capabilities. There was nothing out there that met all of their requirements. It was then that they found us and started playing around with what we had built.
Today Locality’s entire product is running on FoundationDB! They came to us because we were the only company that was able to match all the things that were needed in NoSQL, but also offered additional features that didn’t force them to compromise.
Are you planning on expanding into Europe or Germany in particular?
We actually have a few companies that we’re working with. There’s a large, Swedish dating website company, a financial services company that’s based in London and a software vendor based in France. We have plans for Germany and will be rolling out there soon. We’re attending the NoSQL Matters conference in Cologne in late April, also.
FoundationDB is a NoSQL database with a shared nothing architecture.The product is designed around a “core” database, with additional features supplied in “layers.” The core database exposes an ordered key-value store with transactions. The transactions are able to read or write multiple keys stored on any machine in the cluster while fully supporting ACID properties. Transactions are used to implement a variety of data models via layers.