Notes from my MongoDB Research

For this series, I had conversations and read through a number of posts (blog posts and thousands of HN comments).

General Thoughts

Some general reflections from all my research:

  • The Right Tool for the Job (RTJ): Commenters rarely gave context into their use case and their own experience/position; without this information, it’s impossible to make a good technical choice – or understand how much weight to give to someone’s opinion
    • There can be many widely different database decision maker personas all with different considerations when making a good decision: hackathon developer, startup CTO, high volume data engineer (e.g.. IOT), Fortune 500 database decision maker, database administrator, general devops engineer, among many others
    • Some debates devolved into good vs bad, not the right tool for the job; better norms could reduce this (e.g., HN could have a more clear way to list out your background, commenters could consistently note their use case)
  • 10gen Marketing and Engineers: Some especially astutecomments noted that the anger about MongoDB on Hacker News was primarily about the fact that what was advertised wasn’t consistent with the reality
    • Wildly overpromising is common in marketing and sales, but often much derided in engineering circles
    • Given the success of 10gen’s strategy, I do wonder how much the typical engineering founder’s reluctance to do this negatively impacts their ability to get technology adopted
    • This question can also be posed to engineers: how comfortable would we be if in 10 years we’d have a powerful, stable, well accepted open source document database – but the cost was the short-term issues and lost productivity of a nascent MongoDB which had to be wildly oversold to get uptake and cross the chasm
  • Junior engineers and technical decision making:
    • For many dev tools companies, junior engineers are a powerful market to target as the current market may underserve them (e.g., usability) – and the product does not have to be rock solid compared to a large enterprise sale.
    • As such, it’s important for junior engineers to look at previous stories and have thoughtful engineers around them to reduce the likelihood of poor technical choices; part of the reason for bad choices is that software engineering is rarely taught in computer science programs – and because social media is an important input into technology choices early in your career
  • Timing Matters: Timing really matters when discussing the appropriateness of MongoDB; my story is set in 2012, before Postgres released JSONB support and when MongoDB still had some problematic defaults; Examples of key events that might influence your decision include:
    • Global lock removed
    • Acknowledged writes on by default
    • Postgres adds JSON support
    • Postgres adds JSONB support
    • MEAN stack training material provided
  • Personal Responsibility: There’s a big debate here about who’s responsible for a bad database decision. Should the marketer have been more careful? How responsible should be the programmer be when they willingly made a choice? And how does the answer change if you’ve just started coding – or are very early in your career?
  • Anonymity: A number of developers wrote anonymously; one noted that they were worried about getting a job in the industry if they used their real name for a negative critique, another alluded to the fact that it might look bad to comment on a failure at their company
    • This is a key reason why I don’t list companies other than those that have gone public with their reflections
    • The broader discussion suggests that there’s value to off the record real world discussions too.
    • While negativity may cause issues with some recruiters and companies, I’m personally of the belief that thoughtful critiques with a willingness to revisit your assumptions are much better than both blind hate – and blind excitement
  • Limited Conflict Disclosure: In our engineering discussions, we rarely discuss the conflicts that could influence the impartiality that we expect of great engineers and scientists
    • Some commenters could have been partisans on both sides (10gen employees/friends, 10gen competitors, a speaker at a 10gen conference, a MongoDB consultant) and there wasn’t consistent disclosure
    • Etsy, Foursquare, and Business Insider shared investors with 10gen and were friends with the 10gen team, which influenced their decision – not simply tech appropriateness; they all noted this, but I wonder if this message got lost for many readers – and it was not generally noted by 10gen marketers
    • at minimum, you have to dig into the incentives of anyone expressing a strong opinion in a comment, blog post, or speech – if you decide to use it to make a decision
  • Confidence and Competence: As noticed in some comments, we can get opinionated even when we don’t have the competence to thoughtfully opine on certain topics; there’s value to saying “I don’t know” and seeking out thoughtful engineers to discuss with
  • Blog carefully: Vendor employees should be careful about their blog posts/online comments, as they provide a wealth of information that may not reflect favorably on their organization or themselves
  • App Developers vs Ops: Part of the MongoDB debate was one contrasting the usability and productivity that app developers prize versus the potential downside risks that ops is responsible for; there’s not an easy answer, as I’ve seen people make mistakes on both extremes (some large company ops veterans will have mindsets that are inappropriate in early stage startups, while some app developers will overweight myopically short-term productivity).
  • ORM vs. SQL: We continue to have huge debates about ORMs versus raw SQL, which is one front in the broader usability discussion. This is partly a debate between those who know SQL well and benefit from optimized queries and others who value the usability of staying in one DSL. I wonder how much this debates echoes debates of yore (e.g., static vs dynamic)
  • Usability in dev tools: Increasingly, developers are valuing usability in their tools including things like easy setup, good documentation (design and content), well supported libraries, active and responsive mailing list

