On my personal projects, my default database choice is Postgres unless I have a glaring, obvious reason to choose something NoSQL (in which case I like CouchDB if the situation calls for a document store, don't know much about the others).<p>At work, it doesn't matter if we have a perfect use case for a particular NoSQL solution (I'm working on something now that I think would be a great fit for a Graph database like Neo4J). We use Oracle, because it's expensive, we're already paying for it, so damn it, we're going to use it.
One slightly concerning thing about this is the table at the end dictating what popular NoSQL DBs do is populated by, and here I quote - "The methodology used to identify the specific system properties consists of an in-depth analysis of publicly available documentation and literature on the systems. Furthermore, some properties had to be evaluated by researching the open-source code bases, personal communication with the developers as well as a meta-analysis of reports and benchmarks by practitioners."<p>Which looking at the table, doesn't seem to include Aphyr's work (Jepsen), so much of what is being said may in fact be wrong. I'd prefer a chart populated from that (though admittedly such a chart would largely be "undefined", "inconsistent", etc).
This article will soon become outdated: CouchDB 2.0 is in release candidate stage, and will soon be released. It features built-in and automatic sharding and clustering and a new, MongoDB-inspired document query language...and lots of small improvements as well.<p>For more information, read the excellent blog posts from their official blog: <a href="https://blog.couchdb.org/" rel="nofollow">https://blog.couchdb.org/</a>
This is pretty useful for someone like me who's been in large companies using Teradata forever, just to understand the NoSQL products out there and potential use cases. On any given day, I feel like I've fallen way behind on database technology simply because we're fairly locked in, admittedly very happy with TD. It's helpful to keep up here though, because we do have some projects we'd like to do that would probably work better outside of an RDBMS.<p>I'd love to see something similar on the various ETL/data pipeline tools. In that regard, we still write a ton of SAS code because we have a variety of sources, which SAS does well, pretty solid if you need to do some data cleansing into the target, and the code itself is very batch-friendly and maintainable. It's been a while since I've surveyed alternatives.
Great to see RethinkDB covered (although it would have been better if it was included in the primary comparison tables too).<p>It feels like a second-generation NoSQL database where most of the drawbacks with earlier NoSQL-databases has been taken care of!
I enjoyed this topic while researching New Data: a Field Guide [1]. In my research I've come to really enjoy ArangoDB. It has good support for documents, performance, relational data queries and basic graphs. Without doing the research I don't think I would have ever dug into the new tools. If you ever get a chance to do a small prototype, looking using these tools.<p>1- <a href="https://leanpub.com/NewDataAFieldGuide" rel="nofollow">https://leanpub.com/NewDataAFieldGuide</a>
I'd point out that there are arguments[1] that 'CA' is not a real choose you can make when it comes to the CAP theorem.<p>1: <a href="https://codahale.com/you-cant-sacrifice-partition-tolerance/" rel="nofollow">https://codahale.com/you-cant-sacrifice-partition-tolerance/</a>
Felix, author of the article and founder of Baqend [1] here. I'm happy to answer any questions. If you have suggestions for the next version of the article, we're eager to hear them.<p>[1] <a href="http://www.baqend.com" rel="nofollow">http://www.baqend.com</a>
boo. doesn't include a comparison vs Google's NoSql SaaS offerings (Cloud DataStore and BigTable).<p>i personally use Cloud DataStore and find it a great fit, wish there was some comparisons against it.
If you wish an introduction to NoSQL there is a good webinar at <a href="http://www.prohuddle.com/webinars/nosql/NoSQL_Distilled.php" rel="nofollow">http://www.prohuddle.com/webinars/nosql/NoSQL_Distilled.php</a>, which includes discussions, examples and comparisons.
serious question, what is to stop everyone (where a K/V store is not enough) from just chucking some form of SQL server in a VM in a ramdisk and using that? I've always wondered about that idea
Slightly off topic but: As someone out of touch on the topic of DB utilizing apps for a while, what's the update on the ORM impedance mismatch? (I mean the guidelines or best practices).
The TL;DR was TL;DR. Ho, seriously. About halfway through, the buzzwords and jargon got to be too much for me. Let me know if there's anything interesting Wining.