12 ms·

Does everyone hate MongoDB?

393 points by dmytton 14y ago

gubatron 14y ago
hell no, it's been a breath of really fresh air for us, we've been building all sorts of things, no problems so far. (including logging several millions of requests per day and performing distributed map reduce for all sorts of statistical models on a tiny 3 machine "cluster" we run on AWS, I hope I never have to go back to modifying schemas again, so much simpler to run and build with this mindset)
- vyrotek 14y ago
  > I hope I never have to go back to modifying schemas again Honest question. Do you actually leverage the schemaless nature of MongoDB? Not 'worrying' about managing schemas is one thing, but actually leveraging the fact that your objects can have different fields is another. I have worked on projects that did need to store objects with different fields together but it seems to be a rare case. From what I've seen, most projects actually have pretty standard objects with specific fields. People just don't like feeling constrained but in the end I don't think managing a schema is difficult at all. I actually like the safety and performance you get when you put in the effort. I think the single most useful thing to see when starting a new dev job somewhere are the database schemas. If done properly, it will essentially tell you the story of that company and their data. You can think up questions and get answers such as "Is it possible for a Customer to have multiple Orders? Can a product have more than one Review?" (Stupid examples but they illustrate the kinds of relationships which are asked about all the time).
  - dmytton 14y ago
    Flexibility is useful in development. Once you deploy then things will change less frequently so the real benefit is when you do have to change something, you're not running a big ALTER statement.
    - vyrotek 14y ago
      In the enterprise world (at least in the Microsoft world) we have tools to manage these sorts of things. The one I'm currently using even for my small pet projects is called SQL Server Data Tools[1]. You basically just have to modify the original table creation scripts (add a column or whatever) and it actually generates all the change scripts for you. Even if the change is complex it handles making temp tables and transferring the data into the new table. It also notifies you and lets you handle cases where the change may lead to data loss. I guess my point is that the SQL world is still innovating but it doesn't get that much attention. Unless I have a specific use-case for storing similar entities together with different fields then a schemaless DB is not the right tool for the job. [1]http://msdn.microsoft.com/en-us/data/tools.aspx http://msdn.microsoft.com/en-us/data/tools.aspx
    - flatline3 14y ago
      > Once you deploy then things will change less frequently so the real benefit is when you do have to change something, you're not running a big ALTER statement. Instead, you're writing a bunch of code to deal with data that may be in the old format, or may be in the new format, or may be in the new-new format. I don't see that as an improvement.
      - prodigal_erik 14y ago
        In practice, you're writing code that has to deal with records that were updated by versions 3, 5, and 7 of your code but not 4 or 6. After a few years you can be sure somebody got it wrong at some point, and now you have records in a few out of the 2^n states where not even the developers can anticipate the system's behavior. The fix is to make ALTER incremental and less painful, not to stop writing down and checking your schema.
        jeltz 14y ago
        And both MySQL and PostgreSQL have put in work to make ALTER less painful by reducing the situations where a full table rewrite is necessary. In PostgreSQL you can both add and remove columns without the table being rewritten as long as you do not set a default value. You can also increase the lengths of varchars without any rewrite.
  - lmm 14y ago
    What I like is not the absence of a schema (because as you say there usually is one), but not having to fit it into the 2D SQL table model. An obvious case in when you have a many-to-one field that only ever contains a small number of values (e.g. a person's nationality); in a traditional SQL database my choices are make a separate table for it, or use a database-specific custom datatype (which never seem to be fully supported). In something like mongoDB I can just put a list in that field of the document.
colinhowe 14y ago
We've been using MongoDB in production for our main content store at Conversocial for over a year now. We've gone from 1.8 to 2.0 to 2.2 and we're happy. We have ~400gb of data, 220 million documents all on Amazon's SSD instances. We have definitely had our moments where we've screamed that we hate Mongo and are going to rip it out. That's normally where we've overlooked a detail of how it works... and we've had this same experience with every database technology we use - including MySQL and Redis. The day after, when we've cleared our heads... we're happy again. The same as the other technologies. I think that with all technologies you're going to get bitten by some detail you didn't know about or had forgotten. The trick is to mitigate these disasters by thinking about your failure cases.
- agscala 14y ago
  I wish you would write about some of these issues that you faced so we all can keep them in mind when using MongoDB in the future.
  - colinhowe 14y ago
    They're not particularly exciting. Example: we accidentally left detailed logging enabled on a secondary server and weren't monitoring the space left on the drive for logs. The disk got full and the secondary failed. Annoying that it failed but it was our fault for not monitoring that space and also leaving detailed logging on!
    - agscala 14y ago
      Well of course it's not exciting, but that's exactly the kind of examples I like hearing about because now I know I should always have detailed logging off. Anyways, I'm sure a lot of us would appreciate it if you wrote about your experiences, regardless of how mundane they are.
      - colinhowe 14y ago
        Sure! Will try to do it more often :) I don't often want to write about these things as they are silly mistakes... but, if it's helpful, I'll share!
ericcholis 14y ago
While I haven't gone full production with MongoDB yet, it has been a struggle to hear the signal through the noise. I'm glad that there are proponents of MongoDB like ServerDensity, it's nice to hear the other side of things from people who understand the issues. Out of all the issues mentioned, I'm particularly interested in a fix for uncompressed field names.
- josegonzalez 14y ago
  That is very trivial to do in your ORM if you so choose - and something like the Li3 PHP framework (lithium) would handle this quite nicely. To be honest, I'd rather have on-the-fly compression of data fields. At the moment I need to do this on my end, but it would be nice to be able to mark fields as compressible. Ah well.
  - ericcholis 14y ago
    Agreed, lithium user here :-)