Select Comments

Here are excerpts from HN Comments and blog posts (by listing a comment it doesn’t mean that I agree, but that it has something to add to the discussion):

Right Tool for the Job and personal responsibility

Silhouette on Right Tool for the Job:

I embrace using the right tool for the job. Whether it’s new and shiny or old but tried-and-tested doesn’t really matter, though if I had to pick one or the other for some bizarre reason, I’d pick tried-and-tested eight days a week. There have been only a few truly significant advances in the past decade or two, but very many technologies that were initially much-hyped but then failed to stand the test of time for exactly the reasons that critics outside the hype bubble had always predicted. (link)

remon on the importance of noting your use case:

I made a little bet with myself when I saw the topic of this post that a good 80% or more of the top comments would be of the “Shouldn’t jump on the MongoDB/NoSQL bandwagon, nothing wrong with SQL” variety combined with various arguments to support that position or arguments against NoSQL in general or MongoDB specifically. I won.

Here’s the thing; anyone that claims one is superior over the other without adding a specific use case or context is doing something akin to religious preaching. Databases are tools. Pick the tool you need for the job. If you don’t understand exactly what a hammer is for and how it does what it does put effort into gaining that understanding. If after that research you think the tool has flaws that are important to you then don’t use it. (link)

antirez on testing systems for your intended use case:

3) New systems fails, especially if they are developed in the current NoSQL arena that is of course also full of interests about winning users ASAP (in other words to push new features fast is so important that perhaps sometimes stability will suffer). I can see this myself as even if my group at VMware is very focused on telling me to ship Redis as stable as possible as first rule, sometimes I get pressures about releasing new stuff ASAP from the user base itself.

IMHO it is a good idea if programmers learn to test very well the systems they are going to use with simulations for the intended use case. Never listen to the Hype, nor to detractors. (link)

kristina (10gen engineer) on use cases and filing issues:

Stories “like this” show that MongoDB doesn’t work for everyone, particularly people who give no specifics about their architecture, setup, what happened, or anything else. Isn’t it irritating how people will write, “MongoDB lost my data” or “CouchDB is really slow” and provide no specifics? (link)


Look, I don’t doubt that this guy really ran into problems. I just think they have a large data set with a heavy workload, they thought MongoDB was a silver bullet, and rather than being accountable for not doing proper testing, they want to try and burn 10gen. (link)


The bottom line: choose the right tool for the job and don’t bitch about the tools when you fail. (link)

New tech hype

jgrahamc on newtech koolaid and early career developers:

As a greying developer I am most amused by people discovering that ‘old’ technologies like SQL databases work really well.

The only useful piece of advice I can give a younger developer is… be careful when drinking the newtech koolaid. (link)


This is really what he’s driving at with the newtech koolaid. People jumped on MongoDB etc. bandwagon because they drank the koolaid of “Schema less is best!” and “It’s so fast and shiny!” without really understanding the problem, let alone the right solution.

Unfortunately this seems to be a regular pattern in tech, a mistake (mostly) repeated by the young fresh developers coming in. Usually after you get burned once or twice you stop making that mistake. (link)


