Apple Acquires FoundationDB

http://techcrunch.com/2015/03/24/apple-acquires-durable-database-company-foundationdb

by ea016 • 11 years ago

483 376 11 years ago

Would be nice to know what this means for existing customers. Did we just waste a bunch of time with FDB? Is it going to be open-sourced?

crashoverdrive• 11 years ago

You can no longer download from their website. So, I'd assume yes, we all wasted our time.

tjholowaychuk2• 11 years ago

Yeah, noticed our CI failing :( ... so not cool

threeseed5• 11 years ago

Well this is a very unusual announcement.

From what I know Apple is a big user of Cassandra and Teradata for iCloud, iTunes etc. Both of which are very solid databases that have been proven to scale.

I am not doubting FoundationDB's credentials but it's pretty extraordinary if they are having scalability issues with either.

My guess is that Apple plans to create an equivalent to Facebook's Parse. Either that or this is an acquihire.

pxlpshr• 11 years ago

It could be a compliment for Swift but seems like an acquihire. Distributed db startups are maturing, market is getting crowded. Yes, Apple is a heavy user of Cassandra last time I checked.

Still a success for the team and should be celebrated appropriately. :) Startups are hard.

eternalban3• 11 years ago

Why antagonize the community by pulling repos if they only wanted the brains?

wmf2• 11 years ago

Apple has a 1984-like policy about acquisitions where they erase any trace of the acquired company, and they follow this policy to a fault.

spiralpolitik• 11 years ago

Two good reasons:

1. Why waste resources in maintaining something you don't intend to continue to support.

2. Given the litigious nature of the US, Apple probably doesn't want to deal with a codebase that could include all kinds of potential legal issues that are now suddenly Apples problem.

flutterecho• 11 years ago

Apple released CloudKit last year. It's not web and multiplatform like Parse, but it's similar to Parse's initial offering.

jasondc2• 11 years ago

Anyone running FDB in production, good luck, downloads are removed from https://foundationdb.com/

I don't understand why anyone would run a closed source database, especially with the open source options available.

smt885• 11 years ago

The acquire-hire-kill cycle for startups that target developers has become really frustrating. I'd love to try a lot of these new products, but it's hard to know if it's worth my time.

jcdavis• 11 years ago

Tragedy of the commons in action. Every VC-backed startup is incentivized to sell, but in the process continues to kill goodwill towards dev startups. I'd be super hesitant of relying on any other company for core tech with high switching cost for this reason.

andyjdavis• 11 years ago

Can you (or anyone else) explain why these occur?

Is it simply a case of the acquirer wanting the technology and maybe the personnel while the acquired company is losing money hand over fist so they just shut the company down?

PublicEnemy1112• 11 years ago

I've been wondering if there's a sort of nash equilibrium to these things. How many startups will a restaurant let auction its open tables before losing faith in all of them?

bad_user2• 11 years ago

Here's a simple rule you can apply - if it's closed source, then it's not worth your time.

Like, don't build on top of freaking closed source platforms and after 17 years of OSI, 24 years of GPLv2 and myriads of open-source alternatives available, you'd think people would learn.

threeseed5• 11 years ago

The issue isn't with closed source databases. The issue is with trusting smaller startups who don't have a customer base large enough to avoid dropping.

Oracle and Teradata for example are proven databases with official support available worldwide and a talent pool you can draw from almost immediately. You don't get that with most open source databases (at least those that don't have a parent e.g. Datastax, Mongo, MySQL).

YuriNiyazov• 11 years ago

If no one allowed small-startup technology into production, then the industry stagnation would be tremendous, so I disagree that is the issue. However, once you do rely on a small-startup database, it better be closed source, so I disagree: the issue is the closed-source part, not the small-startup part.

baldfat2• 11 years ago

please don't down vote because you disagree. Write a reply. Down vote what is inappropriate and doesn't add to the conversation.

I strongly disagree your stance on Oracle in particular. I had two arrays at a medium size academic library 8 years ago. Anything I had to call about the data base meant a line item for business review due to cost if it wasn't covered by Oracle's service agreement.

PostgreSQL is amazing and I much rather work with that and hire whoever I want with what I want to do either per instance or annual contracts.

lmm• 11 years ago

Oracle and Teradata for example are proven databases with official support available worldwide and a talent pool you can draw from almost immediately.

I've watched Oracle try to strangle more than one company once they were dependent on their database. One they succeeded, one managed to migrate to PostgreSQL just in time. If you build your business to be dependent on Oracle they have you by the balls; don't think they're not going to squeeze. And IME the worldwide talent pool is much more available and... well, talented, for PostgreSQL or MySQL or any of the major open-source options.

throwawaymsft• 11 years ago

There is a species of parasite that infects ants, making them climb blades of grass so they are eaten by wandering bovines.

The cow was the target all along, not the ant.

differentView• 11 years ago

Who's who?

rylee• 11 years ago

Hey, isn't that a quote from a book? Could have sworn I heard it ages ago in a book I enjoyed very much!

I think it was Peeps.

lectrick3• 11 years ago

The parasite is money, isn't it? The ant is FDB and the bovine is of course Apple

crimsonradish• 11 years ago

The even better parasite story is the one that enters into a rat and crosses it's wires so that it is sexually attracted to cat pee. It goes into heat when it sees the cat and naturally gets eaten - the goal was the cat brain the whole time. As heard on NPR http://www.wbur.org/npr/9560048.