danso 14y ago
> Comments: The 32 bit limit is noted (perhaps it should be a warning) on the download page but the main problem was the author did not know when writes started to fail. MongoDB uses unsafe writes by default in the sense that from the driver, you do not know if the write has succeeded without a further call to getLastError. This is because one of the often cited use cases for MongoDB is fast writes, which is achieved by fire and forget queries. (in reference to I’ll Give MongoDB Another Try. In Ten Years, http://diegobasch.com/ill-give-mongodb-another-try-in-ten-years http://diegobasch.com/ill-give-mongodb-another-try-in-ten-ye...) I read the referred article and the HN discussion...but wasn't quite able to tell how much of the debate was focused on the reasonability of this default rather than "developers should read the docs, or accept catastrophic failure" attitude (which is not inherently wrong). What immediately comes to mind is the Rails ActiveRecord update_attributes vulnerability...the default was to allow the updating of all specified attributes with the assumption that no competent developer would trust unsanitized input from the browser. After a good Samaritan performed a spectacular hack on Github, the Rails team immediately changed the default. Is that the situation here with the 32-bit silent fail default? That it is a sensible default, but could be changed if it's shown that competent devs will nonetheless screw it up?
- bunderbunder 14y ago
  Is that the situation here with the 32-bit silent fail default? That it is a sensible default, but could be changed if it's shown that competent devs will nonetheless screw it up? It's kind of sad that we'd need an example to show that it really could happen in every single specific case. It should be common knowledge by now that competent devs screw things up all the time. For example, I'm sure the MongoDB devs are extremely competent. But all the same, having a database management system default to letting writes fail silently is a pretty spectacular screw-up. I can't really blame other competent devs for taking it for granted that a DBMS wouldn't do something like that.
benatkin 14y ago
Does everyone hate MongoDB? - 25 Sept 2012 Headline Problem: Too many people are ranting about MongoDB. Mistake: Too few data points. Overly defensive of MongoDB. Comments: You should probably learn more about Riak. The "From MongoDB to Riak" is light on details but isn't really hand-waving. The author is saying that having a masterless database results in less fretting. http://wiki.basho.com/Riak-Compared-to-MongoDB.html http://wiki.basho.com/Riak-Compared-to-MongoDB.html Also, why two rage faces? Can't you get your point across without resorting to silly memes?
- deleted 14y ago
  [deleted]
- jchrisa 14y ago
  Now that Couchbase Server 2.0 is beta, it's a reliable alternative to MongoDB. Same JSON goodness, different set of user stories. (hint: less rants). Get the beta download here: http://www.couchbase.com/couchbase-server/beta http://www.couchbase.com/couchbase-server/beta
  - pooriaazimi 14y ago
    If you (like me) don't know what's the difference between CouchDB and CouchBase, look here: http://www.couchbase.com/couchdb http://www.couchbase.com/couchdb
  - druiid 14y ago
    We're running 1.8.x to great success. Currently pondering if we want to test with 2.0 or just wait to start testing until 2.0 final is released.
  - driverdan 14y ago
    Could you at least put a disclaimer in your spam that says you're a cofounder of Couchbase?
thibaut_barrere 14y ago
I don't hate MongoDB: I use it on scenarios where it is useful (eg: forms apps collecting semi-structured data, ETL apps pushing/transforming data to achieve geo-near queries etc). For a regular web-app with less exotic needs, my store of choice is PostgreSQL these days. And next time I have to handle large scale data, I will probably use Riak.
antonpug 14y ago
Bottom line...I DO NOT like the OO approach Mongo takes. I am in love with POS (Plain Old SQL)
thedz 14y ago
heh, I thought the domain sounded familiar: http://blog.serverdensity.com/removing-memcached-because-its-too-slow/ http://blog.serverdensity.com/removing-memcached-because-its...
mathnode 14y ago
MongoDB powers my latex doc database, and the CMS my team and I use. It's awesome. I have an event logger, that logs "interesting" MySQL server events to a tab separated file and then out to a central mongodb database. So I can query several servers results at once.
calinet6 14y ago
This is a nice summary of many of the problems with MongoDB, and a good set of fumbled excuses as to why they might not actually be problems. Most of the answers boil down to "Well, yeah, but if you know how to [long complicated solution here], then it's not a problem," while simultaneously admitting that the problem is present and that the solution (if it exists) is extremely difficult and requires specialized knowledge. All I can do is laugh and keep on using Postgres...
- einhverfr 14y ago
  Interestingly I just wrote an article on dzone (published in their NoSQL zone ;-) ) about building encapsulated data models on PostgreSQL. I discuss a bunch of ways of doing this. I totally agree with the idea that one should encapsulate data in application, but that's what an RDBMS is for if you know how to use it. My approaches to db interfaces have been greatly inspired by REST and SOAP. The thing is giving up on the RDBMS is usually the wrong choice. If using NoSQL, usually it is best as an adjunct to the traditional RDBMS (particularly for pre- and post- processing).
jandrewrogers 14y ago
I think a lot of the "hating" is a side effect of MongoDB being consistently oversold in terms of its capabilities and architecture. Many people who are not experts on databases discover this the hard way later. If the claims about it were qualified a little better and the limitations acknowledged more openly by its proponents it would help to mitigate this outcome. I am indifferent to MongoDB but I do caution people that the internals and implementation are quite primitive for a database engine. It is the sort of database engine that a programmer that knows little about database engines would build. Over the years that has repeatedly manifested as problems no one should ever expect a database engine to have if properly designed. There is a reasonable point where you should not have to read the documentation to see if your database has a basic design flaw; there is an assumption of competent architecture for its nominal use cases. MongoDB has improved in this regard over time and many other popular NoSQL (and SQL) databases have similar problems. Users are being asked to cut the database some slack for less than competent engineering choices but users just want a database to work. Being "simple" isn't enough.
- noodle 14y ago
  > I think a lot of the "hating" is a side effect of MongoDB being consistently oversold in terms of its capabilities and architecture. Agreed, though I think its also coupled with just a lack of understanding of what MongoDB does beyond just "its NoSQL!". So many people are used to working with RDBMS. They just seem to make incorrect assumptions about MongoDB based on what they thought were universal rules about databases. Mongo's a tool. Its not right for all situations and it definitely has some maturing to go still, but its good to use in certain situations, provided you're properly informed about it.
- skyebook 14y ago
  Totally agree. I would only add a lack of thinking on the part of developers who jump on the NoSQL bandwagon for the buzzword without understanding the implications of not having a relational database. I'm not a RoR fan but the ActiveRecord model is probably enough for 75% of people to get their projects started without having to dig too much.
- diego 14y ago
illumen 14y ago
You mean the mug, the tshirt or the database? The mug, and tshirt have been quite good. Haven't tried the db.
- benatkin 14y ago
  You raise a valid point. If this essay by pg holds true, you might be better off sticking to PostgreSQL (the other pg): http://paulgraham.com/javacover.html http://paulgraham.com/javacover.html
  - z92 14y ago
    Just finished reading it for first time. Clearly pg was wrong. It now reads like one of those classic wrong predictions.
manishsharan 14y ago
I love that MongoDb allows me to get stuff done without much fuss even when I have not figured out the final data requirements. I have been using RDBMS + ORM ( Hibernate) for a very long time; however I found this to be very "rigid" in a start up environment where the requirements are far from frozen. MongoDB is much more flexible and forgiving than traditional RDBMS in that respect.
- freework 14y ago
  If you haven't figured out the final data requirements, then you have work to do. Its a corollary of the "give me your data structures and I'll understand your program, give me just your code and I'll still be clueless" mantra. The Database should have a strict schema before code is written. Having a schemaless datastore is only flexible in the sense that it lets ou shoot yourself int eh foot easily.