There’s a sad inclination by developers to pick “one ring to rule them all” tools and MongoDB I believe even sells itself that way. It is not. (link)


> This is really what he’s driving at with the newtech koolaid. People jumped on MongoDB etc. bandwagon because they drank the koolaid of “Schema less is best!” and “It’s so fast and shiny!” without really understanding the problem, let alone the right solution.

Exactly. People report “X makes Y so easy!” and because of the breathy excited “look what I did in just an hour” blog posts the naive believe that using X for Y or similar things negates the need to properly design and think ahead.

If you take that approach then even if you are accidentally using the right tool doe the job, you may well be using it very wrongly and creating an unmaintainable and/or inefficient mess that you’ll have to fix later.

A few days coding can save you a good hour or three of design and thinking beforehand. (link)

Competing Databases


The hatred for MongoDB mostly comes from the PostgreSQL supporters camp. The rest of us are just using whatever tool makes sense. (link)


I remember during peak mongo that if you weren’t working on a project that used mongo, other devs looked down their noses at you. (link)

Benefits of NoSQL or MongoDB


Actually, I think that’s a great way to think about it: NoSQL is the “dynamic typing” of the database world.

Put another way, it’s like “what? you couldn’t spend 10 minutes declaring types everywhere?” – yeah, it’s less robust, yet dynamically typed languages remain popular. (link)


MongoDB may not be perfect, but like any tool, if you know its limitations it can be extremely useful, and it certainly is way more approachable for programmers who do not have the luxury of learning all the voodoo and lore that surrounds SQL-based relational DB’s. (link)


Here’s one:

You’re dealing with a torrent of incoming semi-unstructured data, where losing a good chunk of it is minor nuisance because you only need a decent sample, from which you extract data.

In those kind of scenarios, making it easy to work on the code can often be far more important than reliability.

I have a project like that now. I’d love to use Postgres, and probably will eventually once things “settle down” and we know what data we need to store. But or now MongoDB is the “quick and dirty” solution. We define a schema client side for everything we nail down, so as we nail down more aspects of what data to process, it gets easier to transition to a proper database.

As ORMs get better support for Postgres’ JSON capabilities, it will likely get less and less appealing to use MongoDB for stuff like this too. (link)


Schemaless is awesome. Are you dba or a developer? If you’re a developer like me schemaless is awesome because of it’s flexibility. I focus less time on the how to do stuff and more time on the what stuff should we do. (link)


I agree, I’ve read a few ‘screw Mongo, I’m going to SQL’ type blogs, it really seems like they either didn’t grasp how to architect Mongo correctly and tried to do things that don’t work well with it, or they had a problem that was better solved by SQL in the first place.

SQL does many things very well that noSQL stuff won’t. Also vice-versa. (link)


[It]’s important to understand what drove the adoption of NoSQL and schema-less stuff as well as the related trend of dynamic languages like Ruby and JavaScript.

(1) SQL server software itself was clunky, hard to scale, complex to deploy in a clustered fashion, and generally “old” in a bad way. This made NoSQL seem like a breath of fresh air.

(2) Startups! Ship now! MVP! Fail fast! The whole industry has been operating on this ship-fast-fail-fast way of doing things that prioritizes development speed and agility over correctness. That’s because half the time what you are developing will be thrown away anyway — it will fail, or you’ll “pivot” and rip it all apart and almost start over. No point in static languages, SQL schemas, or other explicit design elements in that world.

#2 is I think the more significant of the two for things like schema-less MongoDB or dynamic languages. Once you get product/market fit, you typically end up taking the crap you wrote with no types and schemas and re-doing it in a “real language” with a “real database.” But as they say in Startupistan, that’s a “good problem to have.” (link)


When you’re first working on a project, MongoDB is very easy to slap in. You don’t even have to create tables/collections. As you iterate, you don’t have to constantly be updating schemas as your product direction shifts. Thus, MongoDB is perfect for early startups.