jandrewrogers2• 11 years ago

There are two reasons why many companies run a closed source database. For some types of databases, there is no good equivalent in open source. For some types of workloads, the closed source implementations are orders of magnitude more efficient, faster, or scalable than anything in open source, so open source cannot reasonably support the workload.

It happens more often than you'd think. There are still many things in the database world that open source does relatively poorly compared to alternatives.

jasondc2• 11 years ago

What is an example of something done much better by a closed source database (compared to open source)?

serve_yay• 11 years ago

I do.

kogir• 11 years ago

Or get a 5-10 year support contract for things critical to your company's function?

itcmcgrath• 11 years ago

All sorts of ways around that, so it's unlikely you would get a contract that precludes you not being out of support before the term is up.

As a thought experiment, if the company just went bankrupt and had no one working for it any more, you contract won't help right? Second part, what happens if someone just buys the assets (IP) and closes the company, then hires the old team? There are many possible variants here.

ddispaltro2• 11 years ago

This is actually kinda ridiculous. I feel so bad for companies that have invested in this product. Just pulling the downloads like that... wow. I'm hoping that paying customers at least got some heads up, data migration is the hardest thing to get right.

Good luck to all the former FDB'ers.

sigzero• 11 years ago

Contracts for support just don't go poof.

illicium• 11 years ago

It's fairly common to have contract terms requiring the SaaS provider to provide the source code to their (typically closed-source) product in case they go under. Of course, that only helps if you buy the product or support for it and not just rely on free downloads.

onestone3• 11 years ago

I don't understand why anyone would run a closed source database, especially with the open source options available.

I generally share this opinion. However, in this case no open source solution came close to the features offered by FoundationDB. There are a couple of attempts (like CockroachDB) which could achieve something similar in the future.

One more reason for me to hate Apple now.

biokoda8• 11 years ago

ActorDB is quite similar

ssmoot3• 11 years ago

Because HA, simple to use solutions are very expensive, closed source, or operationally costly.

if you think you've got the secret sauce, and you've actually had to put it into action and still hit five nines, awesome. But IME doing that with something like PostgreSQL is non-trivial (read: costly). That's why FoundationDB looked so appealing (to me).

bbulkow3• 11 years ago

Biased opinion here (Aerospike CTO and Founder), but you might want to check out open-source Aerospike DB. Like Foundation, it's clustered by default, very very good at SSD / Flash, runs great in cloud deployments, etc.

It's been used in production by big ad houses like AppNexus as well as retailers like SnapDeal. Lots of miles on the code.

Was closed source for years, but went open source about 9 months ago.

tracker14• 11 years ago

If you don't need SQL, there are a few pretty compelling options out there, each not without their faults... just the same.

MongoDB, RethinkDB, ElasticSearch, Cassandra and I'm sure a number of others.. each of them have HA options (though RethinkDB is still a few months out for auto-failover iirc), and Cassandra has pretty close to linear scalability in production for some very large data loads. I really like each for different reasons, and would lean towards one or another depending on load.

Not to mention, my speculation is PostgreSQL will likely have an in-the-box replication with failover and/or multi-master solution in place within a few versions.

dlau1• 11 years ago

https://github.com/FoundationDB/ looks to be emptied out

This organization has no public repositories.

eadz• 11 years ago

Anyone have a cache of the downloads for OSX and Linux?

alatkins• 11 years ago

I think it's reasonable to expect any company doing anything vaguely important to do configuration management at least to the level of keeping copies of their production software installation binaries.

markpapadakis2• 11 years ago

This is really about closed source, proprietary infrastructure technology (not all kinds of software in general ), offered by startups, not established companies.

That is to say, people use Oracle, SQL server, Teradata, etc and they are not worried they will go out of business or be sold or otherwise that they will be left in the dark by a sudden shift in business practices and product availability.

The problem is almost entirely with startups, which are an easy target for bigger companies interested in their technology and team skills set. This is even more so an issue because the majority of startups are VC funded and are under pressure to sell or comply with VCs interests.

So in practice you have three ‘safe’ ways to build your infrastructure, which are not mutually exclusive. Choose OSS software, buy from companies such as Oracle, IBM, HANA, etc, and build it yourself. Depending on the expertise of your team and funds available for purchases, as well as qualifies of the available solutions, OSS is probably the safest way, followed by purchased from large corps. Rolling your own infrastructure is expensive, time consuming, requires committing your developers to building infrastructure instead of well, building a product, and may not work in the end at all.

Even the companies that can afford to do it everything in house (Facebook, Yahoo, Twitter, etc) choose OSS for the majority of their needs and build on top of that. Google is Google. However, if that infrastructure is your selling point and what differentiates you from the rest, and/or you have very specific needs and makes more sense to do it this way, doing it yourself can be a great alternative.

We rarely use OSS here, and we don’t use any proprietary infrastructure technology. We have built everything ourselves, and it has worked out great so far, but we have put a lot more effort and resources into that, whereas we could have instead invested on the Product. If we had to make a choice again, in retrospect, we ‘d most likely have gone the OSS way. It’s all about tradeoffs.

lwf• 11 years ago

We have built everything ourselves, and it has worked out great so far, but we have put a lot more effort and resources into that, whereas we could have instead invested on the Product.