LarryMade 14y ago
I think it looks promising - it's not a panacea, there are things SQL works better for and there are things I can see Mongodb would really rock with. With anything there are gotchas so you have to live and learn with em. When I was researching Mongodb before going into it I saw forums talking about the 2gb limit on 32 bit systems; I would say the author of that article didn't see the posting - which could either be a case of not due diligence on the ins and out of the system or lack of diligence on the reference material he had originally been using to build his system.
linuxhansl 14y ago
Let's not conflate "hating" (which is always pointless) with pointing out flaws in a design. "Mongo sucks f*cking balls" is hating it. "Mongo silently does not store data in some situations" is pointing out a flaw. It is easy to dismiss valid criticism as hate. It is also unfortunately true that some topics degenerate to flamewars on HN. Why Mongo is such catalyst is a phenomenon in itself. One that I find fascinating.
firefox 14y ago
They don't all hate MongoDB, they're just singling themselves out as people we shouldn't work with. Ranting about a product without knowing much about it or even reading the documentation simply points out what type of engineer you wouldn't want to deal with.
Zak 14y ago
My problems were to do with data-loss and unrecoverable corruption. I didn't write a blog-rant, but maybe I should have. I have since learned that I could have changed some configuration options to make MongoDB less likely to corrupt and/or lose data. I'm still wary though - the fact that the default configuration was prone to unrecoverable data loss suggests that any time I use MongoDB, I must carefully research the feature I'm using to make sure I don't do it in a way that causes data loss. I believe dangerous configurations should never be the default, and dangerous features should be clearly labeled. The default method for writing data should not fail silently, for example. The fast, fire-and-forget write should be called something like "unchecked_write".
- pjungwir 14y ago
  It's not just that the defaults are dangerous, but that if you change the default, you give up much of the performance benefit of choosing Mongo in the first place.
  - gaius 14y ago
    If you don't care whether a write succeeds or not then you can get even more performance by not making the call to the DB in the first place!
  - taligent 14y ago
    Sorry but NOBODY is choosing MongoDB purely based on speed. If they were they would go with something like MemSQL, Redis etc.
    - rdtsc 14y ago
      They did it more when it first came around. Redis wasn't in the same category. It was usually compared to CouchDB, another one I don't remember, and then traditional SQL DBs. Couch for example looked much worse in benchmarks because it tried a bit harder to take care of users' data and didn't just fling it over the fence. But it mostly lost out because OMG benchmarks!
- 14y ago
halfwit 14y ago
Headline problem: Deployed on 32 bit server so was limited to 2GB database. Writes were being silently discarded. Mistake: Deployed to 32 bit servers without knowledge of the limit. Did not use safe writes and didn’t check for errors after writes. Sorry, I just do not see eye-to-eye with anyone who thinks this problem was the mistake of the user. This attitude, though detestable, is prevalent in our industry, and it's wrong. The database was silently throwing away writes. I don't know what else to say. I mean, I'm sure that MongoDB is really great for some people, and that it's doing a really awesome job storing their data. That is, until one day their writes start silently failing, because they neglected to check a priori every instance in which Mongo would silently fail. Which would make it their fault, naturally. I'd rather not find myself in that situation, but different strokes I guess.
aliks 14y ago
Reasons why i hate Mongodb: site:jira.mongodb.org/browse/ planned but not scheduled
Nux 14y ago
Yes.
davidw 14y ago
I had to use it a few years back, for some data reporting that had been added to a project after the fact, and... I found it to be awful, because the task was very much a join-heavy operation. Something that would have been a breeze with Postgres, or even Mysql got turned into this big, ugly, heavy, slow process. I was not impressed, especially since the quantity of data in the DB was also something that could have very, very easily been handled by a very conventional relational DB running on a VPS, to say nothing of dedicated hardware. Basically, they had chosen MongoDB due to the 'cool/new' factor, and it came back to bite them on the ass.
- einhverfr 14y ago
  >" I found it to be awful, because the task was very much a join-heavy operation. Something that would have been a breeze with Postgres, or even Mysql got turned into this big, ugly, heavy, slow process. " If you can't be assured of structure of data input, you can't reliably and gracefully transform that data on output. That's a pretty fundamental tradeoff between SQL and NoSQL (and historically between PostgreSQL and MySQL too).