As a company scales, of course it’s warts start to show. The very attributes (like schemaless storage) which were an asset when just a few developers were hacking on the project become a drawback as the company grows in size. Reliability becomes more of a concern.

Naturally, people shift to a more traditional database. Personally, I’m almost ready to switch some of our core functionality from MongoDB to Postgres. This isn’t an indictment of Mongo though. (link)


The successes tend to be quiet. And folks who are happy don’t take to the internet to defend their choices.

I’ve been on two straight projects where Mongo has been fine, no better or worse than an SQL database, but certainly nowhere as bad as one would assume reading all the negativity around here. I have experience with it being stable in two different contexts in production (social games, a very common use case, being one). A search for “social games mongo” should show you some success stories. (link)


If you’re doing a “tracer bullet”-style method of development where the requirements aren’t quite set in stone, MongoDB and other schemaless databases can really save time when it comes to adding basic functionality quickly.

Another use case: if you have an ad-hoc group of developers working on a project in a decentralized fashion, they can each work on local codebases of the project without needing an up-to-date setup script or migration scripts.

I’d maybe even argue that a lot of these “goodbye MongoDB” developer blog posts are sort of unnecessary. MongoDB allows for fast deployment and the convenience of a flexible database at the cost of speed, so eventual migration to a more solid relational database could/should be part of a long-term plan when devs choose to use MongoDB. It’s all about using the right tool for the job. (link)


It’s useful for prototyping. When you don’t know which schema you’ll end up using having an *SQL database is tedious because you have to do migrations every time you change the schema. Once you’re done prototyping you can switch to a better alternative. (link)

The Downsides of NoSQL


Whenever I see someone shoehorning something into MongoDB or something else I ask the reasoning for not using a relational database. Its always something along the lines of “We don’t do that now” or “schemaless” (which as the article points out means more work for the dev) something similar, with the “fast” added somewhere into the description.

The crazy thing is most of them are working on a single node, so no horizontal scaling. And they seem to think non-relational is the new way to do things. (link)


Where this line of reason goes completely off the rails is in thinking that schema-less databases are a hedge for future uncertainty. Yes they let you churn out code slightly faster, but then your data becomes a ball of mud just as quickly as your code base, except the former is much much worse because when you pivot you still need your data even if you decide to chuck out all the code that goes with it.

In fact, a traditional RDBMS is designed to allow for any kind of ad-hoc querying you desire with reasonable performance, and the ability to normalize/denormalize, index and materialize views in order to optimize unforeseen use cases. The excuse of poor scalability is just a rationalization that some kids who didn’t understand SQL used to justify using something that has a shiny marketing page that they ignorantly found more viscerally appealing. The tradeoff was all wrong, because 99.9% of projects will never need to scale beyond a single DB server, and for those that do, the flexibility of a well-defined schema and ad-hoc queryability will give them an early advantage in what kind of pivots are reasonable—if they are lucky enough to have to scale then they can replace the RDBMS with the context of knowing what exactly their use case that they must scale is. And at that point you’ll presumably have the resources to do it, which is much more effective than prematurely attempting to design a scalable infrastructure and discovering that you didn’t have the first clue what the real bottlenecks or even the full use case would be. (link)



A startup which I have helped architect back end uses mongodb for everything. before starting the project I have requested the CTO not to use mongo as it was not a right fit.Basically they needed more of a relational stuff.The CTO chose mongo because he was thinking every startup uses it and why not us. Now they are suffering as they need ACID and relational features. They want to rewrite to postgres but they are heavily invested and not easy to go back. (link)


The HN crowd tends to insult it, but outside of HN people hype it up. People keep talking about how much they love the MEAN stack. It’s huge in the hackathon crowd, due to them sponsoring many of them, and its low learning curve. (link)


