
Apple Acquires FoundationDB - ea016
http://techcrunch.com/2015/03/24/apple-acquires-durable-database-company-foundationdb
======
jasondc
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.

~~~
throwawaymsft
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.

~~~
rylee
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.

~~~
_nedR
The life-cycle of the parasite is also illustrated in a great oatmeal comic :

[http://theoatmeal.com/comics/captain_higgins](http://theoatmeal.com/comics/captain_higgins)

~~~
trhway
or in the song

[https://www.youtube.com/watch?v=YIs_rikRREE&list=PLHZxQw_SbV...](https://www.youtube.com/watch?v=YIs_rikRREE&list=PLHZxQw_SbVz6K6VAE_sfoYrPUrjFW1lu9&index=5)

------
orand
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. :-(

~~~
jamie
Worth following the development of cockroachdb
[https://github.com/cockroachdb/cockroach](https://github.com/cockroachdb/cockroach)

The long term goals of that project seem to align.

~~~
Altenuvian
Also have a look into HyperDex: [http://hyperdex.org/](http://hyperdex.org/)

~~~
justin66
Aren't they doing some kind of goofy open source/proprietary differentiation,
just like FoundationDB was doing? It looks like "the full copy of HyperDex
Warp" (whatever that means) is what people are expected to pay for.

~~~
otis_inf
Hyperdex is the result of their ongoing research at Cornell University. They
have a commercial spinoff which sells Hyperdex Warp which adds full ACID
transactions on hyperdex. So if you don't need full acid transactions, you can
use the OSS version, if you want the extra services you have to pay.

It's the same with all software, really: to be able to do a large scale
project you have to have funding from somewhere, as you need developers full
time working on it to fix/write the stuff no-one wants to fix/write. Some OSS
projects get this funding indirectly by sponsored developers who work at
company X and write OSS code all day for the project (this is what Linux
uses). Other projects are funded by VC money, licenses, support contracts or
ads. It's not common a large scale OSS project is successful and stays
successful without any funding from the outside.

Thus, if a piece of software gets its funding by selling licenses (like with
Hyperdex Warp), it's the same as with a company getting funding by sponsoring:
if the cashflow stops, the show ends. In the case of OSS you can grab the
sourcecode at least, but in the end, to successfully maintain that it takes a
lot of effort most of the time, as the projects are often large, complex and
the internals unknown to the user.

------
sporkland
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)

~~~
jhugg
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)

------
justin66
All the company's github repositories have been pulled:

[https://github.com/FoundationDB/](https://github.com/FoundationDB/)

~~~
ccleve
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
Try [https://github.com/hudak/sql-parser](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.

~~~
jaytaylor
More up to date: [https://github.com/jaytaylor/sql-
layer](https://github.com/jaytaylor/sql-layer)

------
jordanthoms
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
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.

~~~
sjwright
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
You could add "acquire and turn minimally viable products into world-spanning
domination, look no further than Touchstream"

------
jaytaylor
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-an...](http://blog.foundationdb.com/7-things-that-make-
google-f1-and-the-foundationdb-sql-layer-so-strikingly-similar)

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

~~~
mdasen
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
CUPS was fully open source when it was acquired.

------
0xFFC
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
Distributed ACID transactions. Very good testing regime. Good performance.
Basically the NewSQL dream.

~~~
itchyouch
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.

~~~
bbulkow
Financial services companies have three different issues: * Banks don't do
multi-record SQL (see Brewer's article on the topic) * They don't do many
transactions * Nobody got fired for buying oracle or DB2

An oracle replacement won't be built for financial services companies.

~~~
smiler
Can you link to Brewer's article please...

------
cynicalkane
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
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.

------
jhugg
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
> 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
> 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.

------
teeray
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.

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

------
threeseed
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.

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

~~~
wmf
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
Isn't following a policy like that _at all_ a fault?

~~~
Gigablah
Yes, if putting "Apple" and "1984-like" in the same sentence wasn't obvious
enough :)

------
tjholowaychuk
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
You can no longer download from their website. So, I'd assume yes, we all
wasted our time.

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

------
jaimebuelta
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
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.

------
jordi92
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
Neither of those even come close to the out-of-the-box performance you could
see with FDB.

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

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

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

~~~
raspasov
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
You mean AP, not CA.

CA doesn't exist.

~~~
napoleond
_> 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
> 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.

~~~
Jweb_Guru
They might be related formally (though I'm not really sure). In practice,
relational databases generally implement very special-purpose concurrent
garbage collectors that will totally lock up only under pathological
circumstances (though I won't pretend that it doesn't happen). If you're
talking about GC in general, with special-purpose hardware and/or real time
kernels, GC times can be bounded deterministically and are thus
distinguishable from a partition (except in rare cases, as with all garbage
collectors with cycle collection, where they must revert to stop-the-world
because they can't reclaim memory fast enough). And, of course, it is possible
to write actual real time systems that do not require garbage collection at
all (though scant few of them have been formally verified to the extent that
one might like).

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

~~~
lastRecon
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...](https://foundationdb.com/layers/sql/documentation/Concepts/known.limitations.html#fdbsql-
known-limitations)). 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_sar
To support my previous comment. Quoting David the founder:
[http://techcrunch.com/2012/09/10/foundationdb-not-your-
stand...](http://techcrunch.com/2012/09/10/foundationdb-not-your-standard-
nosql-database/)

“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.”

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

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

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

~~~
eklavya
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
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.

------
amluto
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.

~~~
rodgerd
> 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
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.

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

~~~
jacquesm
Be happy that you didn't!

~~~
ChuckMcM
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
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
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.

~~~
jacquesm
I sent you that mail, please check your spambox since google has an alarmingly
high rate of false positives these days, even with people that you've already
exchanged email with in the past they'll happily bin messages. Highly
annoying.

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

------
kahunamoore
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

------
gkya
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.

------
kolev
How did it compare to ActorDB [0]?

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

------
PeterCorless
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)

------
Gurrewe
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
Consider MySQL compatible ActorDB

------
jsherer
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?

------
rhoml
Too bad not many people read this
[https://twitter.com/ibobrik/status/454205142662119424](https://twitter.com/ibobrik/status/454205142662119424)

------
film42
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.

------
kore_sar
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!

------
chx
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
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."

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

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

------
magd
And this is why my chef broke todya.

------
kolev
Very well said!

~~~
kolev
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.

~~~
reitanqild
> 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
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
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
The karma system is a crowd-sourced pseudo-automated, and greatly imperfect
system to enforce community standards. It's not even using the "wisdom of the
crowds" as it's mixing different things into a single meaningless number. It
has some completely random ranges that give you different privileges (read
"lift restrictions").

I haven't really thought about this, but here are some changes that I would
borrow from here and there with some that I haven't seen elsewhere:

\- a downvote costs you something (a karma point or half a point) ala
StackExchange, which makes you think twice before you're urged to punish;

\- categorize votes ala BuzzFeed reactions insteading mindlessly
up-/downvoting;

\- your karma gets a share of the collective karma of your reply tree - those
who start vivid discussions should be rewarded;

\- reward with own karma - if you really like somebody's comment, why not
donate some of your own karma and reward quality comments with more than 1
point;

\- there's no point to keep punishing somebody for their multiple replies -
this silences voices; you should be able to pick and rate the overall
participation of somebody in the thread, not punish them multiple times for
each attempt for them to convey the same thing.

~~~
chrisper
I don't even see a downvote button. When I came here first I thought nice you
can only upvote here, so the community must be nice. Got down voted pretty
quickly. What does even green username mean?

~~~
engi_nerd
From some discussion earlier today, you must have a collective score of 500
upvotes before you have the ability to downvote. I would guess that is to
enforce a period where new accounts can get used to the generally accepted
standards for discussion here.

~~~
chrisper
Thanks. I had 7 but now I have 5... lol

------
systemtheory
yet another argument for rethinking the open source model.

~~~
systemtheory
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
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
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...](http://www.forbes.com/sites/benkepes/2015/03/25/a-cautionary-
open-source-tale-apple-buys-and-shutters-foundationdb/) 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
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.

------
nickleefly
Hope app store can be faster