jeffdavis 14y ago
"Many suggest this default is a good way to get favourable benchmarks but there are no official ones so I don’t think that’s relevant." Sure it is. People download MongoDB, run some simple workload against it, and see how fast it is. It's not an official benchmark, but it's still a strong part of the marketing message. So, if those people don't understand the significance of sync/async, they may be getting a false impression of the speed.
Uchikoma 14y ago
No I like it if you know it's limits. Schema free supports agile development much better than e.g. MySQL. Compared to key/value stores it's easier if you need to query data (and don't have Twitter scale amounts of it)
tmo9d 14y ago
I wouldn't say I hate it, but I took MongoDB into production two years ago only to have it be a consistent source of problems for me. We integrated it to offload some activity from MySQL, it did a great job for a while, but it's a constant chore to maintain.
spartango 14y ago
I really appreciated this post for its thoughtful quality. It provided a bunch of "in our experience" analysis of situations that others presented, noting both the mistakes of users and Mongo itself, without playing the blame game. The presentation of mitigation strategies for both sources of issues was actually constructive for potential and current users of Mongo. As with any tool, Mongo is useful in some scenarios but not without its drawbacks. It's nice to have a point-by-point assessment of pain points. Falling into the potential user category, I've opted not to use MongoDB for my current project because the particular benefits don't align nicely with my problem, but it was useful to see this and know a bit of what to expect with Mongo, good and bad.
bcoates 14y ago
This article isn't exactly inspring me to give MongoDB a shot. I wasn't even aware Map-Reduce in MongoDB was single-threaded, doesn't that defeat the entire purpose? Isn't Map-Reduce an embarrassingly parallel algorithm? If they're using a single-thread JS engine, can't they just multiprocess? No shared state, after all...
jeffdavis 14y ago
"Getting your working set in memory is one of the most difficult things to calculate and plan for with MongoDB." I am a little bothered when I see a working set described as though it was a property of the user or workload. A large part of database research has gone into allowing the user or the system to make the working set smaller. An obvious example is an index, which makes the working set smaller if you don't mind a random I/O or two per lookup (of course, that only works for indexable queries). There are also many operations in a database which try to work within a limited amount of memory, and therefore must have a small working set regardless of the data size. Sort and HashJoin are two examples. HashJoin doesn't tell you what the working set of your data is, you tell it and it works as efficiently as it can in that amount of memory. And you can design your data layout to have a smaller working set (again, so long as you allow a few disk accesses outside the working set). Normalization and vertical partitioning (i.e. splitting a table up into several tables with fewer columns each) can help here. So, the "working set" isn't some passive constant that can't be managed.
- marshray 14y ago
  Isn't one of the defining characteristics of Mongo-like systems that they tend to aggressively favor using RAM to achieve performance? I.e., their strategy is to complete each query as quickly as possible rather than attempt to optimize for fairness of long-running transactions.
  - jeffdavis 14y ago
    I wasn't referring only to long running transactions. Indexes are clearly a way of reducing the working set (at least in a practical sense) but also vital for workloads with many short transactions. I was not criticizing mongo per se, I was criticizing this post and other misguided statements about the working set as it relates to database software.
    - marshray 14y ago
      OK, it just seemed to me that the stated goal of Mongo-like servers was to take some of our accepted notions of the "working set as it relates to database software" and put them up for fresh discussion.
mark_l_watson 14y ago
I am a huge fan of MongoDB and have been using it for years. That said, my default data store is PostgreSQL. I have to have a good reason for choosing to not use PostgreSQL. I especially like MongoDB for data analytics: really handy for storing data and then doing experimental data mining. Putting a read replica on each server that does analytics/data mining works especially well (very good performance when MongoDB's indices fit in memory and the read mongo is on localhost to programs doing analytics).
pbharrin 14y ago
YES!!!! We stopped using it in production and moved to Solr. I don't hate MongoDB but I think it is overhyped. The fact that 10gen raised 42m is crazy. I would be surprised if those investors got any return greater than the money they invested.
jeffdavis 14y ago
It's not about "hating", or at least I hope it's not. NoSQL, in many ways with MongoDB leading the charge, came on to the scene very quickly with a lot of support on HN. When action outpaces education, then it's natural to expect education to play catch-up for a while, which is what's happening now. Some of it is education by 10gen, some by users who made mistakes (the leading cause of education), and some by traditional database people who want to highlight the lessons learned that might have been missed by 10gen or mongo users. Generalizing all of this as "hate" is not productive.
netvarun 14y ago
You beat me into writing this =) Great article, btw! It seems to me that there are three camps of people when it comes to dbs - (1) The "I hate anything new" camp, (2) The "I hate anything old" camp, and finally (3) The "I will pick the best tool suited to my needs" Those from camp (1) are the ones who hate anything that IS NOT relational or sql. The mongodb bashers would fall in this camp. Those from camp (2) are those who hate that IS relational or sql. The "web-scale" people would flal in this camp. Those from camp (3) are the silent majority who do their independent research, pick the right type of DB for their job, and live life happily. For my startup (Semantics3), we deal primarily with JSON strings (which have no fixed structure). We use MongoDB because a really good use case for it is to just store JSON documents with a unique id. We only run simple queries on it - basically existential (does an id exist) or count. We are aware that it's query performance is not as fast as that of a relational db. So we then index that data to ElasticSearch and run our advanced queries through that. We are really happy with our current system and it has been working great. If we had some sort of "relational" data with a fixed structure I sure has hell would have picked MySQL or PostgreSQL and used Sphinx on it for indexing. Peace.
- netvarun 14y ago
  Hmm, why the downvotes?
chaostheory 14y ago
> The way MongoDB yielded was improved in 2.0 in a very significant way and this was taken further in 2.2 with the complete removal of the global lock as a step towards more granular concurrency. Yes with 2.2, write locks have improved drastically. However, I'm still waiting until you can get to the point of not having to lock down whole collections (the near equivalent to a table - with caveats) as opposed to a document within the collection (the closest thing that you can call a record in db terms - with tons of caveats). This being said, Mongodb does have really really awesome documentation and it is the right way to go for many applications and developers.
oracuk 14y ago
I've used mongodb for a recent prototype. It was brilliant, I iterated through the data model as I coded. However, I am now very aware that I have an implicit schema in my code that will be harder to understand in 6 months than a database schema. I traded fantastic flexibility in initial development against easily maintained longevity. I suspect I will move to something more relational but have also taken on the need to really understand the trade-offs I'm making. I've started reading Seven Databases in Seven Weeks to fill in some of my gaps.
- einhverfr 14y ago
  I traded fantastic flexibility in initial development against easily maintained longevity. Great quote, btw, and spot on.
Lazare 14y ago
MongoDB is really easy to get started with. It's easy to install on a VM, and it's easy to try it out on Heroku. There's drivers for a bunch of languages, and its API works in a way that fits well with the way programmers already think. It dispenses with pretty much everything that makes getting started with a new database hard (schemas, new syntax, unfamiliar concepts, needing to edit server configs). MongoDB "just works" out of the box for testing and development. It's practically the perfect database for any testing and development work. And their marketing documentation tells you that it'll just work in production and will scale really well. That makes a lot of people try MongoDB, and they're mostly very happy with it. ...the problems arise later. Because while MongoDB lives up to the hype for testing and development, it doesn't completely live up to the hype for production uses. It doesn't always scale that well. It isn't always as durable as you might hope. Performance isn't always very good. For some use cases, the default settings aren't appropriate; for other use cases the database design itself isn't appropriate. Backups and replication aren't quite as easy as you'd hope. In short, the problem comes because MongoDB is as good or better than, say, Postgres or Riak during development in basically every way, but it's only better than Postgres or Riak in a few specialized ways during production. Example: Riak basically won't work at all in a multi-tenant setup. Two competing services will provide you with a free development MongoDB instance on Heroku, but nothing of the kind exists for Riak; you basically need to roll your own cluster. That makes MongoDB really easy for someone thinking "hey, I wonder if Mongo would work for this proof of concept I'm working on" (hint: it will). Of course, MongoDB replication and scaling is honestly mediocre, while Riak's is basically magic. This makes Riak a better choice for someone who needs to scale a cluster of database servers - but you only find out that sort of thing first-hand during production. At which point, you make an angry blog post that hits Hacker News. And while plenty of people never run into MongoDBs weak areas, they never post anything that hits the Hacker News frontpage. :) TL;DR: A lot of people hate MongoDB because it's amazingly easy to get started with, but harder later on, and they then feel betrayed. Other databases have smoother learning curves.
fleitz 14y ago
MongoDB is kind of like assembler, if you read processor errata sheets for fun you can make some really fast websites. Get that OS, and everything out of the way, just you and the network card. However, if you just want to write a web app that doesn't lose data it's a really crappy idea and should probably use something creating for solving that problem, like a compiler and web framework.
rdtsc 14y ago
Does everyone hate infomercial salesmen that sell crap at 4am in the morning on TV? I don't know. Some do some don't. Those that see through the lies are probably laughing at them, those that already bought the product and found out it is useless and doesn't live up to touted capabilities probably hate them. Now don't get me wrong. In a practical way (disregarding ethical consideration) they took a risk. They quickly gained a lot of customers because their benchmarks looked very good. So in a certain way people probably already forgot about the competitors at that time, because those competitors never made it so far. Now MongoDB is here years later and stories of hidden data corruption (and this is one of worst thing that could happen to a database) have started to emerge. Yes, by this time Mongo has the mind-share but now it is time to also pay the price for their design choice. They are probably still ahead.
programminggeek 14y ago
I'll say this. I like MongoDB, but I've never built anything at big scale with it. For a small project, it's much less hassle to get rolling on than MySQL, so it's cool for that.
kaiwen1 14y ago
I'm not sure I "hate" it. But every project I've used MongoDB on that grew the least bit of data complexity left me wishing for (and often converting to) Postgres. I'll still like MongoDB if I'm doing something very simple or rapid prototyping, etc. But for real work, forget it.
nwmcsween 14y ago
No it's a tool, do I dislike a hammer because it can't turn screws?
frederico 14y ago
Outstanding article. Well overdue for the Mongo community. There are always the haters whom find themselves ignoring documents then complaining about how things are setup. Thank you for going back through mongo articles to iterate the key failures to understanding points.
edwardcapriolo 14y ago
It is easy to criticize the things closest to you.

393 points by dmytton 14y ago

hell no, it's been a breath of really fresh air for us, we've been building all sorts of things, no problems so far. (including logging several millions of requests per day and performing distributed map reduce for all sorts of statistical models on a tiny 3 machine "cluster" we run on AWS, I hope I never have to go back to modifying schemas again, so much simpler to run and build with this mindset)

vyrotek 14y ago
> I hope I never have to go back to modifying schemas again Honest question. Do you actually leverage the schemaless nature of MongoDB? Not 'worrying' about managing schemas is one thing, but actually leveraging the fact that your objects can have different fields is another. I have worked on projects that did need to store objects with different fields together but it seems to be a rare case. From what I've seen, most projects actually have pretty standard objects with specific fields. People just don't like feeling constrained but in the end I don't think managing a schema is difficult at all. I actually like the safety and performance you get when you put in the effort. I think the single most useful thing to see when starting a new dev job somewhere are the database schemas. If done properly, it will essentially tell you the story of that company and their data. You can think up questions and get answers such as "Is it possible for a Customer to have multiple Orders? Can a product have more than one Review?" (Stupid examples but they illustrate the kinds of relationships which are asked about all the time).
- dmytton 14y ago
  Flexibility is useful in development. Once you deploy then things will change less frequently so the real benefit is when you do have to change something, you're not running a big ALTER statement.
  - vyrotek 14y ago
    In the enterprise world (at least in the Microsoft world) we have tools to manage these sorts of things. The one I'm currently using even for my small pet projects is called SQL Server Data Tools[1]. You basically just have to modify the original table creation scripts (add a column or whatever) and it actually generates all the change scripts for you. Even if the change is complex it handles making temp tables and transferring the data into the new table. It also notifies you and lets you handle cases where the change may lead to data loss. I guess my point is that the SQL world is still innovating but it doesn't get that much attention. Unless I have a specific use-case for storing similar entities together with different fields then a schemaless DB is not the right tool for the job. [1]http://msdn.microsoft.com/en-us/data/tools.aspx http://msdn.microsoft.com/en-us/data/tools.aspx
  - flatline3 14y ago
    > Once you deploy then things will change less frequently so the real benefit is when you do have to change something, you're not running a big ALTER statement. Instead, you're writing a bunch of code to deal with data that may be in the old format, or may be in the new format, or may be in the new-new format. I don't see that as an improvement.
    - prodigal_erik 14y ago
      In practice, you're writing code that has to deal with records that were updated by versions 3, 5, and 7 of your code but not 4 or 6. After a few years you can be sure somebody got it wrong at some point, and now you have records in a few out of the 2^n states where not even the developers can anticipate the system's behavior. The fix is to make ALTER incremental and less painful, not to stop writing down and checking your schema.
      - jeltz 14y ago
        And both MySQL and PostgreSQL have put in work to make ALTER less painful by reducing the situations where a full table rewrite is necessary. In PostgreSQL you can both add and remove columns without the table being rewritten as long as you do not set a default value. You can also increase the lengths of varchars without any rewrite.
- lmm 14y ago
  What I like is not the absence of a schema (because as you say there usually is one), but not having to fit it into the 2D SQL table model. An obvious case in when you have a many-to-one field that only ever contains a small number of values (e.g. a person's nationality); in a traditional SQL database my choices are make a separate table for it, or use a database-specific custom datatype (which never seem to be fully supported). In something like mongoDB I can just put a list in that field of the document.

colinhowe 14y ago

We've been using MongoDB in production for our main content store at Conversocial for over a year now. We've gone from 1.8 to 2.0 to 2.2 and we're happy. We have ~400gb of data, 220 million documents all on Amazon's SSD instances. We have definitely had our moments where we've screamed that we hate Mongo and are going to rip it out. That's normally where we've overlooked a detail of how it works... and we've had this same experience with every database technology we use - including MySQL and Redis. The day after, when we've cleared our heads... we're happy again. The same as the other technologies. I think that with all technologies you're going to get bitten by some detail you didn't know about or had forgotten. The trick is to mitigate these disasters by thinking about your failure cases.

agscala 14y ago
I wish you would write about some of these issues that you faced so we all can keep them in mind when using MongoDB in the future.
- colinhowe 14y ago
  They're not particularly exciting. Example: we accidentally left detailed logging enabled on a secondary server and weren't monitoring the space left on the drive for logs. The disk got full and the secondary failed. Annoying that it failed but it was our fault for not monitoring that space and also leaving detailed logging on!
  - agscala 14y ago
    Well of course it's not exciting, but that's exactly the kind of examples I like hearing about because now I know I should always have detailed logging off. Anyways, I'm sure a lot of us would appreciate it if you wrote about your experiences, regardless of how mundane they are.
    - colinhowe 14y ago
      Sure! Will try to do it more often :) I don't often want to write about these things as they are silly mistakes... but, if it's helpful, I'll share!

ericcholis 14y ago

While I haven't gone full production with MongoDB yet, it has been a struggle to hear the signal through the noise. I'm glad that there are proponents of MongoDB like ServerDensity, it's nice to hear the other side of things from people who understand the issues. Out of all the issues mentioned, I'm particularly interested in a fix for uncompressed field names.

josegonzalez 14y ago
That is very trivial to do in your ORM if you so choose - and something like the Li3 PHP framework (lithium) would handle this quite nicely. To be honest, I'd rather have on-the-fly compression of data fields. At the moment I need to do this on my end, but it would be nice to be able to mark fields as compressible. Ah well.
- ericcholis 14y ago
  Agreed, lithium user here :-)

