19 ms·

Apple Acquires FoundationDB

483 points by ea016 12y ago

tjholowaychuk 12y 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 12y ago
  You can no longer download from their website. So, I'd assume yes, we all wasted our time.
  - tjholowaychuk 12y ago
    Yeah, noticed our CI failing :( ... so not cool
threeseed 12y 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 12y 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.
- eternalban 12y ago
  Why antagonize the community by pulling repos if they only wanted the brains?
  - wmf 12y 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.
    - lbarrett 12y ago
      Isn't following a policy like that at all a fault?
      - Gigablah 12y ago
        Yes, if putting "Apple" and "1984-like" in the same sentence wasn't obvious enough :)
    - zak_mc_kracken 12y ago
      The irony s thick considering that landmark 1984 ad they published during the Superbowl... Apple used to claim to fight against Big Brother, today they are largely seen as Big Brother. Thank god for Android for keeping them honest.
  - spiralpolitik 12y 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 12y ago
  Apple released CloudKit last year. It's not web and multiplatform like Parse, but it's similar to Parse's initial offering.
jasondc 12y ago
Anyone running FDB in production, good luck, downloads are removed from https://foundationdb.com/ https://foundationdb.com/ I don't understand why anyone would run a closed source database, especially with the open source options available.
- smt88 12y 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 12y 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.
    - smt88 12y ago
      This doesn't have to be the case. What if startups with high switching costs (DBMS, OS, pretty much anything else infrastructural) added a guarantee to their sales contracts? For example, it could be that, if they get acquired, they'll open-source the technology, sell it to another for-profit entity that will maintain it, or provide a migration tool. Even for something like FoundationDB, it'd hardly be any skin off Apple's back to have a few employees spend a few months ensuring that previous customers have some sort of support.
      - josho 12y ago
        This is simply the risk you take being an early adopter. If you are uncomfortable with the risk then choose something from IBM/oracle/et al.
        smt88 12y ago
ChuckMcM 12y ago
Congrats Nick and company! Way to go! And crap! I was hoping to use that stuff.
- jacquesm 12y ago
  Be happy that you didn't!
  - ChuckMcM 12y 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.
    - jacquesm 12y ago
      Hehe, that's so scary :) I'm busy sketching out something exactly like that at the instigation of my son (who is an avid gamer). I'm nowhere near realizing the vision but I've learned an awful lot just studying the problem from different angles. The key element seems to be 'who owns that data?'.
      - ChuckMcM 12y ago
        Exactly, so the player can be modeled as an index attached to several database records. You end up doing a geo-box select (see earlier posting here about why geo information data bases are hard), an inventory select, an equipment select, and an attributes select by player-id. The linkage is (player-id, geo) -> key for 'world' based databases, (player-id) -> key for 'player specific' databases. When you go to do an action you combine the action mechanics (pick up -> delete from world, add to inventory), (attack -> (roll) -> edit other attributes of monsters/players near by), (defend (roll) -> edit player attributes)) and (drop -> delete from inventory, add to world). Where at 'n' frames per second you need to do a select for a given view point to identify what the rendering engine needs to "show". Clearly doing this with ascii characters on a terminal screen is much easier than trying to render 3D avatars in the real world but the number of database transactions per second becomes massive. If we posit that there are 1,000 players visible to the current player, and just the player / world select is a single transaction, then at 30 fps, that is 60,000 or so queries per second, you throw actions between players, and between multiple players (area of effect attacks) and add another 2,000 monsters and you're easily over 250,000 transactions per second. Since FoundationDB was talking millions of transactions per second with full ACID it seemed like it would be a useful back end for this. Or put another way, you could contemplate building this and see if their product was actually able to keep up at this rate. And they asserted this was on modest hardware (like 32 nodes). So yes, I was looking forward to the interesting places that investigation would lead and the things I could learn.
jsherer 12y 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 12y ago
This actually makes me pretty sad. FoundationDB was the best shot the world-at-large had at a decent distributed database.
orand 12y 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 12y 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 12y 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.
    - cgag 12y ago
      Free people not being able to match the pace of people desperately trying to free themselves from wage slavery doesn't strike me as a great justification of wage slavery. Not that I agree with the premise that capitalism is what drives people to produce things to begin with.
      - logicchains 12y ago
        Are these people trying to desperately free themselves from wage slavery the same people who spend most of their time watching tv, playing games or caring for children nobody forced them to have? If so they don't seem so desperate to me. Generally the people I've met who work hard to develop themselves and develop skills society needs end up doing quite well for themselves, although I admit that as an Australian my experience is probably different from the US. Here we have more socialised education and healthcare, so anyone with motivation can go to college.
