What 10gen nailed with MongoDB

This article is spot-on, but 10gen did one more thing they probably shouldn't have: marketed their not-very-scalable, not-very-durable database as a solution to problems companies were having with scalability and durability.

&#62; Think about a web developer who shows up to a hackathon, ready to break out his new side project. He doesn’t want to spend hours planning schema or creating databases and tables. He just wants a quick way to persist and retrieve data.<p>When you say that, this is what I hear:<p>&#62; MongoDB is the quickest way to accrue large quantities of technical debt.<p>In this analogy, fast accrual of debt leads to one place: bankruptcy. Which, in software engineering, is the ground-up rewrite.

&#62; For 90% of web development cases, simply storing and retrieving objects from a persistent store is enough of an API.<p>"90%", that's quite a specific number.<p>Most of what I've written for the past fifteen years is web apps, and I'd say about 10% fall into the "all I need is put and get objects" category. Especially once I knew how to use SQL effectively, especially once I knew how to work with ACID, these features became irreplaceable in almost every project I've worked with.<p>IMHO it's all about what you're familiar with. Rich Hickey thinks we're morons for using OOP, as he's a brilliant functional guy. Shrugs.

&#62; Think about a web developer who shows up to a hackathon [...] He just wants a quick way to persist and retrieve data.<p>This is the _worst_ reason to use Mongo.<p>If you are doing a hackathon or just prototyping and need persistence, use pickle. Or store JSON to a text file. Who cares what the solution is. It should:<p>a) Be built into the standard library. b) Not require bringing up another service to work.<p>[Edit.. clarity in the quote]

MongoDB does pretty much everything the opposite of Oracle: Easy to setup, use and program.<p>However, Oracle sure is raking in the dough, so is Mongo succeeding simply because they're fulfilling a niche left by Oracle, or because it's the 'right way' to build a software product company?<p>I hope the answer is the latter, and that Oracle's billions are simply the result of the being entrenched after years and years of doing it the 'old way. That being said, I think it's a little too early to be championing Mongo's business model (even though I'm rooting for it).

Although I am a heavy user/believer of MongoDB, one caveat that is overlooked in this article is the administration part of Mongo Clusters.<p>Even the simplest replication needs 3 servers, add sharding to the dance for extra performance and the server counter jumps up. For startups this is a major decision to consider as a full-time ops guy isn't always affordable. Luckily, PaaS services as MongoLabs and MongoHQ save the day.

I was nailed by MongoDB. It's a great database for prototyping, but all projects that go anywhere run into its limitations: scale, durability, intimate relationship with OS, ease of administration. MongoDB is right for some projects, but in many cases is not. So if you know that you can transition from it at a later point, it gets you off to a flying start. If you foresee that it will be hard to switch later, I would advice spending some time considering future scenarios upfront.

Nailing community and ease of use (drivers for everything, easy to install) and documentation wouldn't have been much use if the product sucked; it doesn't.<p>A lot of people that I've seen with issues around Mongo haven't understood how it's expected to be used: i.e. it's not a relational database and the schema design is therefore different.

Interestically someone just released a new async scala drivers : <a href="http://news.ycombinator.com/item?id=4454077" rel="nofollow">http://news.ycombinator.com/item?id=4454077</a>