danso 14y ago

> Comments: The 32 bit limit is noted (perhaps it should be a warning) on the download page but the main problem was the author did not know when writes started to fail. MongoDB uses unsafe writes by default in the sense that from the driver, you do not know if the write has succeeded without a further call to getLastError. This is because one of the often cited use cases for MongoDB is fast writes, which is achieved by fire and forget queries. (in reference to I’ll Give MongoDB Another Try. In Ten Years, http://diegobasch.com/ill-give-mongodb-another-try-in-ten-years http://diegobasch.com/ill-give-mongodb-another-try-in-ten-ye...) I read the referred article and the HN discussion...but wasn't quite able to tell how much of the debate was focused on the reasonability of this default rather than "developers should read the docs, or accept catastrophic failure" attitude (which is not inherently wrong). What immediately comes to mind is the Rails ActiveRecord update_attributes vulnerability...the default was to allow the updating of all specified attributes with the assumption that no competent developer would trust unsanitized input from the browser. After a good Samaritan performed a spectacular hack on Github, the Rails team immediately changed the default. Is that the situation here with the 32-bit silent fail default? That it is a sensible default, but could be changed if it's shown that competent devs will nonetheless screw it up?

bunderbunder 14y ago
Is that the situation here with the 32-bit silent fail default? That it is a sensible default, but could be changed if it's shown that competent devs will nonetheless screw it up? It's kind of sad that we'd need an example to show that it really could happen in every single specific case. It should be common knowledge by now that competent devs screw things up all the time. For example, I'm sure the MongoDB devs are extremely competent. But all the same, having a database management system default to letting writes fail silently is a pretty spectacular screw-up. I can't really blame other competent devs for taking it for granted that a DBMS wouldn't do something like that.

benatkin 14y ago

Does everyone hate MongoDB? - 25 Sept 2012 Headline Problem: Too many people are ranting about MongoDB. Mistake: Too few data points. Overly defensive of MongoDB. Comments: You should probably learn more about Riak. The "From MongoDB to Riak" is light on details but isn't really hand-waving. The author is saying that having a masterless database results in less fretting. http://wiki.basho.com/Riak-Compared-to-MongoDB.html http://wiki.basho.com/Riak-Compared-to-MongoDB.html Also, why two rage faces? Can't you get your point across without resorting to silly memes?

deleted 14y ago
[deleted]
jchrisa 14y ago
Now that Couchbase Server 2.0 is beta, it's a reliable alternative to MongoDB. Same JSON goodness, different set of user stories. (hint: less rants). Get the beta download here: http://www.couchbase.com/couchbase-server/beta http://www.couchbase.com/couchbase-server/beta
- pooriaazimi 14y ago
  If you (like me) don't know what's the difference between CouchDB and CouchBase, look here: http://www.couchbase.com/couchdb http://www.couchbase.com/couchdb
- druiid 14y ago
  We're running 1.8.x to great success. Currently pondering if we want to test with 2.0 or just wait to start testing until 2.0 final is released.
- driverdan 14y ago
  Could you at least put a disclaimer in your spam that says you're a cofounder of Couchbase?

thibaut_barrere 14y ago

I don't hate MongoDB: I use it on scenarios where it is useful (eg: forms apps collecting semi-structured data, ETL apps pushing/transforming data to achieve geo-near queries etc). For a regular web-app with less exotic needs, my store of choice is PostgreSQL these days. And next time I have to handle large scale data, I will probably use Riak.

antonpug 14y ago

Bottom line...I DO NOT like the OO approach Mongo takes. I am in love with POS (Plain Old SQL)

thedz 14y ago

heh, I thought the domain sounded familiar: http://blog.serverdensity.com/removing-memcached-because-its-too-slow/ http://blog.serverdensity.com/removing-memcached-because-its...

mathnode 14y ago

MongoDB powers my latex doc database, and the CMS my team and I use. It's awesome. I have an event logger, that logs "interesting" MySQL server events to a tab separated file and then out to a central mongodb database. So I can query several servers results at once.

calinet6 14y ago

This is a nice summary of many of the problems with MongoDB, and a good set of fumbled excuses as to why they might not actually be problems. Most of the answers boil down to "Well, yeah, but if you know how to [long complicated solution here], then it's not a problem," while simultaneously admitting that the problem is present and that the solution (if it exists) is extremely difficult and requires specialized knowledge. All I can do is laugh and keep on using Postgres...

einhverfr 14y ago
Interestingly I just wrote an article on dzone (published in their NoSQL zone ;-) ) about building encapsulated data models on PostgreSQL. I discuss a bunch of ways of doing this. I totally agree with the idea that one should encapsulate data in application, but that's what an RDBMS is for if you know how to use it. My approaches to db interfaces have been greatly inspired by REST and SOAP. The thing is giving up on the RDBMS is usually the wrong choice. If using NoSQL, usually it is best as an adjunct to the traditional RDBMS (particularly for pre- and post- processing).