We start our apps with mongo, and design them with a migration plan to postgres. We’ve found it’s very easy to rapidly develop the application with mongo due to it’s flexibility. Once we understand where or app is headed and what our relationships actually are, we pretty much pull the plug out of mongo and stick it in postgres. If you build a reasonably intelligent query wrapper it’s fairly effortless. That being said, we’re thinking of moving our early prototyping to Rethink now that it’s made some strides. (link)

MongoDB and Usability, Documentation, Libraries

Driving Developer Adoption (March 4, 2012)

Easy to get started: Developers have limited time to invest in exploring new technologies, so its critical to make the initial “getting started” experience as seamless as possible. We want it to be dead simple to download MongoDB, and we pride ourselves on ease of installation. You can even try MongoDB without installing anything by playing with our interactive tutorial,

Support is the new marketing: In most cases, a free support forum is a new user’s first interaction with the open source community. You don’t get a second chance to make a first impression. Providing good support isn’t good enough; we strive for amazing support that wows new users, so that they tell all their friends about MongoDB. For example, Kristina once fixed a bug in the Perl driver within a few hours. Who would have thought that the person who found the bug was a developer at Craigslist, who would later tell that story in interviews and presentations?


Guess what I’m using, MongoDB. Why? Their documentation is fan-f’n-tastic. Their newsgroup support is just as good, lots of folks who help troubleshoot issue, including the developers themselves (link)


About the only thing I agree with is how great their docs are. (link)


Mongo absolutely nailed creating a database that is easy to get started with and even do things that are traditionally more ‘hard’ such as replication. It is still super attractive for me to pick it up for small projects, even after dealing with its (many) pain points both in development and operational settings. (link)


The real problem with Mongo is that it’s so enjoyable to start a project with that it’s easy to look for ways to continue using it even when Mongo’s problems start surfacing. (link)


Because postgres doesn’t focus on the first-five-minutes experience the way Mongo does. Even the name is hard to say.

Mongo is a dumb, dead-end platform, but they know how important ease-of-use is. (link)


I worked with MongoDB quite a lot in context of Rails applications. While it has performance issues and can generally become pain because of lack of relations features, it also allows for really fast prototyping (and I believe that Mongoid is much nicer to work with than Active Record).

When you’re developing MVPs, work with ever changing designs and features, ability to cut off this whole migration part comes around really handy. I would however recommend to anybody to keep migration plan for the moment the product stabilizes. If you don’t, you end up in the world of pain. (link)


I think a lot of people (at least in the Node community) love the interfaces provided for it and specifically Mongoose which allows you to enforce a schema and thus relational data.

I’ll admit that I originally got into it because I didn’t really know SQL and I’m still not very talented with it but for example. (link)


This is key and often overlooked – MongoDB is so popular not because it’s the best database but because it’s so easy to get started with. Download/unzip/run to have a database engine ready. It also helps that you can also immediately store anything without any prior setup steps.

Postgres/mysql/sqlserver/etc are nowhere near as easy to install, as fast to get started with or as portable to move around. (link)


Idk about hype, but for node.js virtually every tutorial uses it. (link)


Postgres members should listen this and have a simple getting started guide for osx, Windows, Linux. I tried brew install postgresql. There was no single place which tells me how to start server, access command line, create db etc. (link)


You can insult the developers that use Mongo or you can look at how to get those users onto a better platform. With the modern expectations of full-stack development, is it any wonder that something promising simplicity and zero-configuration data storage does well? (link)


Postgres wasn’t always a great document store…there was definitely a time period where if you wanted to take a document-oriented approach to data modeling, MongoDB was a good way to go. JSONB was only added in the last minor version of Postgres, and while the JSON and HSTORE types were available, it didn’t give you quite the same speed. Now that JSONB is a thing, I think the two databases are more comparable as a document store. (link)

I think this is part of the reason who RoR, MEAN and other such frameworks are so popular. They tend to be easier to setup and many developers love it. My own theory is there are so many bad devs out there so that contributes to the hype because so may devs end up adopting it.

Take it with a grain of salt… (link)

10gen Marketing Strategy

(Primarily written by 10gen Employeees)