0xFFC 12y 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.
- lclarkmichalek 12y ago
  Distributed ACID transactions. Very good testing regime. Good performance. Basically the NewSQL dream.
  - slantedview 12y ago
    This, and there is (or was) nothing else like it in the marketplace.
    - icefox 12y ago
      Well if it truly mattered out there right now there is a company that has a void that they need filling and all they have to do is speak up and help fund a replacement.
      - orand 12y ago
        That won't do much good when all the rare talent needed to build it is locked up at Apple and Google.
        lectrick 12y ago
        There's other rare talent coming online all the time.
        orand 12y ago
        Well in that case, this problem should solve itself any day now. /s
  - 12y ago
amluto 12y 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 12y 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.
- rodgerd 12y 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 12y 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 12y ago
Can someone give a quick description of what made FoundationDB different than the bajillion other database engines out there?
- raspasov 12y 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 12y ago
    You mean AP, not CA. CA doesn't exist.
    - raspasov 12y ago
      Thanks man, good you caught it, I totally knew that, I need to be more careful with acronyms right after waking up :)
    - napoleond 12y ago
      > CA doesn't exist. I'm not sure that's a good way of putting it. You can have databases that offer both consistency and availability, but they need to fit on a single machine (no partition tolerance).
      - cjbprime 12y ago
        > I'm not sure that's a good way of putting it. You can have databases that offer both consistency and availability, but they need to fit on a single machine (no partition tolerance). Garbage collection requires (a delay that is indistinguishable from) partition tolerance. It's pretty illusory on single machines as well. Especially if they're multi-core.
jaytaylor 12y 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 http://community.foundationdb.com/index.html [1] https://github.com/FoundationDB/ https://github.com/FoundationDB/ [2] http://blog.foundationdb.com/7-things-that-make-google-f1-and-the-foundationdb-sql-layer-so-strikingly-similar 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 http://research.google.com/pubs/pub41344.html
- josephpmay 12y 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 12y ago
  Looks like an acquire hire and product kill scenario.
- mdasen 12y 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.
justin66 12y ago
All the company's github repositories have been pulled: https://github.com/FoundationDB/ https://github.com/FoundationDB/
- clord 12y ago
  If someone has a recent clone and the licence was compatible, is there a reason a fork can't be started?
  - threeseed 12y ago
    Apple has incentives for engineers to file patents. Always something to be mindful of.
- amirmc 12y 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.
  - 72deluxe 12y ago
    Put it on Google Code. Oh, hang on....
  - jaytaylor 12y ago
    I have a copy of the SQL layer from March 1st, 2015. It's up on github: https://github.com/jaytaylor/sql-layer https://github.com/jaytaylor/sql-layer
- PublicEnemy111 12y ago
  If someone is desperate enough, they can recreate the repositories using google cache. See http://webcache.googleusercontent.com/search?q=cache:YiBFZmBkNHYJ:https://github.com/FoundationDB/celery-layer/blob/master/fdb_celery/fdb_task.py+&cd=1&hl=en&ct=clnk&gl=us http://webcache.googleusercontent.com/search?q=cache:YiBFZmB...
- barosl 12y ago
jordz 12y 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?
- lclarkmichalek 12y 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 http://news.ycombinator.com/item?id=8745462
  - deleted 12y ago
    [deleted]
- lastRecon 12y 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/known.limitations.html#fdbsql-known-limitations 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?
jordi92 12y 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.
- 15155 12y ago
  Neither of those even come close to the out-of-the-box performance you could see with FDB.
  - Rapzid 12y ago
    Numbers? I would like to see some test results out of curiosity.
  - juanido 12y ago
    And both are not key/value stores. They are multi-model databases with the focus on documents and graphs.