jandrewrogers 14y ago

I think a lot of the "hating" is a side effect of MongoDB being consistently oversold in terms of its capabilities and architecture. Many people who are not experts on databases discover this the hard way later. If the claims about it were qualified a little better and the limitations acknowledged more openly by its proponents it would help to mitigate this outcome. I am indifferent to MongoDB but I do caution people that the internals and implementation are quite primitive for a database engine. It is the sort of database engine that a programmer that knows little about database engines would build. Over the years that has repeatedly manifested as problems no one should ever expect a database engine to have if properly designed. There is a reasonable point where you should not have to read the documentation to see if your database has a basic design flaw; there is an assumption of competent architecture for its nominal use cases. MongoDB has improved in this regard over time and many other popular NoSQL (and SQL) databases have similar problems. Users are being asked to cut the database some slack for less than competent engineering choices but users just want a database to work. Being "simple" isn't enough.

noodle 14y ago
> I think a lot of the "hating" is a side effect of MongoDB being consistently oversold in terms of its capabilities and architecture. Agreed, though I think its also coupled with just a lack of understanding of what MongoDB does beyond just "its NoSQL!". So many people are used to working with RDBMS. They just seem to make incorrect assumptions about MongoDB based on what they thought were universal rules about databases. Mongo's a tool. Its not right for all situations and it definitely has some maturing to go still, but its good to use in certain situations, provided you're properly informed about it.
skyebook 14y ago
Totally agree. I would only add a lack of thinking on the part of developers who jump on the NoSQL bandwagon for the buzzword without understanding the implications of not having a relational database. I'm not a RoR fan but the ActiveRecord model is probably enough for 75% of people to get their projects started without having to dig too much.
diego 14y ago

illumen 14y ago

You mean the mug, the tshirt or the database? The mug, and tshirt have been quite good. Haven't tried the db.

benatkin 14y ago
You raise a valid point. If this essay by pg holds true, you might be better off sticking to PostgreSQL (the other pg): http://paulgraham.com/javacover.html http://paulgraham.com/javacover.html
- z92 14y ago
  Just finished reading it for first time. Clearly pg was wrong. It now reads like one of those classic wrong predictions.

manishsharan 14y ago

I love that MongoDb allows me to get stuff done without much fuss even when I have not figured out the final data requirements. I have been using RDBMS + ORM ( Hibernate) for a very long time; however I found this to be very "rigid" in a start up environment where the requirements are far from frozen. MongoDB is much more flexible and forgiving than traditional RDBMS in that respect.

freework 14y ago
If you haven't figured out the final data requirements, then you have work to do. Its a corollary of the "give me your data structures and I'll understand your program, give me just your code and I'll still be clueless" mantra. The Database should have a strict schema before code is written. Having a schemaless datastore is only flexible in the sense that it lets ou shoot yourself int eh foot easily.

LarryMade 14y ago

I think it looks promising - it's not a panacea, there are things SQL works better for and there are things I can see Mongodb would really rock with. With anything there are gotchas so you have to live and learn with em. When I was researching Mongodb before going into it I saw forums talking about the 2gb limit on 32 bit systems; I would say the author of that article didn't see the posting - which could either be a case of not due diligence on the ins and out of the system or lack of diligence on the reference material he had originally been using to build his system.

linuxhansl 14y ago