So, you don't use a libc, or a web framework, or any library that implements common logic that other programmers have spent ages refining?

If yes, erk, I don't want to be anywhere near that codebase. If not, I'm reminded of https://www.youtube.com/watch?v=YKjPI6no5ng

Decade3• 11 years ago

Established companies are no guarantee. If you rely on Visual Basic or FoxPro, then good luck to you. Oregon hardly had a good experience with Oracle. Much of IBM is doomed.

FOSS or proprietary to yourself are the only valid options.

ChuckMcM3• 11 years ago

Congrats Nick and company! Way to go! And crap! I was hoping to use that stuff.

jacquesm4• 11 years ago

Be happy that you didn't!

ChuckMcM3• 11 years ago

Actually not really. They had some really awe inspiring stuff working, ACID at speed. One of the things that could have enabled would be multi-user gaming at a scale that is only imagined today, literally several thousand players on engaged in the same space at the same time, all with predictable semantics that would allow you to provide for individual engagement statistics and client visibility (basically everyone would see the same things happening at the same time, the really "hard" bit of multiplayer gaming). I had started coding up a massively multiplayer version of rogue since my 3d art skills are crap, the idea being to see if we could get a thousand people into the same room of an ascii dungeon at the same time and usefully engage enemies and collect loot. That simple example touches many places where things have to work predictably in order for a virtual "space" to succeed.

jsherer• 11 years ago

Interesting. I was checking out FDB earlier this month for solving some interesting scalability challenges. I'm quite glad I hadn't decided to re-architect a bunch things based on it!

Did any of you get bitten?

burke• 11 years ago

This actually makes me pretty sad. FoundationDB was the best shot the world-at-large had at a decent distributed database.

orand6• 11 years ago

