Skip to content

Comment on FoundationDB — Not Your Standard NoSQL Databaseparent

Comments

Different FoundationDB founder here :)

We'd be happy to give you information that would be helpful for your document - your offer to put something like that together is generous, helpful, and we'll definitely take you up on it.

Why don't you shoot me an email at nick dot lavezzo at foundationdb. If you're at Disrupt or in the SF area we might even be able to get together before we head back to DC on Thursday morning.

Thanks again for the helpful comments and interest!

I am speaking more generally -- I'm not evaluating a new database for my toolchain at the moment, and to be honest, I am very shy of anything that is proprietary-only. However, I thought your ideas were interesting regardless, so I felt compelled to defend their interesting-ness.

I'm just tired of trying pierce through proprietary database literature language to sort a new database system that has Apparently Magical Properties into the multi-dimensional bin of tradeoffs. Consider the FAQ for Redis: http://redis.io/topics/faq

Or, the very short rundown in the second half of the home page of Postgres-XC http://postgres-xc.sourceforge.net/, although it probably could use some fine-tuning. Many of the developers, including the first one, are not native english speakers.

A good example in proprietary-land is Datomic: http://www.datomic.com/faq.html. Here's a good paragraph:

    How does Datomic handle consistency, availability and scale?  Because
    Datomic separates the handling of transaction processing and
    query/read, it can make independent choices for each
    facility. Transactions favor consistency over availability, and the
    loss of a transactor will require traditional failover
    approaches. Queries and reads, however, are serviced by the highly
    available, replicated and scalable infrastructure of DynamoDB. And,
    since the data segments stored by Datomic in Dynamo are immutable,
    they are always consistent. Thus, Datomic is well suited for
    applications that require write consistency and read scalability.
On the other hand, I really appreciate your benchmarks to give me a ballpark idea, and think it's great that you offer them up so easily. They could probably take a less pronounced position in your literature if you find you are in need of space for other material, though.

I see what you mean - thanks for the clarification. We'll be working on a FAQ to get up on the website soon, and we'll also be putting up a blog where we'll cover areas of particular interest in detail. I'm sure CAP will be one of the earliest topics covered, but we've made a lot of important design decisions while building this product and they should all make for interesting reading.

We've done our best to take the technical high road in those hard decisions - generally trading in ease of (our) development for stronger guarantees, more rigorous testing, and higher performance. We're excited to talk about our development process and decisions with the world. Looks like we've got some writing to do :)

AboutSource Built by g1lg1l

Hackerly is an independent reader for Hacker News, built on the public HN API. Not affiliated with Y Combinator.