kolev 12y ago
Very well said!
- kolev 12y 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.
  - deleted 12y ago
    [deleted]
  - reitanqild 12y 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. : )
    - kolev 12y ago
      It surely does affect sorting or silencing unpopular voices, but unless it's a top-level comment, it doesn't really matter. Plus, most people who one should care about when making the effort to post a comment, read at least all top comments and scan the rest. Second-level and deeper comments usually get lost unless they are attached to a "popular" top comment or the discussion is small. Also, if you have a unpopular opinion, you should be scared to reply to a reply as the same people who downvoted your first comment and invest their time in downvoting the reply as well. The commenting system here is prehistoric and lacks basic understanding of psychology. It stimulate ass kissers, not people with unique views and unpopular opinions that can actually add some additional perspectives to otherwise the monotonous highfiving.
      - pauloday 12y ago
        I think the problems you describe are with people (so therefore should be dealt with through community standards etc.), not the karma system. How would you improve it?
kolev 12y ago
How did it compare to ActorDB [0]? [0] http://www.actordb.com/ http://www.actordb.com/
nickleefly 12y ago
Hope app store can be faster
- deleted 12y ago
  [deleted]
cynicalkane 12y 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 12y 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 12y 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 https://foundationdb.com/files/Architecture.pdf
- biokoda 12y ago
  I think the closest cousin is ActorDB http://www.actordb.com/ http://www.actordb.com/
- jhugg 12y 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 https://news.ycombinator.com/item?id=9262673
- bdarnell 12y 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 12y ago
Woa, that was unexpected! So sad to see this great piece of software dragged to Apple dungeons.
deleted 12y ago
[deleted]
deleted 12y ago
[deleted]
teeray 12y ago
One of their engineers gave a great talk at Strangeloop (https://m.youtube.com/watch?v=4fFDFbi3toc 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.
datashovel 12y ago
I don't want to believe it, but I'm starting to think Apple is the new Microsoft / Oracle.
- zak_mc_kracken 12y 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.
  - datashovel 12y ago
    Actually nothing is surprising about it IMO. But I always get downvotes when I appear to be bashing Apple too hard :)
Donch 12y 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 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 12y 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 12y 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."
jordanthoms 12y 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_kracken 12y 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.
  - jordanthoms 12y ago
    True, although said replacement will probably have to be open source to pick up any serious usage.
  - sjwright 12y 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.
    - zimpenfish 12y ago
      You could add "acquire and turn minimally viable products into world-spanning domination, look no further than Touchstream"
    - deleted 12y ago
      [deleted]
jaimebuelta 12y ago
About FoundationDB, they have this blog post about achieving almost 15 million writes per second http://blog.foundationdb.com/databases-at-14.4mhz http://blog.foundationdb.com/databases-at-14.4mhz It's a pretty impressive number, though as always with benchmarks, should be taken with care.
- 15155 12y 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 12y 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 12y ago
And this is why my chef broke todya.
krick 12y 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 12y 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.
systemtheory 12y ago
yet another argument for rethinking the open source model.
- systemtheory 12y 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.
  - takeda 12y 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.
    - systemtheory 12y ago
      I believe you don't know what you're talking about. Forbe's thought it was an open source issue. I don't think many would say Forbe's has a radical open source "agenda". http://www.forbes.com/sites/benkepes/2015/03/25/a-cautionary-open-source-tale-apple-buys-and-shutters-foundationdb/ http://www.forbes.com/sites/benkepes/2015/03/25/a-cautionary... EDIT: just to clarify, i'm not saying Forbe's said FDB is open source. i'm pointing to the fact that someone that writes for a national business magazine about open source issues thought it was an open source "issue". if persons working in open source can hope to make a living, counting business as a stakeholder is a good idea.
      - takeda 12y ago
        Are you for real? Are you telling me that a someone's blog on a business magazine has a larger knowledge of technology than someone who's actively involved in it? If you have a medical condition do you also read health industry section in Wall Street Journal? By the way, if you did not see it there was an update posted that states that FDB was closed source. It also doesn't matter that some components were open source or not, because without FDB they are useless either way.
jhugg 12y 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 12y 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.)
  - jhugg 12y 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.
deleted 12y ago
[deleted]
Galactigon 12y ago
Fantastic! Good to see a software company elevated.
Gurrewe 12y 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_sar 12y ago
  Consider MySQL compatible ActorDB
eklavya 12y ago
If foundationdb was open source, can't the community continue with the last open sourced release?
- Gurrewe 12y ago
  It was closed source, with only parts of it being OSS.
  - eklavya 12y 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?
    - ohitsdom 12y ago
      The full source wasn't available, but at least the product was available to the market. With Apple buying it up and taking down the source repos and the full product download page, the tech is lost to anyone outside of Apple.