simonw on Mongo’s focus on events (Lanyrd founder):

One of the things that’s really impressed me about 10gen is how much effort they’ve put in to running and promoting MongoDB events. We’ve been collecting them on Lanyrd and they’ve been involved with 17 in the past 12 months, and have another 8 coming up (link, ~2011)

Hackathon Sponsorships:

Last fall we started sponsoring buses to bring students to the event. One bus picks up students from Philly, Princeton and Rutgers, and a second bus picks up students from Boston-area schools, Brown, and Yale. This weekend over 300 student hackers came to the event, and 55 of them arrived on the 10gen-sponsored buses (link).

7 tips for getting started with developer marketing

  1. Blog about industry topics

Early on, when your brand name is probably not yet recognizable, you should spend some time blogging about industry topics to demonstrate your expertise. Apigee, for example, has an excellent blog that covers general topics around API best practices. Similarly, at 10gen, our CEO wrote a multi-part blog series on distributed consistency. These types of posts establish you as a thought leader and drive interest in your products.

If youre struggling to find the time to write detailed technical posts, keep your blog up to date with a weekly or monthly round-up of community posts on relevant topics, or announcements about new features and events. Another easy way to generate content is to do short interviews with users, and get them to talk about how your product is great (see this post on AppHarbor for example). The key with blogging is consistency, so set a target (at a minimum, once a month) and stick to it. A short post is better than nothing at all!

Measuring ROI on developer event sponsorship

When I joined 10gen, we were completely focused on adoption, educating the community about MongoDB, and gaining traction. We spoke at local user groups and any conferences that would be interested in learning about NoSQL. We sponsored events to get exposure, but we had a tiny marketing budget so I always negotiated the lowest tier.

As the company grew and hired a sales team, it became necessary to think more critically about how we invest our marketing dollars into developer events. We also had lead generation targets to meet, and events seemed like a great way to accomplish that.

Community is hygiene not heroics

For example, at 10gen, our community marketing programs started with big, one-day conferences. Those events are crucial for seeding community and continue to be important yearly milestones in each city we visit. The conferences are highly visible, somewhat heroic feats.

What many dont see is all the work that happens between each conference. User forum posts, IRC questions, and tweets that receive timely responses. Monthly newsletters targeted for each local market. User groups that meet regularly with the financial and logistical support of 10gen. Personal check-ins with key customers and community members. That is the hygiene required to maintain a successful community.

How to run a tech conference part 6: promotion of your event

Announce to Relevant User Groups

Prior to an event, I usually spend several hours researching where the local technologists congregate. In most US cities, there are active groups on for every major programming language. I typically join the mailing lists for those groups, and lurk for a few weeks to get a feel for the culture of the meet up. If its a high-volume list with lots of announcements and activity, I usually simply send an announcement about the event to the group. If the group is less active, I instead reach out to the organizers to see if making an announcement about the event would be appropriate. In addition, its a good idea to offer a few free passes or swag that the organizers can raffle off during the next meetup. This requires some advance planning, but helps build goodwill with the groups.

Online MongoDB Education and Study Groups

Education has been key to encouraging adoption of MongoDB. Its why we value and invest in training, MongoDB days, and MongoDB User Groups (MUGs). Online courses take that strategy to the next level by enabling us to scale our educational offerings. Last year our in-person, public training courses enabled us to educate 1,000 people on MongoDB. Through, weve already enrolled over 10,000 people for the online classes.

Hence, I was thrilled when my colleague Francesca had the brilliant idea of incorporating our new online education platform with our user group network. One of the biggest challenges the MUGs face is coming up with new content on a regular basis. The launch of provides the MUGs with the perfect set of content for weekly study groups. As each course is released on a weekly basis, the groups can work together on the material and assignments, and hopefully encourage a higher rate of completion of the course.

Lead Generation with Developers

