If MongoDB is regarded as a poor product[1,2,3] then what should one use instead?<p>I feed a document database is the correct decision for my domain, so would prefer to choose a superior product now rather than regret it later.<p>[1] http://pastebin.com/raw.php?i=FD3xe6Jt
[2] http://mcfunley.com/why-mongodb-never-worked-out-at-etsy
[3] http://www.sarahmei.com/blog/2013/11/11/why-you-should-never-use-mongodb/
Your "poor product" examples are really poor.<p>[1] <a href="http://pastebin.com/FD3xe6Jt" rel="nofollow">http://pastebin.com/FD3xe6Jt</a> was debunked in 2011 when it first appeared.<p>[2] The Etsy article from 2012 had the major point "if you are considering Mongo plus another database like MySQL, then in all likelihood you shouldn't do it [...] Keep in mind that almost none of this is specific to MongoDB. I wouldn't discourage anyone from trying Mongo out if they're starting a new site"<p>[3] As one commentator stated, "don't use a non-relational store when you have relational data."<p>The most important thing you need to do is probably confirm your feeling regarding a document database being the correct decision for your domain. [2] and [3] concluded by using MySQL rather than MongoDB, but for different reasons. Why do you think a not-MongoDB, but not-SQL database is correct for you?
How can you expect an answer about a storage system without giving us a detailed use-case?<p>One of the main reasons MongoDB is regarded as a poor product is because people try to use it in completely inappropriate situations. OK, MongoDB has some bad design choices, but it can be an interesting system in some cases.
Honestly Mongodb is as good as it gets if you want to query your JSON data. Yes it might have a few challenges when it comes to scalability and disk usage but I don't think its anything that can't be addressed with a carefully thought out architecture. I believe Tokutek with TokuMX is addressing some of the shortcomings of Mongodb. Though I'm a bit surprised that 10gen hasn't officially commented on Tokutek's contribution.<p>The other NoSQL solutions that would come close are CouchDB and RavenDB. I haven't tried the latter but CouchDB doesn't allow easy adhoc querying and you really have to give some thought to your Map/Reduce Views/Scripts.<p>CouchDB is great because it also allows you to attach binary content to your JSON documents so it's great as a CMS backend but as I mentioned before, querying your data isn't as pleasant as with Mongodb.<p>Now Mongodb does have GridFS for binary data storage but it isn't IMHO as simple to use compared to CouchDB's 'Attachments'.
The product is an aggregator of sorts, very flat domain. The only thing apart from the items being collected are categories which are denormalized on aggregation - they have a short lifespan anyway.<p>RE: Write/Read/Update heavy, it's going to be a mixture. Once users are present it will be read heavy. The backend is constantly collecting new data and updating if changes are spotted.<p>I'm 99% certain a document database/ non-relational approach is suitable here. I have nothing against MongoDB - I just want to make these decisions now. I've enjoyed using it so far.<p>Thanks for feedback!
Write-heavy, read-heavy, update-heavy, or all?<p>Consistent world-view or quick answers?<p>Gigabytes per day or terabytes per day?<p>Is the Time axis important? Do you need to go back in time and query the state of the world? Do you need queries that relate the state of the world in two different points of time?<p>Hmm, I should probably be charging you for this! :-) I'm distilling years down the rabbit hole into these paragraphs + saving you months of discovery.