FoundationDB Gets $17M to Push ACID Machines
NoSQL startup FoundationDB became the latest recipient of venture capital funding today when it announced a $17 million Series A round of funding led by Sutter Hill. The Washington D.C.-area company hopes the cash infusion gives it the resources to build out its NoSQL database, which it claims is one of the few of the class to deliver true ACID features.
There is an ongoing debate among NoSQL database vendors about compliance with the precepts of ACID, the database term that stands for atomicity, consistency, isolation, and durability. Relational databases have long adhered to ACID, which is critical for transaction processing as it ensures that a database will remain stable under high loads with lots of updates from multiple sources. ACID-icity is not as critical for read-heavy applications, such as analytics.
Many NoSQL databases give up strong adherence to ACID in exchange for horizontal scalability and greater flexibility in data types. That is not a problem for analytic workloads, but it raises major issues when one tries to run a large transaction-oriented workload on a NoSQL database. Some NoSQL vendors espouse “eventual consistency” in exchange for the strong consistency typically displayed by relational databases. But in some cases, even eventual consistency leaves too big of a chance of having a corrupted database that NoSQL is deemed too risky to use.
The folks at FoundationDB were aware of this dilemma as they began development of what would become their eponymous database in 2009. They were aware of the Eric Brewer’s CAP Theorem, which states that, in distributed computing architectures, it’s impossible to simultaneously provide data consistency, availability, and partition tolerance. They were aware of the work of Amazon CTO Werner Vogel, who has cast doubt on the capability to deliver consistently large distributed database technologies.
“That really was the understanding, that you just had to give up consistency and ACID transactions if you’re going to operate at scale in a distributed manner,” says Nick Lavezzo, the COO of FoundationDB. “It was because of that belief, the CAP Theorem, which led people to believe that a system like what we built was not possible. That almost deterred us from entering this project, but thankfully it didn’t.”
So how did the company tackle the problem that had vexed so many? According to Lavezzo, they simplified the problem as much as possible. The product eventually built by him and his FoundationDB colleagues, co-founders Dave Rosenthal and Dave Scherer, is actually a very basic key value store.
“We pushed a lot of complexity out of the system by making it a very simple core data model,” Lavezzo tells Datanami. “We separated transaction processing, which is dealing with concurrency, out from the problem of actually storing the data, and that helped to make the problem manageable for us.”
Unlike SQL databases that support a lot of features, the FoundationDB is a bare-bones key value store. “It’s basically like a dictionary,” he says. “You can write keys and value. You can retrieve keys and values. And you can do a couple of operations on them. But it’s not highly feature-able. And that made designing and testing the system really possible.”
Additional features are added to the FoundationDB in what the company calls layers. “They’re basically programs that sit on top of FoundationDB, that use the FoundationDB key value API to represent other data models to applications.” One of those layers is a SQL engine that sits on top of the NoSQL database. That SQL engine is currently in testing. FoundationDB would have failed at its efforts had it tried to support a bunch of features, such as complex SQL, documents, or graphs, right off the bat, Lavezzo says. “The problem would have been much, much harder,” he says.
If this approach sounds like a departure from how other database companies have attacked the problems, that’s because it probably is. But FoundationDB has one big tech company on its side that’s doing things in a similar manner: Google.
“Eight or nine months ago, something really exciting happened for us, which was that Google published the Google Spanner Paper,” Lavezzo says. That paper describes a fault tolerant system that is fully compliant with the ACID precepts. “Google did the same thing [we did]. Google Spanner is a key value store, like FoundationDB. Then they have a layer that sits on top, called F1. That’s a SQL interface to their Spanner database.”
The fact that Google took the same approach to addressing strong consistency in a distributed database was a validation of FoundationDB’s efforts, and undoubtedly helped them get their funding. “I’m sure they were unaware of us, and we were unaware of them,” Lavezzo says. “We were running down a very similar path with simple features in the core and then adding features in layer.”
FoundationDB’s database became generally available in August after an 18-month development and testing process. The company, which was initially bootstrapped by its co-founders, now has $17 million in the bank to ramp up its development, sales, and marketing efforts.
Just getting your foot in the door has proved to be a challenge. “One of the hardest things we had to overcome initially was basically everyone’s reaction. When we told them what we built, they’d say ‘It’s bull***t. That’ s impossible. I read all these things online that said you can’t do it.’ We could prove it to people if they were willing to download the software and test the system.”
But FoundationDB has a believer in Sutter Hill Ventures, the Menlo Park, California venture capital fund that led Foundation’s Series A round. “When I first encountered the claims made by FoundationDB about their technology I was naturally skeptical,” said Sutter Hill’s managing director Sam Pullara in a statement. “I’ve followed the NoSQL space with interest for years waiting to invest in a company and technology that stood out from the crowd. The approach and discipline of the FoundationDB team is astonishing. They spent four years building the most rigorously engineered piece of software I’ve seen in the last 20 years.”
FoundationDB is still a young company and hasn’t had a lot of customer success yet, but it’s convinced it’s on the right path. It’s not shy about beating the ACID drum far and wide, which probably won’t win it many friends in the NoSQL database world, considering its practice of calling out other NoSQL database vendors about their ACID claims.
The only other NoSQL vendor that passes FoundationDB’s ACID test is Marklogic. “We do think Marklogic is telling the truth. They do have ACID,” Lavezzo says. “But there are a lot of companies out there that are using the term ACID, but they’re misleading people. A lot of companies will say they have ACID. But they can only update a single data element at a time.
There is some wiggle room in the ACID definition that’s providing cover for NoSQL database vendors, Lavezzo says. “Unfortunately ACID doesn’t have a binary definition,” he says. “There’s a lot of confusion. A lot [of NoSQL database vendors] are weak in that regard, but they’re strong in market position, so they’re trying to create confusion around that.”