Organize great events: Developers love meeting up. Its a really wonderful and unique thing about people who build software as Ive never seen any other professional group with such an active and diverse conference and meetup scene. If you organize an event with interesting content developers will register and attend. By keeping your events focused on technology you will build credibility within the community. Seeing colleagues at these events also provides validation that your company and/or product is interesting to other developers.

How to Hire Developers/DBAs with MongoDB Experience

As my colleague Matt Asay recently explained on the 10gen blog, the key to recruiting is creating an environment of innovation. Companies that are using open source technologies and openly talking about it have a major advantage.  The best strategy for finding MongoDB talent is getting involved with the MongoDB community and showcasing the interesting work that you are doing with MongoDB, and there are lots of ways to do that.

One way to engage the community is by supporting your local MongoDB User Group. If your company has a large enough space, offer to host the group so that the members can see what your office is like. If you have the budget, consider buying the group pizza or beer during the next event in exchange for the opportunity to talk about job openings. But really, the best thing to do is to give a technical presentation on your MongoDB implementation.

My suggestions above are all great ways to attract people who are already interested in and have some knowledge of MongoDB. But now that 10gen offers free online courses for MongoDB through, you also have the option of hiring someone and training them quickly and at no cost. I havent seen any employers try this yet, but one way to attract talent is for employers to provide new hires with time to take the MongoDB online courses. As recent research from Dice showed in this article in Forbes, engineers with MongoDB skills were among the highest paid in the industry. Offering someone the chance to build that skill set could make a job description a lot more compelling.


“I love the simple web form on Kinvey’s website: I want a sticker. This is a low cost, easy way to build a lead database and get developers to decorate their laptops with your logo!” (link)

10gen Benchmarks

10gen engineer on her mistaken benchmark:

> MongoDB, <b>by default</b>, doesn’t actually have a response for writes.

Whoopsy, got your emphasis wrong there. We did this to make MongoDB look good in stupid benchmarks (;).

Seriously, though, this “unchecked” type of write is just supposed to be for stuff like analytics or sensor data, when you’re getting a zillion a second and don’t really care some get lost if the server crashes. <b>You can do an insert that not only waits for a database response, but waits for N slaves (user configurable) to have replicated that insert.</b> Note that this is very similar to Cassandra’s “write to multiple nodes” promise. You can also fsync after every write. (link)


Marketing. They shipped with unacknowledged writes for a long time and it made them look really good in write benchmarks. Couch was actually trying to keep your data safe. But it didn’t look fast enough so those that didn’t read the fine print on page 195 from the manual where it tells you how to enable safe data storage for MongoDB, jumped on the bandwagon.

Oh and mugs, always the mugs. I have 3 I think. (link)

10gen and Database Marketing


Lots of early database releases are going to be like Mongo, the question is how much the parties at play own up to the fact that their implementation is still immature and present that starkly real truth to their customers. So far, it seems commercial vendors are less likely to do that. (link)