rhoml 12y ago
Too bad not many people read this https://twitter.com/ibobrik/status/454205142662119424 https://twitter.com/ibobrik/status/454205142662119424
gkya 12y 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 12y 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_sar 12y 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 12y 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 http://goo.gl/KVQxyq

483 points by ea016 12y 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 12y ago
You can no longer download from their website. So, I'd assume yes, we all wasted our time.
- tjholowaychuk 12y ago
  Yeah, noticed our CI failing :( ... so not cool

threeseed 12y 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 12y 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.
eternalban 12y ago
Why antagonize the community by pulling repos if they only wanted the brains?
- wmf 12y 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.
  - lbarrett 12y ago
    Isn't following a policy like that at all a fault?
    - Gigablah 12y ago
      Yes, if putting "Apple" and "1984-like" in the same sentence wasn't obvious enough :)
  - zak_mc_kracken 12y ago
    The irony s thick considering that landmark 1984 ad they published during the Superbowl... Apple used to claim to fight against Big Brother, today they are largely seen as Big Brother. Thank god for Android for keeping them honest.
- spiralpolitik 12y 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 12y ago
Apple released CloudKit last year. It's not web and multiplatform like Parse, but it's similar to Parse's initial offering.

jasondc 12y ago

Anyone running FDB in production, good luck, downloads are removed from https://foundationdb.com/ https://foundationdb.com/ I don't understand why anyone would run a closed source database, especially with the open source options available.

smt88 12y 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 12y 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.
  - smt88 12y ago
    This doesn't have to be the case. What if startups with high switching costs (DBMS, OS, pretty much anything else infrastructural) added a guarantee to their sales contracts? For example, it could be that, if they get acquired, they'll open-source the technology, sell it to another for-profit entity that will maintain it, or provide a migration tool. Even for something like FoundationDB, it'd hardly be any skin off Apple's back to have a few employees spend a few months ensuring that previous customers have some sort of support.
    - josho 12y ago
      This is simply the risk you take being an early adopter. If you are uncomfortable with the risk then choose something from IBM/oracle/et al.
      - smt88 12y ago

ChuckMcM 12y ago

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

jacquesm 12y ago
Be happy that you didn't!
- ChuckMcM 12y 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.
  - jacquesm 12y ago
    Hehe, that's so scary :) I'm busy sketching out something exactly like that at the instigation of my son (who is an avid gamer). I'm nowhere near realizing the vision but I've learned an awful lot just studying the problem from different angles. The key element seems to be 'who owns that data?'.
    - ChuckMcM 12y ago
      Exactly, so the player can be modeled as an index attached to several database records. You end up doing a geo-box select (see earlier posting here about why geo information data bases are hard), an inventory select, an equipment select, and an attributes select by player-id. The linkage is (player-id, geo) -> key for 'world' based databases, (player-id) -> key for 'player specific' databases. When you go to do an action you combine the action mechanics (pick up -> delete from world, add to inventory), (attack -> (roll) -> edit other attributes of monsters/players near by), (defend (roll) -> edit player attributes)) and (drop -> delete from inventory, add to world). Where at 'n' frames per second you need to do a select for a given view point to identify what the rendering engine needs to "show". Clearly doing this with ascii characters on a terminal screen is much easier than trying to render 3D avatars in the real world but the number of database transactions per second becomes massive. If we posit that there are 1,000 players visible to the current player, and just the player / world select is a single transaction, then at 30 fps, that is 60,000 or so queries per second, you throw actions between players, and between multiple players (area of effect attacks) and add another 2,000 monsters and you're easily over 250,000 transactions per second. Since FoundationDB was talking millions of transactions per second with full ACID it seemed like it would be a useful back end for this. Or put another way, you could contemplate building this and see if their product was actually able to keep up at this rate. And they asserted this was on modest hardware (like 32 nodes). So yes, I was looking forward to the interesting places that investigation would lead and the things I could learn.

jsherer 12y 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 12y ago

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

