NoSQL Benchmarks NoSQL use cases NoSQL Videos NoSQL Hybrid Solutions NoSQL Presentations Big Data Hadoop MapReduce Pig Hive Flume Oozie Sqoop HDFS ZooKeeper Cascading Cascalog BigTable Cassandra HBase Hypertable Couchbase CouchDB MongoDB OrientDB RavenDB Jackrabbit Terrastore Amazon DynamoDB Redis Riak Project Voldemort Tokyo Cabinet Kyoto Cabinet memcached Amazon SimpleDB Datomic MemcacheDB M/DB GT.M Amazon Dynamo Dynomite Mnesia Yahoo! PNUTS/Sherpa Neo4j InfoGrid Sones GraphDB InfiniteGraph AllegroGraph MarkLogic Clustrix CouchDB Case Studies MongoDB Case Studies NoSQL at Adobe NoSQL at Facebook NoSQL at Twitter



Why startups should not choose NoSQL

So to summarize – don’t sacrifice flexibility and ease of work for some fictional “trillions of petabytes”. If it happens that you need to handle huge amounts of data, it will be in a way that you will be able to restructure your data model. And at a point when you will know what questions you want to ask.

Questions for the author — admittedly I might have missed a couple:

  1. is it easier to maintain a series of migrations or use a schema-less storage until you nail your model?
  2. is it more efficient to pre-compute some results or to put them together over and over and over again?
  3. is it worth caching some of the results or are you better off computing them every time?

I cannot make up my mind.

Original title and link: Why startups should not choose NoSQL (NoSQL databases © myNoSQL)