I have no intention of defending MongoDB because what do I know, never worked with it in real life – but just out of curiosity I took the free courses they offer ( and I find that a sizable share of the complaints about MongoDB come from people who don’t seem to have learned much about the product they are using. It’s like people complaining their new truck behaves badly in water. (link)


It’s massively successful in the entry level web coding world due to a combination of good marketing and the belief that it gives you unlimited scale ‘for free’ and everything ‘just works.’

Not saying those are impossible goals but so far no database has managed to deliver that. Building a large-scale endlessly-scalable database is still very hard and very detailed and easy to screw up. (link)


One of the reasons I don’t want to create a company around Redis, but want to stay with VMware forever as an employee developing Redis, is that I don’t want development pressures that are not drive by: users, technical arguments. So that I can balance speed of development and stability as I (and the other developers) feel right. (link)


That’s a totally valid reason to use Mongo, now if only they’d market themselves that way. (link)


Mongo also goes to every conference and pitches themselves constantly. Maybe postgres needs a marketing person 🙂 (link)


Their website is quite hype prone:

The Standard for Modern Applications

MongoDB 3.0 features performance and scalability enhancements that place MongoDB at the forefront of the database market as the standard DBMS for modern applications.

Also included in the release is our new and highly flexible storage architecture, which dramatically expands the set of mission-critical applications that you can run on MongoDB.

These enhancements and more allow you to use MongoDB 3.0 to build

The people who wrote that are not the same people who write the database. (link)


Pretty much everything about the mongodb hate derives from their marketing and sales. The truth is, they’ve obviously stumbled onto something the market wants, otherwise they would never have become so successful. (link)


MongoDB brilliantly won by winning the hearts and minds of hackers and coders who don’t care about such issues, but were able to get started quickly with Mongo (and got cool free cups at meetups). It turns out that’s most engineers out there, definitely the initial critical mass to target for a database startup like Mongo.

Btw. the story behind Oracle is similar: early versions were basically write-only; read Ellison’s book ‘Softwar’. Of course there are other ways to get started: for example DBs coming out of academic research like Vertica seem to avoid this problem; in that case initial funding is basically provided by the gov’t and when they create the company to commercialize they’re already shooting for Enterprise contracts, skipping the opensource/community building phase of Mongo. (link)

If they confront their issues, I think it’s just a matter of time before Mongo wins the NoSQL race. They have what matters most – good people, a brand, and great expectations from customers. (link)

The most interesting lessons from the Jepsen series:

  • You should never trust, and always verify, the claims made by database manufacturers.
  • Especially when those claims relate to data integrity.
  • Super-especially when every safety level provided by the manufacturer that includes the word “SAFE” is actually unsafe. (link)


Mongo absolutely nailed creating a database that is easy to get started with and even do things that are traditionally more ‘hard’ such as replication. It is still super attractive for me to pick it up for small projects, even after dealing with its (many) pain points both in development and operational settings.

Given this, it is so tragic to see how dismissive they have been in regards to the consistency issues that have plagued the db since the early days. Whether it was the stupidity of bad defaults in drivers to not confirm writes, or easily corruptible data in the 1.6 days, or now with not seriously looking at the results of jepsen, the mongodb organization has never taken the issues head on. It would be so refreshing to see more transparency and admitting to the faults rather than wiggling around them until eventually pushing a fix buried in patch notes.

I often feel like a mongodb apologist when I admit that I don’t mind using mongo for small (and not important) projects and while the mongodb hate can be a bit extreme at times, the companies treatment of these sorts of issues may justify some of it. (link)


Half the startups in NYC use mongo, but that might be cause they are connected to Union Sq Ventures, (link)


It would also help if the company that makes a DB would put flashing banner on their page to explain the trade-offs in their product. Such as “we don’t have single server durability built in as a default”.

It is not bad that they had durability turned off. It is just a choice, and it is fine. What is not fine is not making that clear on the front page. (link)


My argument is that the feature disparity between mongo and redis stems mostly from the fact that Antirez has better judgement over what can be made work reliably and what can not. This is why redis clearly states its scope and limits on the tin and performs like a swiss watch within those bounds.

Mongo on the other hand promises the world and then degrades into a pile of rubble once you cross one of the various undocumented and poorly understood thresholds. (link)

10gen’s Helpfulness

“Has Eliot and the rest of his staff @ 10Gen been extremely responsive and helpful whenever we run into problems? Yes, absolutely. Their level of support is amazing.” (link; Harry Heymann @ Foursquare)

”I’ve been to their open office hours in NYC and, though we don’t have a support contract, they were incredibly welcoming and helpful.” (link)

10Gen CTO:

If you want to come talk to the MongoDB team, both our offices hold open office hours where you can come and talk to the actual development teams. We try to be incredibly open, so please come and get to know us. (link)

10gen engineer:

That’s not to say that things never go wrong, MongoDB is definitely not perfect and has lots of room for improvement. I hope that users with questions and problems will contact us on the list, our wiki, the bug tracker, or IRC (or, heck, write a snarky blog post). Anything to contact the community and let us try to help. I wish every person who tried MongoDB had a great experience with it. (link)