orand 12y 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 12y 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 12y 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.
  - cgag 12y ago
    Free people not being able to match the pace of people desperately trying to free themselves from wage slavery doesn't strike me as a great justification of wage slavery. Not that I agree with the premise that capitalism is what drives people to produce things to begin with.
    - logicchains 12y ago
      Are these people trying to desperately free themselves from wage slavery the same people who spend most of their time watching tv, playing games or caring for children nobody forced them to have? If so they don't seem so desperate to me. Generally the people I've met who work hard to develop themselves and develop skills society needs end up doing quite well for themselves, although I admit that as an Australian my experience is probably different from the US. Here we have more socialised education and healthcare, so anyone with motivation can go to college.

0xFFC 12y 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.

lclarkmichalek 12y ago
Distributed ACID transactions. Very good testing regime. Good performance. Basically the NewSQL dream.
- slantedview 12y ago
  This, and there is (or was) nothing else like it in the marketplace.
  - icefox 12y ago
    Well if it truly mattered out there right now there is a company that has a void that they need filling and all they have to do is speak up and help fund a replacement.
    - orand 12y ago
      That won't do much good when all the rare talent needed to build it is locked up at Apple and Google.
      - lectrick 12y ago
        There's other rare talent coming online all the time.
        orand 12y ago
        Well in that case, this problem should solve itself any day now. /s
- 12y ago

amluto 12y 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 12y 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.
rodgerd 12y 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 12y 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 12y ago

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

raspasov 12y 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 12y ago
  You mean AP, not CA. CA doesn't exist.
  - raspasov 12y ago
    Thanks man, good you caught it, I totally knew that, I need to be more careful with acronyms right after waking up :)
  - napoleond 12y ago
    > CA doesn't exist. I'm not sure that's a good way of putting it. You can have databases that offer both consistency and availability, but they need to fit on a single machine (no partition tolerance).
    - cjbprime 12y ago
      > I'm not sure that's a good way of putting it. You can have databases that offer both consistency and availability, but they need to fit on a single machine (no partition tolerance). Garbage collection requires (a delay that is indistinguishable from) partition tolerance. It's pretty illusory on single machines as well. Especially if they're multi-core.

jaytaylor 12y 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 http://community.foundationdb.com/index.html [1] https://github.com/FoundationDB/ https://github.com/FoundationDB/ [2] http://blog.foundationdb.com/7-things-that-make-google-f1-and-the-foundationdb-sql-layer-so-strikingly-similar 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 http://research.google.com/pubs/pub41344.html

josephpmay 12y 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 12y ago
Looks like an acquire hire and product kill scenario.
mdasen 12y 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.

justin66 12y ago

All the company's github repositories have been pulled: https://github.com/FoundationDB/ https://github.com/FoundationDB/

clord 12y ago
If someone has a recent clone and the licence was compatible, is there a reason a fork can't be started?
- threeseed 12y ago
  Apple has incentives for engineers to file patents. Always something to be mindful of.
amirmc 12y 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.
- 72deluxe 12y ago
  Put it on Google Code. Oh, hang on....
- jaytaylor 12y ago
  I have a copy of the SQL layer from March 1st, 2015. It's up on github: https://github.com/jaytaylor/sql-layer https://github.com/jaytaylor/sql-layer
PublicEnemy111 12y ago
If someone is desperate enough, they can recreate the repositories using google cache. See http://webcache.googleusercontent.com/search?q=cache:YiBFZmBkNHYJ:https://github.com/FoundationDB/celery-layer/blob/master/fdb_celery/fdb_task.py+&cd=1&hl=en&ct=clnk&gl=us http://webcache.googleusercontent.com/search?q=cache:YiBFZmB...
barosl 12y ago

jordz 12y 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?

lclarkmichalek 12y 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 http://news.ycombinator.com/item?id=8745462
- deleted 12y ago
  [deleted]
lastRecon 12y 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/known.limitations.html#fdbsql-known-limitations 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?

jordi92 12y 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.

15155 12y ago
Neither of those even come close to the out-of-the-box performance you could see with FDB.
- Rapzid 12y ago
  Numbers? I would like to see some test results out of curiosity.
- juanido 12y ago
  And both are not key/value stores. They are multi-model databases with the focus on documents and graphs.

kolev 12y ago

Very well said!

kolev 12y 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.
- deleted 12y ago
  [deleted]