Let's not conflate "hating" (which is always pointless) with pointing out flaws in a design. "Mongo sucks f*cking balls" is hating it. "Mongo silently does not store data in some situations" is pointing out a flaw. It is easy to dismiss valid criticism as hate. It is also unfortunately true that some topics degenerate to flamewars on HN. Why Mongo is such catalyst is a phenomenon in itself. One that I find fascinating.

firefox 14y ago

They don't all hate MongoDB, they're just singling themselves out as people we shouldn't work with. Ranting about a product without knowing much about it or even reading the documentation simply points out what type of engineer you wouldn't want to deal with.

Zak 14y ago

My problems were to do with data-loss and unrecoverable corruption. I didn't write a blog-rant, but maybe I should have. I have since learned that I could have changed some configuration options to make MongoDB less likely to corrupt and/or lose data. I'm still wary though - the fact that the default configuration was prone to unrecoverable data loss suggests that any time I use MongoDB, I must carefully research the feature I'm using to make sure I don't do it in a way that causes data loss. I believe dangerous configurations should never be the default, and dangerous features should be clearly labeled. The default method for writing data should not fail silently, for example. The fast, fire-and-forget write should be called something like "unchecked_write".

pjungwir 14y ago
It's not just that the defaults are dangerous, but that if you change the default, you give up much of the performance benefit of choosing Mongo in the first place.
- gaius 14y ago
  If you don't care whether a write succeeds or not then you can get even more performance by not making the call to the DB in the first place!
- taligent 14y ago
  Sorry but NOBODY is choosing MongoDB purely based on speed. If they were they would go with something like MemSQL, Redis etc.
  - rdtsc 14y ago
    They did it more when it first came around. Redis wasn't in the same category. It was usually compared to CouchDB, another one I don't remember, and then traditional SQL DBs. Couch for example looked much worse in benchmarks because it tried a bit harder to take care of users' data and didn't just fling it over the fence. But it mostly lost out because OMG benchmarks!
14y ago

halfwit 14y ago

Headline problem: Deployed on 32 bit server so was limited to 2GB database. Writes were being silently discarded. Mistake: Deployed to 32 bit servers without knowledge of the limit. Did not use safe writes and didn’t check for errors after writes. Sorry, I just do not see eye-to-eye with anyone who thinks this problem was the mistake of the user. This attitude, though detestable, is prevalent in our industry, and it's wrong. The database was silently throwing away writes. I don't know what else to say. I mean, I'm sure that MongoDB is really great for some people, and that it's doing a really awesome job storing their data. That is, until one day their writes start silently failing, because they neglected to check a priori every instance in which Mongo would silently fail. Which would make it their fault, naturally. I'd rather not find myself in that situation, but different strokes I guess.

aliks 14y ago

Reasons why i hate Mongodb: site:jira.mongodb.org/browse/ planned but not scheduled

Nux 14y ago

Yes.

davidw 14y ago

I had to use it a few years back, for some data reporting that had been added to a project after the fact, and... I found it to be awful, because the task was very much a join-heavy operation. Something that would have been a breeze with Postgres, or even Mysql got turned into this big, ugly, heavy, slow process. I was not impressed, especially since the quantity of data in the DB was also something that could have very, very easily been handled by a very conventional relational DB running on a VPS, to say nothing of dedicated hardware. Basically, they had chosen MongoDB due to the 'cool/new' factor, and it came back to bite them on the ass.

einhverfr 14y ago
>" I found it to be awful, because the task was very much a join-heavy operation. Something that would have been a breeze with Postgres, or even Mysql got turned into this big, ugly, heavy, slow process. " If you can't be assured of structure of data input, you can't reliably and gracefully transform that data on output. That's a pretty fundamental tradeoff between SQL and NoSQL (and historically between PostgreSQL and MySQL too).

jeffdavis 14y ago

"Many suggest this default is a good way to get favourable benchmarks but there are no official ones so I don’t think that’s relevant." Sure it is. People download MongoDB, run some simple workload against it, and see how fast it is. It's not an official benchmark, but it's still a strong part of the marketing message. So, if those people don't understand the significance of sync/async, they may be getting a false impression of the speed.

Uchikoma 14y ago