Nooooo!!!! FoundationDB is too special to relegate to the iCloud back-end. There's nothing else quite like it out there that's publicly available, either commercial or open-source. This just set the industry back several years. Given that Apple has virtually zero interest in server-side development tools, I highly doubt us civilians will ever see this amazing technology again. :-(

amelius• 11 years ago

It is a sad example of what capitalism eventually leads to. Instead of having "modular" companies which can interface freely with eachother, we end up having a few opaque MegaCorps with an internal economy.

dasil003• 11 years ago

But capitalism is also what channels the human instinct to survive into productivity. Sure some subset of geeks can be motivated purely by creativity under a communist system, but I'd be dubious that it could overall match the velocity of Silicon Valley's innovation engine even granting the sizable implied waste reduction.

logicchains9• 11 years ago

As opposed to communism, which leads to everything being produced/owned by one entity, the state? I'm sure there are reasonably arguments for communism but I've never heard it asserted that encouraging market competition is one of them.

wesleyy• 11 years ago

Well if we're in an ideal capitalism society, if what foundationDB created was really of such tremendous value, somebody will come along and do the same thing.

Keyframe• 11 years ago

Well, that's the nature of capitalism. It naturally and inevitably leads to monopoly without government intervention. That's the primary reason of regulation in capitalism oriented societies.

taf2• 11 years ago

How does influxdb compare?

wmf2• 11 years ago

It doesn't? Time series data is a pretty specific use case.

jamie• 11 years ago

Worth following the development of cockroachdb https://github.com/cockroachdb/cockroach

The long term goals of that project seem to align.

orand6• 11 years ago

Thanks for the pointer to cockroachdb. The last I'd checked (over a year ago), FoundationDB was the only reasonable option for distributed ACID transactions, so it's good to see something else with the same goals.

jzelinskie• 11 years ago

Coackroach is to Spanner as FoundationDB is to F1

Altenuvian• 11 years ago

Also have a look into HyperDex: http://hyperdex.org/

bdarnell2• 11 years ago

Yes, we have very similar goals with CockroachDB as FoundationDB had: a distributed, transactional data store (ACID, CP, etc). We're starting with the key/value layer, although we have ambitions to also build more structured interfaces on top of it. It's not quite ready for use yet but we're approaching our first alpha release.

t1m• 11 years ago

I think Aerospike has a very similar featureset. It is ACID + NoSQL, replicates nicely across multiple data centers, and definitely has a similar/better latency and throughput profile than FoundationDB.

emp2• 11 years ago

ACID on a single "record". I am glad they document this openly, so many other DBs try to make it seem like they support ACID transactions in general. From my understanding with FoundationDB, you did something of the form of "begin transaction" "do lots of stuff" "end transaction", and it just worked. I've yet to find another option that can do this.

0xFFC• 11 years ago

So, database experts , what was specific about foundationDB ? Why apple chose this one ? There is planty of [a-bA-B]+DB's out there. Why this one ? , Sry I dont know anything about databases , But I would love to know about them.

lclarkmichalek5• 11 years ago

Distributed ACID transactions. Very good testing regime. Good performance. Basically the NewSQL dream.

slantedview• 11 years ago

This, and there is (or was) nothing else like it in the marketplace.

itchyouch• 11 years ago

Based on a cursory glance at the properties of ACID, it seems like something that the financial world, especially the stock exchanges, have had to deal with when dealing with transactions.

I wonder if a similar architecture could be used for building a distributed database that could rival what was lost with foundation.

assface• 11 years ago

Mmm... they were just doing shared-data distributed MVCC. Nothing new there. My takeaway from spending some time with the documentation that their SQL layer was a hack.

jhugg9• 11 years ago

Except the SQL part didn't work well.

If you want those same features, consider VoltDB. It makes different tradeoffs on what kinds of ops are fast, but has all of those features.

Essentially arbitrary two-key transactions are slower. Partition-friendly writes and global reads are faster. Global reads with real SQL can be orders of magnitude faster.

mirekrusin• 11 years ago

Just have a look at how they do testing (Simulation/Flow). It's amazing.

bsaul• 11 years ago

That's exactly the one thing i remember about them. I saw the video about their testing method and knew they had to go somewhere eventually.

xentronium• 11 years ago

There is planty of [a-bA-B]+DB's out there

You probably meant [a-zA-Z]+DB!

amluto• 11 years ago

I wonder whether Apple is planning on open-sourcing the code. If they want it for internal use, then open sourcing it could make the whole project less expensive.

FireBeyond• 11 years ago

As optimistic as you might be, I have to imagine the odds of that happening are exceptionally small.

While you could point to the pulling of downloads, and pulling of GitHub accounts as a transitional 'rebranding', I just don't see what incentive Apple has to open source a system that is useful to bigger players and generates a lot of revenue.

rodgerd3• 11 years ago

it could make the whole project less expensive

I'm sure a company that's richer than many countries is really, really concerned about the cost of development.

The benefit of making sure no-one else can benefit from the technology, on the other hand...

josephagoss• 11 years ago

Is it worth it for Apple to deny the industry a cutting edge database with the only cost being a single day's profits or less? Of course it is.

And you're spot on about the cost of development. I'd imagine 12 - 48 hours of profits from Apple would be enough to fund its database R&D for the next 10 years.

beagle3• 11 years ago

Can someone give a quick description of what made FoundationDB different than the bajillion other database engines out there?

raspasov2• 11 years ago

CP database (in the CAP theorem sense), distributed transactions via Paxos. Most popular databases (Cassandra, Riak, et al) are AP* systems. CockroachDB is an interesting project in progress that aims to be a CP system from my understanding.

EDITED: seancribbs corrected my acronym spelling in the early morning; *CA - DOES NOT EXIST, what I wrote initially was completely wrong

seancribbs• 11 years ago

You mean AP, not CA.

CA doesn't exist.

jaytaylor4• 11 years ago

Do any of you know if Apple has acquired companies which are partially open-source (FDB SQL layer) with a substantial technologist user-base before?

Knowing their past behavior would be an interesting indicator of what is most likely to follow here.

According to the TC article (and their website), FDB is no longer available for download and there is a "goodbye"-esque type of message on their community site [0]. Their github [1] repos have all now been made private. This seems most unfortunate for anyone who's included FDB in their tech stack.

For reference, FoundationDB has been compared to Google's F1 database [2] [3], so this is Apple purchasing a pretty shiny piece of technology.

[0] http://community.foundationdb.com/index.html

[1] https://github.com/FoundationDB/

[2] http://blog.foundationdb.com/7-things-that-make-google-f1-an...

[3] F1: A Distributed SQL Database That Scales - http://research.google.com/pubs/pub41344.html

josephpmay• 11 years ago

Technically, NeXT was partially open-source, and they maintained Darwin for awhile, but it's pretty much dead now.

Edit: More recently, they killed off OpenNI about a year after buying PrimeSense

eloff• 11 years ago

Looks like an acquire hire and product kill scenario.

mdasen• 11 years ago

Apple acquired CUPS (Common Unix Printing System) which is still used by a lot of Linux distros (like Ubuntu and Fedora).

CUPS was bought by Apple in 2007 and continues to have open source releases and continues to be used by major Linux distros.

For FoundationDB, there isn't really the same market. Most sites don't need a distributed database. People that run sites is already niche and people that run sites trafficked enough to require a distributed database is even more niche. I use HBase and Kafka a lot and there are definitely high-profile users of the software, but it's nowhere near the number of users of MySQL or PostgreSQL.

Maybe Apple will look at FoundationDB as something where open-source in no way hurts them and gets them free development. Google won't be replacing F1/Spanner with it so it's not much help to what a lot of people would consider Apple's largest competition. Plus, open-source could help make it better.

justin663• 11 years ago

CUPS was fully open source when it was acquired.

Decade3• 11 years ago

Not an open-source project, and not a big user-base, but Apple bought P.A. Semi and canceled the PWRficient line of POWER-architecture chips.[1] Presumably, that was inconvenient for P.A. Semi's customers.

[1] http://www.eetimes.com/document.asp?doc_id=1168406

justin663• 11 years ago

All the company's github repositories have been pulled:

https://github.com/FoundationDB/

clord• 11 years ago

If someone has a recent clone and the licence was compatible, is there a reason a fork can't be started?

threeseed5• 11 years ago

Apple has incentives for engineers to file patents.

Always something to be mindful of.

amirmc• 11 years ago

This is quite frustrating. There's a lesson here in keeping mirrors of projects in multiple places. That things can be 'disappeared' from GitHub is because not enough people do this anymore.

72deluxe2• 11 years ago

Put it on Google Code. Oh, hang on....

jaytaylor4• 11 years ago

I have a copy of the SQL layer from March 1st, 2015. It's up on github: https://github.com/jaytaylor/sql-layer

PublicEnemy1112• 11 years ago

If someone is desperate enough, they can recreate the repositories using google cache. See http://webcache.googleusercontent.com/search?q=cache:YiBFZmB...

barosl• 11 years ago

Their PyPI packages also seem to be pulled out[1], but thankfully, their Twitter account is still alive![2]

Also note that there seems to be a mirror for the PyPI packages.[3]

[1] https://pypi.python.org/pypi/foundationdb

[2] https://twitter.com/FoundationDB

[3] http://download.gocept.com/pypi/foundationdb/

ccleve• 11 years ago

Ok, this is a big problem. We've started a project that uses their fdb-sql-parser, which was an Apache-licensed fork of the Derby sql parser. I did not make a clone of it before they pulled it. Does anyone have a copy?

Fortunately, they can't pull the artifacts from Maven Central.

Pulling an open-source project upon which people may depend is total jerk behavior.

timv• 11 years ago

Try https://github.com/hudak/sql-parser

It's out of date - only goes as far as 1.5, but at the very least you can import the 1.6.1 source as one big commit.

georgewfraser• 11 years ago

Apache calcite http://incubator.apache.org/projects/calcite.html contains a sql parser and the source is in much better shape. I made a bunch of contributions to fix things in fdb-sql-parser and discovered it's a real mess.

mintplant2• 11 years ago

According to Google's cache, the latest version on Maven Central (v1.6.1) was only four commits behind master.

https://webcache.googleusercontent.com/search?q=cache:TllYak...

Of those four commits, one was a version bump, one a README tweak, and two were merge commits.

https://webcache.googleusercontent.com/search?q=cache:IzAL7H...

The source code is there on Maven Central, alongside the build artifacts, but the git history is gone.

http://search.maven.org/#browse|-1374863701

mintplant2• 11 years ago

I've found a live fork with the latest changes.

https://github.com/rimig/sql-parser/tree/fix-docs-javarun

jordz• 11 years ago

Interesting, they invest heavily in Cassandra (something like 10PB, 80K+ nodes). I've not really seen much of FoundationDB but is it not similar?

lclarkmichalek5• 11 years ago

It really wasn't. FoundationDB's USP was transactions. Cassandra was designed as a AP system, and using it as a strongly consistent system came at great latency costs. In addition, atomicity outside of a row was all but impossible. Features such as lightweight transactions tried to remedy that, slightly, but suffered from poor performance (was basically just bolting on paxos using the Cassandra protocol, as I under stand it), and correctness problems (see aphyr's post on Cassandra). FoundationDB, on the other hand, was designed from the ground up to support transactions. Features such as MVCC, multi key (read: multi-machine) transactions, all while providing a sane-ish datamodel and very good performance... well boy oh boy they had some real potential.

And now they have been subsumed by Apple. "and they were never heard from again"

EDIT: a while back I commented on a comparison of FoundationDB to Cassandra, and Dave Rosenthal, the FoundationDB CEO, took the time to respond. I completely disagreed with him at the time, but think I understand his points now. Link: http://news.ycombinator.com/item?id=8745462

lastRecon• 11 years ago

I too am interested in this. I just took a look through the docs. SQL layer over a distributed key-value store...

Full ACID and looks to have support for FK/PK JOINs/ and multi-table queries. Their benchmarks page looks super awesome. How well does this work in practice?

One major difference from Cassandra (I think) seems to be that coordinator nodes are set statically (but can be changed on the fly). Cassandra is not this way. While there are coordinator nodes during client connections, they are chosen dynamically by the client during the session and not some fixed config point.

Another difference appears to be transaction limits (https://foundationdb.com/layers/sql/documentation/Concepts/k...). This is fundamentally different from Cassandra, but to be expected without tunable consistency.

Different tools for different problems. I think Cassandra fits Apple's content distribution model better (e.g. streaming music/movie blobs out of C* for iTunes all over the world), but for a traditional RDBMS that is distributed, this looks like a great escape.

Scaling seems pretty easy if it's as easy as copy-pasting the config file from node to node and bouncing the service. Anyone know about this in practice?

kore_sar5• 11 years ago

Not only they have SQL layer. But mongodb compatible document layer should have come out soon.

kore_sar5• 11 years ago

To support my previous comment. Quoting David the founder: http://techcrunch.com/2012/09/10/foundationdb-not-your-stand...

“The most important innovation with MongoDB is its API,” Rosenthal said. “We sell an amazing storage technology that could be compatible with NoSQL technologies like MongoDB.”

jordi92• 11 years ago

One interesting aspect FDB was offering is the multi-model approach. Fortunately, there are still true open source alternatives for this like ArangoDB and OrientDB.

151552• 11 years ago

Neither of those even come close to the out-of-the-box performance you could see with FDB.

Rapzid• 11 years ago

Numbers? I would like to see some test results out of curiosity.

juanido• 11 years ago

And both are not key/value stores. They are multi-model databases with the focus on documents and graphs.

kolev7• 11 years ago

Very well said!

kolev7• 11 years ago

What? I can't do more than just silently upvote if I have nothing to add? The "karma" here means nothing when you think about it - you lose karma in the real world with your purposeless negation.

reitanqild3• 11 years ago

The "karma" here means nothing when you think about it

it affects sorting IIRC.

And in the case of your comment it makes it stand out as less readable as a sign for anyone who hasn't picked up the house rules yet. : )

dang• 11 years ago

I don't think people should have downvoted you for this, but you've also taken this thread way off-topic, and not in the unpredictable satisfying way.

(I've detached this subthread and flagged it as off-topic.)

kolev7• 11 years ago

How did it compare to ActorDB [0]?

[0] http://www.actordb.com/

nickleefly• 11 years ago

Hope app store can be faster

cynicalkane• 11 years ago

I interviewed with FoundationDB and came very close to working there. They were about as smart as you would expect the people behind that kind of technology would be--scalable distributed transactions at speeds many zeroes higher than what was thought possible--and I'm glad to see them succeed, but wondering what's going to happen to their software. Whatever secret sauce made their software I'm not convinced the market can replicate anytime soon.

I also can't help but wonder how much my options would have been worth.

laxatives• 11 years ago

I interviewed with FoundationDB last August or so and got a very paltry offer. On top of that, they wanted me to pay my relocation and cover the cost of the signing bonus clawback. My stock options (had they fully vested at the time of the Apple sale) would have been worth under $14,000. I don't think I missed much.

edit: scratch that, $23 million is the amount they raised, not the amount of their sale. Regardless, unless they sold for 10 figures, I don't have any regrets.

sporkland• 11 years ago

What really differentiated it was the fact that multi-key transactions allowed for you to reasonably build any number of logical data models on top of it in a linearly scalable way. It was all built to an extremely high degree of polish with an extremely good testing and simulation harness and a high degree of predictability in performance. It was basically Spanner for the rest of us, without atomic clocks (and they also shipped an F1, their SQL layer on top). As others have mentioned, the closest cousin at the moment is probably cockroach, but it relies on wall clocks which will probably lead to problems in certain cases, but gets an easier way to scale writes.

Here's the architecture diagram for FDB, it's pretty fun to read: https://foundationdb.com/files/Architecture.pdf

biokoda8• 11 years ago

I think the closest cousin is ActorDB http://www.actordb.com/

jhugg9• 11 years ago

Except it turns out no, the layer thing is practically hard to pull off.

See my other comment. https://news.ycombinator.com/item?id=9262673

bdarnell2• 11 years ago

Cockroach uses hybrid logical clocks and should generally tolerate reasonable amounts of clock skew. Atomic clocks can improve performance in some cases by putting a tighter bound on clock skew, but they're not necessary for correctness.

arthursilva• 11 years ago

Woa, that was unexpected! So sad to see this great piece of software dragged to Apple dungeons.

teeray• 11 years ago

One of their engineers gave a great talk at Strangeloop (https://m.youtube.com/watch?v=4fFDFbi3toc) that shows some of the amazing simulations they ran FoundationDB through. It's well worth a watch if you want to understand the punishment that they put this database through to make it stand out.

Donch• 11 years ago

Reminds me a little of Apple's buyout of the compositing software Shake from Nothing Real and their brutal "end of life" process.

http://en.wikipedia.org/wiki/Shake_%28software%29

"Existing maintenance program subscribers had the option to license the Shake source code for $50,000 USD."

chx• 11 years ago

Funny how everyone accepts this as fact despite techcrunch printing it. The only facts available are that the repos and downloads have been pulled.

aquark• 11 years ago

community.foundationdb.com is a little more informative ... not much but a little.

"Thank you for your support of FoundationDB over the last five years. We’re grateful to have shared our vision of building the best database software and we strongly value your participation in this community. We have made the decision to evolve our company mission and, as of today, we will no longer offer downloads. If you have any technical questions, please email info@foundationdb.com."

jordanthoms2• 11 years ago

Apple is the worst acquirer in the industry, at least for users of the acquired company's products. Nobody else would dare kill a _database_ with no warning, explanation, or migration plan - not even a goodbye blog post!

Whenever Apple acquires anything that runs on a competing company's platform, that version is immediately killed (see any of their mobile app acquisitions).

Thanks for making things that much harder for every other database startup.

zak_mc_kracken3• 11 years ago

I think they're making it much easier for every other database start up: just pick up on the technical grounds left by FoundationDB (see their Architecture PDF) and knock yourself out. You have no competitors right now.

jordanthoms2• 11 years ago

True, although said replacement will probably have to be open source to pick up any serious usage.

sjwright• 11 years ago

If you need evidence of Apple's ability to acquire and senselessly destroy viable products, look no further than Shake.

If you need evidence of Apple's ability to acquire companies while keeping product lines independent, look no further than Beats.

If you need evidence of Apple's ability to acquire industry leading technology to ensure exclusive advantage, look no further than AuthenTec (Touch ID).

If you need evidence of Apple's ability to sincerely invest in open source for the benefit of all, look no further than CUPS. Or LLVM. Or WebKit.

Apple has no pattern.

jkestner• 11 years ago

You can also assign some blame to the database startup that chose not to prioritize its customers in the acquisition. It'd be nice if this pushed more startups to make a legally binding declaration of how customers would be affected by an acquisition, or it pushed more customers to demand it (instead of just giving up on startups). But I'm guessing no one wants to have their hands tied like that, especially when acquisition is a more likely outcome.

jaimebuelta• 11 years ago

About FoundationDB, they have this blog post about achieving almost 15 million writes per second

http://blog.foundationdb.com/databases-at-14.4mhz

It's a pretty impressive number, though as always with benchmarks, should be taken with care.

151552• 11 years ago

As an anecdote, I was seeing outrageous, hard-to-believe numbers in my usage of FDB.

Nothing but good things to say, other than their multi-node configuration being a little strange.

film42• 11 years ago

I feel really bad for all other database startups out there. I'm sure this is sending a negative shockwave through every devops team out there to not use up-and-coming databases.

magd• 11 years ago

And this is why my chef broke todya.

krick• 11 years ago

Can anyone explain what's so special about FoundationDB? Why Apple would want to acquire it? Why exactly FDB and not some other *DB, which we have tons now after last… I don't know… seven years? Just why? I don't get it.

nemothekid• 11 years ago

FoundationDB was a performant, distributed (multiple machines), shared nothing (multi-master) key-value database with SQL on top (not sure if it was standards compliant SQL) that supported translations and serializable isolation (ACID complaint IIRC, but they were some size limitations).

In any case, given that narrow feature set, I can't think of many production quality NoSQL databases with that feature set, and I can't think of any that replicated the millions of writes/sec on GCE like Foundation did, so Foundation seems to be quite special.

Interestingly enough Apple is a heavy user of Cassandra, so if this related to iCloud I wonder if they decided to replace it and why. Or maybe they had enough money where the decided they could just own the database, and DataStax's valuation was too high.

systemtheory3• 11 years ago

yet another argument for rethinking the open source model.

systemtheory3• 11 years ago

yet more downvotes, with no reasoning, on a relevant comment. hacker news is like that significant other that abuses you and you keep going back to. i can't keep making excuses for you hacker news.

takeda2• 11 years ago

I believe you were downvoted because you tried to inject your agenda even though this has nothing to do with Open Source.

FoundationDB was closed source, they just allowed to use their product for free in small deployments.

jhugg9• 11 years ago

This just lines up with what we've seen in the KV space over the last 5 years. Mutating data and key-lookup are all well and good, but without a powerful query language and real index support, it's much less interesting.

Quoting the Google F1 Paper: "Features like indexes and ad hoc query are not just nice to have, but absolute requirements for our business."

Cassandra got ahead of this with CQL. FoundationDB saw this coming and bought Akiban to add a SQL layer. But bolting SQL onto a KV store, even a really good one, isn't trivial to do. I'm not sure it ever delivered on the promise of a real query layer.

Still, I hope this is a good exit for the FDB team. The KV layer is pretty cool stuff.

Full disclosure: VoltDB engineer here.

misframer• 11 years ago

But bolting SQL onto a KV store, even a really good one, isn't trivial to do.

Sure, but isn't that basically what everyone does? All of the relational databases I know use ordered key-value storage engines. FoundationDB is the same, except it's distributed.

The point is to use FDB as a foundation. I heard how one of the FDB founders replaced SQLite's B-tree storage engine with FoundationDB, which turned SQLite into a distributed SQL database. It's much more difficult to make something like that if you had to tackle the hard distributed systems problems.

(I interned for FoundationDB a couple of years ago.)

jhugg9• 11 years ago

Sure, but isn't that basically what everyone does? All of the relational databases I know use ordered key-value storage engines. FoundationDB is the same, except it's distributed.
The point is to use FDB as a foundation. I heard how one of the FDB founders replaced SQLite's B-tree storage engine with FoundationDB, which turned SQLite into a distributed SQL database. It's much more difficult to make something like that if you had to tackle the hard distributed systems problems.

So this is a really interesting point and I can see why it makes sense if you’ve not built a SQL engine. So why is building SQL on top of a KV store the wrong call? What’s the difference between MySQL’s or Postgres’s or VoltDB’s “storage engine” and what FDB had built?

First, I’m not claiming that putting SQL on top of a KV store like FDB is impossible, just that you’re going to have to either compromise the purity of the KV engine substantially, or you’re going to get slow SQL for anything other than single row CRUD.

It starts with metadata. FDB-SQL stores metadata in the KV store itself. This is great from a distributed correctness point-of-view. It’s also great from a simplicity point-of-view. If I trust the underlying system to be safe and consistent, then my metadata is also safe and consistent. But now I need to do a ton of reads before I run my SQL to know how to run my SQL. Where’s my data, for example? Compare this to VoltDB which replicates metadata to all processing sites, and basically has a second state-machine to ensure that each processing site has the right metadata at the right time. Updating metadata is more expensive, but the fast-path of using the metadata is several orders of magnitude faster.

Then you get to locking. I believe FDB-KV uses per-key read-write-sets to manage concurrency. This choice makes their two-key transaction benchmarks look great, but it scales poorly as the number of keys per transaction grows. SQL basically begs users to write operations that read and write to lots of keys. To make scans fast (even common partial-index-scans), you’re going to need more granular locks, or you’re going to need to relax consistency (ACID, not CAP).

Now we get to storage efficiency. If I have a SQL relation with a primary key and other columns, do I split it so the primary key is in the “key” and the other columns are in the “value” in the KV store? Do I store the whole record in the “value” and loose some efficiency? What about relations with no primary key? Say I’ve got a table that facilitates a many-to-many relationship and it’s just a set of integer pairs. How do I store that efficiently in a KV store? And what about that pesky metadata? Does the key need to include the identifier of the SQL relation (table)? Of course it does.

Secondary indexes. Oh man. To do them well on top of a KV store, you’re going to need pretty strong consistency to ensure that index records point to the right base record, and that there are no base records without an index record. This rules out the aforementioned trick of relaxing consistency to get faster many-key transactions. It’s also a metadata problem; I’ve got metadata I need to read to understand how to use the secondary index. More than that, when I update a record in the base relation, I’m going to need to find all affected secondary indexes and make sure they reflect the new information. That might mean lots of reads to the system to query metadata to update the secondary indexes. And again, we have the efficiency problem where I have to put a bit of extra stuff in each “key” to identify the secondary index the KV-pair belongs to. So secondary indexes have locking/consistency, storage efficiency and metadata problems in this model.

Finally you get data transfer. This is probably not a broadly applicable problem, but I think in the FDB implementation, there is a lot of needless data transfer between KV cluster nodes and SQL processing nodes. Too much data needs to be collected and processed, rather than pushing down that processing to the data’s resting location. In FDB-SQL, if I just want one value from a large record, do I have to move the whole record over the network? Most SQL systems build processing DAGs for each SQL statement and can in-process stream between nodes, or have efficient temp tables to buffer intermediate results.

This falls out of making the SQL layer so separate. In fact, I think the team working on SQL was almost a completely separate team in Massachusetts than the KV team in Virginia. If the SQL layer worked, then I can see how awesome this would be. The “Layers” model just sounds so appealing. It’s just technically quite hard.

So yes, I agree that under most SQL-relational systems, there is a storage engine that smells much like a KV store. Still, that system is much less “pure” than what they were going for at FDB. Locking, metadata, secondary indexes, native understanding of relations, moving the processing to the data — all critical to do right to get reasonable performance.

If FDB had more time to continue on the SQL path, I imagine it would dictate much deeper hooks into the KV side of things. I’m sure with time it could get a lot better. There’s a lot of research addressing some of the tradeoffs I’ve mentioned above, especially in the distributed transaction coordination space. Still, it’s always going to be easier to build the storage engine for the kinds of operations you want from day one.

datashovel2• 11 years ago

I don't want to believe it, but I'm starting to think Apple is the new Microsoft / Oracle.

zak_mc_kracken3• 11 years ago

What's so surprising? Apple has been trying to be a monopoly for more than three decades. Just because they have consistently failed doesn't make them less evil that companies that succeeded at it.

datashovel2• 11 years ago

Actually nothing is surprising about it IMO. But I always get downvotes when I appear to be bashing Apple too hard :)

Gurrewe2• 11 years ago

The company I'm working for is looking for a way to scale our DB-layer. Anyway, FoundationDB was more or less the only candidate against MySQL.

Does anyone know of any good (and proven) alternatives to FoundationDB?

kore_sar5• 11 years ago

Consider MySQL compatible ActorDB

eklavya2• 11 years ago

If foundationdb was open source, can't the community continue with the last open sourced release?

Gurrewe2• 11 years ago

It was closed source, with only parts of it being OSS.

eklavya2• 11 years ago

Oh, from the comments here I got the impression that it was open source. If it was not open source to start with why are people saying that amazing tech is lost? It was never available(in the knowledge sense not as a product) in the first place was it?

rhoml• 11 years ago

Too bad not many people read this https://twitter.com/ibobrik/status/454205142662119424

gkya• 11 years ago

Now, what I do not understand is that why would Apple wish to make an over-the-top TV set or whatever. I'd say that they have a loyal userbase--if it only consisted of the mac-using coffeeshop-goers, the business probably would still survive--and a sustainable business model, and they are not going in negative direction economically. Why install another arm to your business?

I also wonder if it is lawful to remove an opensource project overnight from public access, to which people outside the company might have contributed. I have not used this product before and I know neither its licence nor the amount or existence of its contributors, but if I have had made a significant contribution, I would be very annoyed in this case and have sued--if possible--Apple or whoever responsible for publication of the sources until the acquisition.

kahunamoore• 11 years ago

What is needed is a middle ground between OSS and proprietary licensing. Towards this end we are attempting to define a new software license that is organized around the idea of a software cooperative. This provides the basis for a sustainable business model that OSS, frankly, does not have.

This also helps solve the larger problem of concentration of wealth/power within large corporations as the cooperatives would be distributing the wealth to all participants and not just to founders.

It also provides a better path for startups so they don't have to borrow VC money and can get the help of the community to move them toward profitability in the long term rather than taking the first available bag of money from disinterested investors who only want a return on "their" money.

Cooperatives are among the most stable forms of enterprise and are run via direct democracy (at least in our view.)

To discuss this further, join our mailing list here:

groups.google.com/d/forum/coopsource

kore_sar5• 11 years ago

They removed the npm package few hour before our very important deployment. As the result, our client didn't get a feature, we didn't get our money. Die, FoundationDB, die!

PeterCorless• 11 years ago

Congrats to the FoundationDB team from us at Aerospike. We respect what FoundationDB was doing with NoSQL and ACID and believe this validates the importance of reliability and enterprise-readiness in the NoSQL market.

I'd love to hear from anyone who was actually using FoundationDB in development or production, and what other NoSQL open source alternatives you are considering. pcorless@aerospike.com ; http://goo.gl/KVQxyq

Apple Acquires FoundationDB

Related Stories