- reitanqild 12y 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. : )
  - kolev 12y ago
    It surely does affect sorting or silencing unpopular voices, but unless it's a top-level comment, it doesn't really matter. Plus, most people who one should care about when making the effort to post a comment, read at least all top comments and scan the rest. Second-level and deeper comments usually get lost unless they are attached to a "popular" top comment or the discussion is small. Also, if you have a unpopular opinion, you should be scared to reply to a reply as the same people who downvoted your first comment and invest their time in downvoting the reply as well. The commenting system here is prehistoric and lacks basic understanding of psychology. It stimulate ass kissers, not people with unique views and unpopular opinions that can actually add some additional perspectives to otherwise the monotonous highfiving.
    - pauloday 12y ago
      I think the problems you describe are with people (so therefore should be dealt with through community standards etc.), not the karma system. How would you improve it?

kolev 12y ago

How did it compare to ActorDB [0]? [0] http://www.actordb.com/ http://www.actordb.com/

nickleefly 12y ago

Hope app store can be faster

deleted 12y ago
[deleted]

cynicalkane 12y 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 12y 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 12y 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 https://foundationdb.com/files/Architecture.pdf

biokoda 12y ago
I think the closest cousin is ActorDB http://www.actordb.com/ http://www.actordb.com/
jhugg 12y 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 https://news.ycombinator.com/item?id=9262673
bdarnell 12y 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 12y ago

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

deleted 12y ago

[deleted]

deleted 12y ago

[deleted]

teeray 12y ago

One of their engineers gave a great talk at Strangeloop (https://m.youtube.com/watch?v=4fFDFbi3toc 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.

datashovel 12y ago

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

zak_mc_kracken 12y 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.
- datashovel 12y ago
  Actually nothing is surprising about it IMO. But I always get downvotes when I appear to be bashing Apple too hard :)

Donch 12y 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 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 12y 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 12y 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."

jordanthoms 12y 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_kracken 12y 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.
- jordanthoms 12y ago
  True, although said replacement will probably have to be open source to pick up any serious usage.
- sjwright 12y 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.
  - zimpenfish 12y ago
    You could add "acquire and turn minimally viable products into world-spanning domination, look no further than Touchstream"
  - deleted 12y ago
    [deleted]

jaimebuelta 12y ago

About FoundationDB, they have this blog post about achieving almost 15 million writes per second http://blog.foundationdb.com/databases-at-14.4mhz http://blog.foundationdb.com/databases-at-14.4mhz It's a pretty impressive number, though as always with benchmarks, should be taken with care.

15155 12y 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 12y 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 12y ago

And this is why my chef broke todya.

krick 12y 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 12y 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.

systemtheory 12y ago

yet another argument for rethinking the open source model.

systemtheory 12y 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.
- takeda 12y 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.
  - systemtheory 12y ago
    I believe you don't know what you're talking about. Forbe's thought it was an open source issue. I don't think many would say Forbe's has a radical open source "agenda". http://www.forbes.com/sites/benkepes/2015/03/25/a-cautionary-open-source-tale-apple-buys-and-shutters-foundationdb/ http://www.forbes.com/sites/benkepes/2015/03/25/a-cautionary... EDIT: just to clarify, i'm not saying Forbe's said FDB is open source. i'm pointing to the fact that someone that writes for a national business magazine about open source issues thought it was an open source "issue". if persons working in open source can hope to make a living, counting business as a stakeholder is a good idea.
    - takeda 12y ago
      Are you for real? Are you telling me that a someone's blog on a business magazine has a larger knowledge of technology than someone who's actively involved in it? If you have a medical condition do you also read health industry section in Wall Street Journal? By the way, if you did not see it there was an update posted that states that FDB was closed source. It also doesn't matter that some components were open source or not, because without FDB they are useless either way.

jhugg 12y 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 12y 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.)
- jhugg 12y 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.

deleted 12y ago

[deleted]

Galactigon 12y ago

Fantastic! Good to see a software company elevated.

Gurrewe 12y 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_sar 12y ago
Consider MySQL compatible ActorDB

eklavya 12y ago

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

Gurrewe 12y ago
It was closed source, with only parts of it being OSS.
- eklavya 12y 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?
  - ohitsdom 12y ago
    The full source wasn't available, but at least the product was available to the market. With Apple buying it up and taking down the source repos and the full product download page, the tech is lost to anyone outside of Apple.

rhoml 12y ago

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

gkya 12y 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 12y 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_sar 12y 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 12y 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 http://goo.gl/KVQxyq