No I like it if you know it's limits. Schema free supports agile development much better than e.g. MySQL. Compared to key/value stores it's easier if you need to query data (and don't have Twitter scale amounts of it)

tmo9d 14y ago

I wouldn't say I hate it, but I took MongoDB into production two years ago only to have it be a consistent source of problems for me. We integrated it to offload some activity from MySQL, it did a great job for a while, but it's a constant chore to maintain.

spartango 14y ago

I really appreciated this post for its thoughtful quality. It provided a bunch of "in our experience" analysis of situations that others presented, noting both the mistakes of users and Mongo itself, without playing the blame game. The presentation of mitigation strategies for both sources of issues was actually constructive for potential and current users of Mongo. As with any tool, Mongo is useful in some scenarios but not without its drawbacks. It's nice to have a point-by-point assessment of pain points. Falling into the potential user category, I've opted not to use MongoDB for my current project because the particular benefits don't align nicely with my problem, but it was useful to see this and know a bit of what to expect with Mongo, good and bad.

bcoates 14y ago

This article isn't exactly inspring me to give MongoDB a shot. I wasn't even aware Map-Reduce in MongoDB was single-threaded, doesn't that defeat the entire purpose? Isn't Map-Reduce an embarrassingly parallel algorithm? If they're using a single-thread JS engine, can't they just multiprocess? No shared state, after all...

jeffdavis 14y ago

"Getting your working set in memory is one of the most difficult things to calculate and plan for with MongoDB." I am a little bothered when I see a working set described as though it was a property of the user or workload. A large part of database research has gone into allowing the user or the system to make the working set smaller. An obvious example is an index, which makes the working set smaller if you don't mind a random I/O or two per lookup (of course, that only works for indexable queries). There are also many operations in a database which try to work within a limited amount of memory, and therefore must have a small working set regardless of the data size. Sort and HashJoin are two examples. HashJoin doesn't tell you what the working set of your data is, you tell it and it works as efficiently as it can in that amount of memory. And you can design your data layout to have a smaller working set (again, so long as you allow a few disk accesses outside the working set). Normalization and vertical partitioning (i.e. splitting a table up into several tables with fewer columns each) can help here. So, the "working set" isn't some passive constant that can't be managed.

marshray 14y ago
Isn't one of the defining characteristics of Mongo-like systems that they tend to aggressively favor using RAM to achieve performance? I.e., their strategy is to complete each query as quickly as possible rather than attempt to optimize for fairness of long-running transactions.
- jeffdavis 14y ago
  I wasn't referring only to long running transactions. Indexes are clearly a way of reducing the working set (at least in a practical sense) but also vital for workloads with many short transactions. I was not criticizing mongo per se, I was criticizing this post and other misguided statements about the working set as it relates to database software.
  - marshray 14y ago
    OK, it just seemed to me that the stated goal of Mongo-like servers was to take some of our accepted notions of the "working set as it relates to database software" and put them up for fresh discussion.

mark_l_watson 14y ago

I am a huge fan of MongoDB and have been using it for years. That said, my default data store is PostgreSQL. I have to have a good reason for choosing to not use PostgreSQL. I especially like MongoDB for data analytics: really handy for storing data and then doing experimental data mining. Putting a read replica on each server that does analytics/data mining works especially well (very good performance when MongoDB's indices fit in memory and the read mongo is on localhost to programs doing analytics).

pbharrin 14y ago

YES!!!! We stopped using it in production and moved to Solr. I don't hate MongoDB but I think it is overhyped. The fact that 10gen raised 42m is crazy. I would be surprised if those investors got any return greater than the money they invested.

jeffdavis 14y ago

It's not about "hating", or at least I hope it's not. NoSQL, in many ways with MongoDB leading the charge, came on to the scene very quickly with a lot of support on HN. When action outpaces education, then it's natural to expect education to play catch-up for a while, which is what's happening now. Some of it is education by 10gen, some by users who made mistakes (the leading cause of education), and some by traditional database people who want to highlight the lessons learned that might have been missed by 10gen or mongo users. Generalizing all of this as "hate" is not productive.

netvarun 14y ago

You beat me into writing this =) Great article, btw! It seems to me that there are three camps of people when it comes to dbs - (1) The "I hate anything new" camp, (2) The "I hate anything old" camp, and finally (3) The "I will pick the best tool suited to my needs" Those from camp (1) are the ones who hate anything that IS NOT relational or sql. The mongodb bashers would fall in this camp. Those from camp (2) are those who hate that IS relational or sql. The "web-scale" people would flal in this camp. Those from camp (3) are the silent majority who do their independent research, pick the right type of DB for their job, and live life happily. For my startup (Semantics3), we deal primarily with JSON strings (which have no fixed structure). We use MongoDB because a really good use case for it is to just store JSON documents with a unique id. We only run simple queries on it - basically existential (does an id exist) or count. We are aware that it's query performance is not as fast as that of a relational db. So we then index that data to ElasticSearch and run our advanced queries through that. We are really happy with our current system and it has been working great. If we had some sort of "relational" data with a fixed structure I sure has hell would have picked MySQL or PostgreSQL and used Sphinx on it for indexing. Peace.

netvarun 14y ago
Hmm, why the downvotes?

chaostheory 14y ago

> The way MongoDB yielded was improved in 2.0 in a very significant way and this was taken further in 2.2 with the complete removal of the global lock as a step towards more granular concurrency. Yes with 2.2, write locks have improved drastically. However, I'm still waiting until you can get to the point of not having to lock down whole collections (the near equivalent to a table - with caveats) as opposed to a document within the collection (the closest thing that you can call a record in db terms - with tons of caveats). This being said, Mongodb does have really really awesome documentation and it is the right way to go for many applications and developers.

oracuk 14y ago

I've used mongodb for a recent prototype. It was brilliant, I iterated through the data model as I coded. However, I am now very aware that I have an implicit schema in my code that will be harder to understand in 6 months than a database schema. I traded fantastic flexibility in initial development against easily maintained longevity. I suspect I will move to something more relational but have also taken on the need to really understand the trade-offs I'm making. I've started reading Seven Databases in Seven Weeks to fill in some of my gaps.

einhverfr 14y ago
I traded fantastic flexibility in initial development against easily maintained longevity. Great quote, btw, and spot on.

Lazare 14y ago

MongoDB is really easy to get started with. It's easy to install on a VM, and it's easy to try it out on Heroku. There's drivers for a bunch of languages, and its API works in a way that fits well with the way programmers already think. It dispenses with pretty much everything that makes getting started with a new database hard (schemas, new syntax, unfamiliar concepts, needing to edit server configs). MongoDB "just works" out of the box for testing and development. It's practically the perfect database for any testing and development work. And their marketing documentation tells you that it'll just work in production and will scale really well. That makes a lot of people try MongoDB, and they're mostly very happy with it. ...the problems arise later. Because while MongoDB lives up to the hype for testing and development, it doesn't completely live up to the hype for production uses. It doesn't always scale that well. It isn't always as durable as you might hope. Performance isn't always very good. For some use cases, the default settings aren't appropriate; for other use cases the database design itself isn't appropriate. Backups and replication aren't quite as easy as you'd hope. In short, the problem comes because MongoDB is as good or better than, say, Postgres or Riak during development in basically every way, but it's only better than Postgres or Riak in a few specialized ways during production. Example: Riak basically won't work at all in a multi-tenant setup. Two competing services will provide you with a free development MongoDB instance on Heroku, but nothing of the kind exists for Riak; you basically need to roll your own cluster. That makes MongoDB really easy for someone thinking "hey, I wonder if Mongo would work for this proof of concept I'm working on" (hint: it will). Of course, MongoDB replication and scaling is honestly mediocre, while Riak's is basically magic. This makes Riak a better choice for someone who needs to scale a cluster of database servers - but you only find out that sort of thing first-hand during production. At which point, you make an angry blog post that hits Hacker News. And while plenty of people never run into MongoDBs weak areas, they never post anything that hits the Hacker News frontpage. :) TL;DR: A lot of people hate MongoDB because it's amazingly easy to get started with, but harder later on, and they then feel betrayed. Other databases have smoother learning curves.

fleitz 14y ago

MongoDB is kind of like assembler, if you read processor errata sheets for fun you can make some really fast websites. Get that OS, and everything out of the way, just you and the network card. However, if you just want to write a web app that doesn't lose data it's a really crappy idea and should probably use something creating for solving that problem, like a compiler and web framework.

rdtsc 14y ago

Does everyone hate infomercial salesmen that sell crap at 4am in the morning on TV? I don't know. Some do some don't. Those that see through the lies are probably laughing at them, those that already bought the product and found out it is useless and doesn't live up to touted capabilities probably hate them. Now don't get me wrong. In a practical way (disregarding ethical consideration) they took a risk. They quickly gained a lot of customers because their benchmarks looked very good. So in a certain way people probably already forgot about the competitors at that time, because those competitors never made it so far. Now MongoDB is here years later and stories of hidden data corruption (and this is one of worst thing that could happen to a database) have started to emerge. Yes, by this time Mongo has the mind-share but now it is time to also pay the price for their design choice. They are probably still ahead.

programminggeek 14y ago

I'll say this. I like MongoDB, but I've never built anything at big scale with it. For a small project, it's much less hassle to get rolling on than MySQL, so it's cool for that.

kaiwen1 14y ago

I'm not sure I "hate" it. But every project I've used MongoDB on that grew the least bit of data complexity left me wishing for (and often converting to) Postgres. I'll still like MongoDB if I'm doing something very simple or rapid prototyping, etc. But for real work, forget it.

nwmcsween 14y ago

No it's a tool, do I dislike a hammer because it can't turn screws?

frederico 14y ago

Outstanding article. Well overdue for the Mongo community. There are always the haters whom find themselves ignoring documents then complaining about how things are setup. Thank you for going back through mongo articles to iterate the key failures to understanding points.

edwardcapriolo 14y ago

It is easy to criticize the things closest to you.