Why is MongoDB wildly popular? It’s a data structure thing.

Updated 11/7/14: Fixed typos

"Show me your code and conceal your data structures, and I shall continue to be mystified. Show me your data structures, and I won't usually need your code; it'll be obvious." - Eric Raymond, in The Cathedral and the Bazaar, 1997

Linguistic innovation

The fundamental task of programming is telling a computer how to do something.  Because of this, much of the innovation in the field of software development has been linguistic innovation; that is, innovation in the ease and effectiveness with which a programmer is able to instruct a computer system.

While machines operate in binary, we don't talk to them that way. Every decade has introduced higher-level programming languages, and with each, an advancement in the ability of programmers to express themselves. These advancements include improvements in how we express data structures as well as how we express algorithms.

The Object-Relational impedance mismatch

Almost all modern programming languages support OO, and when we model entities in our code, we usually model them using a composition of primitive types (ints, strings, etc...), arrays, and objects.

While each language might handle the details differently, the idea of nested object structures has become our universal language for describing 'things'.

The data structures we use to persist data have not evolved at the same rate. For the past 30 years the primary data structure for persistent data has been the Table - a set of Rows comprised of Columns containing scalar values (ints, strings, etc...). This is the world of the relational database, popularized in the 1980's by its transactionality, speedy queries, space efficiency over other contemporary database systems, and a meat-eating ORCL salesforce.

The difference between the way we model things in code, via objects, and the way they are represented in persistent storage, via tables, has been the source of much difficulty for programmers. Millennia of man-effort have been put  against solving the problem of changing the shape of data from the object form to the relational form and back.

Tools called Object-Relational Mapping systems (ORMs) exist for every object-oriented language in existence, and even with these tools, almost any programmer will complain that doing O/R mapping in any meaningful way is a time-consuming chore.

Ted Neward hit it spot on when he said:

"Object-Relational mapping is the Vietnam of our industry"

There were attempts made at object databases in the 90s, but there was no technology that ever became a real alternative to the relational database. The document database, and in particular MongoDB, is the first successful Web-era object store, and because of that, represents the first big linguistic innovation in persistent data structures in a very long time. Instead of flat, two-dimensional tables of records, we have collections of rich, recursive, N-dimensional objects (a.k.a. documents) for records.

An Example: the Blog Post

Consider the blog post. Most likely you would have a class / object structure for modeling blog posts in your code, but if you are using a relational database to store your blog data, each entry would be spread across a handful of tables.

As a developer, you need to know how to convert each 'BlogPost' object to and from the set of tables that house them in the relational model.

A different approach

Using MongoDB, your blog posts can be stored in a single collection, with each entry looking like this:

    _id: 1234,
    author: { name: "Bob Davis", email : "bob@bob.com" },
    post: "In these troubled times I like to ...",
    date: { $date: "2010-07-12 13:23UTC" },
    location: [ -121.2322, 42.1223222 ],
    rating: 2.2,
    comments: [
       { user: "jgs32@hotmail.com",
         upVotes: 22,
         downVotes: 14,
         text: "Great point! I agree" },
       { user: "holly.davidson@gmail.com",
         upVotes: 421,
         downVotes: 22,
         text: "You are a moron" }
    tags: [ "Politics", "Virginia" ]

With a document database your data is stored almost exactly as it is represented in your program. There is no complex mapping exercise (although one often chooses to bind objects to instances of particular classes in code).

What's MongoDB good for?

MongoDB is great for modeling many of the entities that back most modern web-apps, either consumer or enterprise:

  • Account and user profiles: can store arrays of addresses with ease
  • CMS: the flexible schema of MongoDB is great for heterogeneous collections of content types
  • Form data: MongoDB makes it easy to evolve the structure of form data over time
  • Blogs / user-generated content: can keep data with complex relationships together in one object
  • Messaging: vary message meta-data easily per message or message type without needing to maintain separate collections or schemas
  • System configuration: just a nice object graph of configuration values, which is very natural in MongoDB
  • Log data of any kind: structured log data is the future
  • Graphs: just objects and pointers - a perfect fit
  • Location based data: MongoDB understands geo-spatial coordinates and natively supports geo-spatial indexing

Looking forward: the data is the interface

There is a famous quote by Eric Raymond, in The Cathedral and the Bazaar (rephrasing an earlier quote by Fred Brooks from the famous The Mythical Man-Month):

"Show me your code and conceal your data structures, and I shall continue to be mystified. Show me your data structures, and I won't  usually need your code; it'll be obvious."

Data structures embody the essence of our programs and our ideas. Therefore, as programmers, we are constantly inviting innovation in the ease with which we can define expressive data structures to model our application domain.

People often ask me why MongoDB is so wildly popular. I tell them it's a data structure thing.

While MongoDB may have ridden onto the scene under the banner of scalability with the rest of the NoSQL database technologies,  the disproportionate success of MongoDB is largely based on its innovation as a data structure store that lets us more easily and expressively model the 'things' at the heart of our applications. For this reason MongoDB, or something very like it, will become the dominant database paradigm for operational data storage, with relational databases filling the role of a specialized tool.

Having the same basic data model in our code and in the database is the superior method for most use-cases, as it dramatically simplifies the task of application development, and eliminates the layers of complex mapping code that are otherwise required. While a JSON-based document database may in retrospect seem obvious (if it doesn't yet, it will), doing it right, as the folks at 10gen have, represents a major innovation.


82 Responses to Why is MongoDB wildly popular? It’s a data structure thing.

  1. Morningtime 2012/08/06 at 8:26 pm #

    Thanks, I’m moving my ecommerce application from MySQL to MongoDb to store product catalogs. Previously this were several dozens of joined tables, now just 1 document – moving to Mongo is like going surfing in Hawaii.

  2. ajung 2012/08/06 at 10:43 pm #

    MongoDB is popular because it is used by people who think that it fits their brain but does not.
    MongoDB is popular because it attracts the former PHP/MySQL programmer swamp.

  3. Christian 2012/08/07 at 6:00 am #

    Your example document structure (and real life document structures) contains redundant information: author: { name: “Bob Davis”, email : “bob@bob.com” }. If you don’t wan’t to update many documents if the author changes it’s email, and if you want to save space, you have to do something like joins too.

  4. Javin Paul 2012/08/07 at 6:10 am #

    I have been hearing mango db from long time  but your blog example makes it quite easy to understand. Thanks for this great post.

  5. andrewvc 2012/08/07 at 8:18 am #

    The oft quoted impedance mismatch isn’t due to bad software design in RDBMSes, but due to two fundamentally different systems interacting. A database is fundamentally different than an in-memory data-structure. Modeling in mongo can be much harder than it is in SQL in many ways.

    For instance, there’s no way to atomically update the author in your example since it’s so denormalized. For a blog, this probably doesn’t matter, for many other applications (say ecommerce) it very much does. Additionally, more normalized data is frequently much easier to work with, as a single atomic update can do the job of a large crawl/update in an object/document DB.

    Lastly, RDBMSes let you execute extremely powerful ad-hoc queries with very little syntax. AFAIK there’s no equivalent to a PG window function in mongo (and no, just saying you can always use map reduce doesn’t count).

    I do, btw appreciate the list of stuff Mongo is good for (though I see you guys left out stuff like finance as that would definitely go in a list of things Mongo is bad for).

    I would say though, that mongo makes little sense for log data (which is present in that list) unless you plan on always having less log data than memory due to mongo’s use of MMAP for everything. Log data usually needs to be queried, and mongo’s poor handling of on-disk data makes it a bad choice for this.

  6. benwen 2012/08/07 at 9:43 am #

    Our Hawaii contingent agrees with you. 

  7. benwen 2012/08/07 at 9:49 am #

    Flexible schema and document-orientedness doesn’t free a designer from making schema choices.  Even with relational table-oriented solutions at larger scales there’s a normalization vs. partial denormalization design tension.  Roughly that’s space/atomicity vs. access time trade-off.  One must also consider the relative frequency and value of each access pattern.  A human at a browser may have only a few seconds of patience, but a large batch analytics job may have overnight latencies, but be worth millions of dollars.  YMMV.

  8. Kim 2012/08/07 at 12:10 pm #

    MongoDB is excellent when you have _a lot_ of fairly similarly structured data (like logs..). It pretty much sucks for your normal “enterprise” system with a billion different entities and their relationships. 

  9. benwen 2012/08/07 at 12:17 pm #

    The claim isn’t that a relational table design is bad.  Far be it from that.  Codd et. al. are visionary.  The tension is that forcing a fully normalized state at rest and then having to constantly move back to the denormalized form is unnecessarily contributing to the heat death of the universe.  

    A flexibly schema’d denormalize-able data store lets a designer choose an intermediate point that may be more natural for the problem domain at hand.  As you note, that flexibility in modeling carries with it a burden of choosing the data representation in a well-fit manner.  

    For the blog/author example, choosing a partially normalized model, where an indirection to another collection (in relational-speak “table”) of authors is completely acceptable.  Part of the art therein is to understand the space/atomicity and access time trade-offs for the most common and most valuable paths. Of course, a relational database can store denormalized data as well; choosing the denormalization point is a practice of the craft. 

    What a core relational table physical model lacks here is the per-document (or row) flexibility of a document-orientation.  Once denormalized, being able to optionally include, extend, nest, or exclude key/values (or columns) is powerful and liberating.  There’s enough rope to hang oneself by over using that flexibility too, creating an unmaintainable knot of mismatched schema.  

    In MongoDB 2.2, the aggregation framework is highly anticipated and allows for some very interesting grouping and cross-document calculation. I’m not a PG guy, so if you’ll excuse the shallow interpretation, it seems similar to PG windows.  More here with an infographic that may help understanding.   http://blog.mongolab.com/2012/07/aggregation-example/ 
    As for logging, I’d be curious as to your opinion of fluentd, a syslog-like daemon for JSON formatted logs.  (Written by our friends over at Treasure Data.)  I’d argue that having a key-indexed datastore is more powerful for querying than a straight flat log search or fragile regex mechanism.  And in any case, fitting into memory wouldn’t work either for an ad hoc search.  Yes, a streaming search or regex would make sense, but then it’s less of a storage / query problem domain.  Thank you for the extended comment.

  10. Patrick Bohan 2012/08/08 at 4:49 am #

    I work on an “enterprise” MongoDB database that has lots of heterogeneous types of data, and it works beautifully, it is the exact opposite of “suck”.

  11. Eric Ingram 2012/09/12 at 11:52 am #

    There’s a new open source e-commerce platform combined with MongoDB, and it’s available soon: http://getfwd.com

  12. benwen 2012/10/08 at 3:26 pm #

    Cool stuff.  I saw getfwd.com a little while ago and thought it was cool.  Tnx for ping!  

  13. Benjamin Abbott-Scott 2012/12/07 at 9:19 pm #

    ORM unfortunately does not go away when using NoSQL.  It just bubbles up into the code, where it suffers the slings and errors of outrageous git pushes.

    Way back when, we had these discrete document collections, each referenced by a key, and you could perform inserts, updates, lock data, synchronize across multiple servers, add layers of caching, etc etc… It was called a filesystem.  NoSQL is little more than a directory tree of Storables, with more overhead, and less maintainability.

  14. Josh Sled 2012/12/13 at 7:58 am #

    The quote at the top of your essay is unfairly attributed; ESR was re-phrasing and indeed quoting Brooks, from the /The Mythical Man Month/, Chapter 9.

  15. MongoLab 2012/12/13 at 2:28 pm #

    Well, yes and no. Technically correct. But imho there’s a fair bit of modern-day value-add in esr’s edits …

    (from http://www.free-soft.org/literature/papers/esr/cathedral-bazaar/cathedral-bazaar-5.html )

    *9. Smart data structures and dumb code works a lot better than the other way around.*

    Brooks, Chapter 9: “Show me your and conceal your [data structures], and I shall continue to be mystified. Show me your [data structures], and I won’t usually need your ; it’ll be obvious.”
    Actually, he said “flowcharts” and “tables”. But allowing for thirty years of terminological/cultural shift, it’s almost the same point.

  16. Nicolas Bousquet 2013/01/23 at 1:24 am #

    Thinking that NoSQL and MongoDB can make you ignore the ORM problem or its equivalent is naive.

    There several differences between let say a MongoDB document and a class hierarchy. There is no visibility, no inheritence for example. More, you’ll not have only one entity storing the whole object graph but many of theses. Maybe you’ll want not be fully normalized. That’s ok, but the same rules still apply.

    You still need to view your data structures as data structures and not as object models. You still need to understand consistency, concurrent update and take care that for depending on how you use your data you’ll need a totally different model.

    The problem of an ORM or its equivalent is not the objects, it is not the data. It is not the mapping. ORMs work just fine, if you understand them. That is you don’t try to map your complete data model to a complete object model. This will always fail for a non trivial example, even with a NoSQL flavor.

    You think to see your data as data. That happen eventually to be seen as objects if you are into that. But your object only contain relevant data for your current task, and mapping is not unversal but linked to this task. No lazy anything, no inheritence. And the mapping become easy and fast. Data problems are modelized in the database (relational or not) and that all.

  17. Christopher Rueber 2013/01/23 at 8:02 am #

    Calling people naive, when you’re using examples of problems that have fairly simple solutions (visibility, inheritance), only makes you look like you’re just arguing to argue, without fully understanding how the solution works/can work.

  18. Volodymyr Bilyachat 2013/05/09 at 3:20 am #

    I have short question lets say we have many places where user can comment and one place where we should show some thing like a feed, how is that possible to do that because What i am thinking about its just save duplicates in “feed” collection so when user post comment we will save in original document lets say for photo or article, and save duplicate in feed or is this here any better ways to figure it out?

  19. Akatsuki Sai 2013/05/09 at 3:23 am #

    I hope only one language only exist on the future… JAVASCRIPT! =p

  20. Akatsuki Sai 2013/05/09 at 3:25 am #


  21. Randy 2013/05/09 at 4:23 am #

    With that you cant be straight , you need to have backbone . : )

  22. Akatsuki Sai 2013/05/09 at 11:56 am #

    you mean backbonejs? yes, but i’m trying to make it simple and less code although i also think that backbone and angular can be combined.. I just want to experiment if it possible with just few recipe can make a cute mini facebook.. =)

  23. Ionut Manolache 2013/10/30 at 11:21 am #

    Ok, so do you many-to-many relations as long as there is no “join” in the NoSQL dbs?

  24. Ionut Manolache 2013/10/30 at 11:22 am #

    *…how do you do….

  25. obiwanginobli 2013/10/30 at 12:44 pm #

    rails as ORM

  26. rohan 2014/01/13 at 6:55 am #

    I have found a good tutorial to mongoDB.

    Hopefully it helps.

  27. sankalp singha 2014/01/30 at 7:45 pm #

    Add ReactJs to it.. You definitely have the next FB :P

  28. Patrick Daures 2014/04/05 at 2:48 pm #

    You must be kidding, right ?

  29. Akatsuki Sai 2014/04/08 at 11:07 pm #

    Performance, speed and easy to manipulate database are advantages of mongodb to mysql. But relation from table to another table or collection to another collection is quite a little more extra work needed. In mysql, it’s automatically cascade dependents data of the one to be deleted while in mongodb, you need to programmatically code to check first if there dependent data before deleting.. for user’s posts must be deleted first before deleting it’s account.. But I’m positive kind elite programmer there will make plugin to solve this problem.. =)

  30. Julian Reyes E 2014/04/22 at 12:18 pm #

    @google-ad5a7252f318a4e27373ce8e4fadcb72:disqus can you help showing me a technical example. how to handle relationships or handle the update/deletes when the information is denormalized?

  31. Pedro Figas 2014/07/14 at 2:50 am #

    I have started to use MongoDB recently and I can feel that along it’s benefits and features, it requires well thought-out data models and is also packed with knobs of configuration that need to be understood very well before hitting production (as in I took their course, read their manuals and experimented and I still feel like I don’t grasp it like a bauss).

    What I’d love is a Hybrid system! A database system that would somehow join the best of both worlds efficiently, mainly to save roundtrips to separate relational and a non-relational databases and provide querying like the Universe has never seen.

    I’m certain that someone has already built a demon of sorts, but I haven’t heard of it (at least without digging a few meters of Google soil). I’m sure the brain of the web will conjure up something rock-solid and community-strong soon.

  32. Jon 2014/07/31 at 10:18 am #

    Hi Andrewvc,

    Could you please speak further to MongoDB and Finance?


  33. Hermansyah Sofyan 2014/09/16 at 1:28 am #

    LOL!!! that never happens bro unless u r the only programmer left on earth

  34. Munier 2014/10/20 at 3:47 am #

    I am looking for an article that represents a general structure of object relational database

  35. Shalin Siriwaradhana 2014/10/21 at 5:43 am #

    I got a question for you can object oriented concepts applied to javascripts?


  36. Dan Dascalescu 2014/11/06 at 9:59 pm #

    I got a question for you do you speak English?

  37. Shalin Siriwaradhana 2014/11/11 at 8:52 pm #

    Sorry if i make you confused, its a question I had for OOP

  38. gerta kapodistrias 2015/01/13 at 6:48 pm #

    Information don’t have to be denormalized, and that’s where mongoDB makes the difference. It doesn’t enforce any kind of structure thus allowing it to work exactly like any RDBMS

  39. Fred 2015/05/12 at 10:07 am #

    Why is Mongo more popular than object-oriented databases, then? Mongo looks essentially like an OODB, except with no schema, no joins, and no standards compliance. Sure, OQL failed in the marketplace, but not because of technical flaws. Is there any way in which Mongo’s query language is better than OQL? Having used both, I can’t think of any.

    I can’t tell what the ESR quote is doing as your prologue. It seems to be precisely the opposite of what you’re promoting. The defining aspect of Mongo seems to be that the object types are never actually defined anywhere, except implicitly in how the database is used by your application. With an RDBMS or OODB, the types are plainly visible (in the schema), and this makes the entire program obvious. With Mongo, the types are hidden in code.

    When I see a new codebase that uses Mongo, I continue to be mystified, until I’ve read the entire source. When I see a new codebase that uses SQL, I glance at information_schema it’s all clear.

  40. Tuna 2015/11/21 at 4:28 am #

    Because having my data stored as big JSON blobs is an improvement how? It will fill a niche role but there is far to much investment in applications developed using a relational DB model for things to change drastically anytime soon.

    In reality most software is not Google, Amazons etc. back end. There is also the problem with MongoDB not being transactional its a really big problem actually.

  41. Tuna 2015/11/21 at 2:51 pm #

    except for ACID because it doesn’t have that. which attackers have already exploited

  42. mbokil 2016/01/10 at 8:59 am #

    I code in JS for client (Angular) and now JS for backend using Node/Express. I occasionally use Python too but for the most part @akatsukisai:disqus your prediction came true for me. JS all the way!

  43. mbokil 2016/01/10 at 9:05 am #

    React is cool but I have been using the beta Angular 2 lately for new apps and the component structure is very nice. Probably will challenge React. In some way Angular 2 is better for me since you get the whole MVC framework in one shot.

  44. mbokil 2016/01/10 at 9:06 am #

    Nicely stated. You really have to think a while about your data structure before you jump into mongo. But if you get it right it is very nice to work with and fast! I think probably some of the criticism of mongo stems from developers using it without designing a good schema that reflects their data.

  45. Justin 2016/02/04 at 3:08 am #

    Once WebAssembly is complete I predict JS will die and Python will take its place.

  46. Arjun 2016/02/21 at 9:35 am #

    Hi Andrew, do still stand with the same words that you commented or learning and working in mongo. Am newbie to get into it, just curious to know whether I can step in or not.

  47. Gilbert Pilz 2016/08/18 at 9:00 am #

    “Horses for courses”. Designing a language is a matter of making tradeoffs. For example, between runtime performance and ease of use. No single language is appropriate for all environments and tasks. It is madness to suppose that the language that is appropriate for writing a web application that executes within the context of a browser is also appropriate for writing the controller code for an IoT device with extremely limited memory and power.

  48. JT 2016/10/27 at 2:31 pm #

    I will give you my life savings when JS dies and Python takes its place.

    I love Python, but JS is going nowhere fast.

  49. Winstoniceks 2017/03/11 at 1:30 am #

    thanks due to the fact that this significant illuminating website, finance up the massive undertaking check out this [url=http://onlinecasinos-x.com]casino online[/url] offers , buy [url=http://esextoyfun.com]sex toys[/url]

  50. Winstoniceks 2017/03/13 at 3:34 am #

    thanks benefit of this significant edifying website, obstruct up the massive undertaking check out this [url=http://onlinecasinos-x.com]casino[/url] offers , buy [url=http://esextoyfun.com]sex toys[/url]

  51. cartier love anello imitazione 2017/03/16 at 11:31 am #

    cartierlovejesduas Sounds challenging! Looking forward to seeing the completed project after all this hard work has been completed
    cartier love anello imitazione

  52. cartier tank francese imitazione 2017/03/16 at 11:31 am #

    cartierlovejesduas I personal a number of web sites which consist of blogs, article directories, and also web directories. I am curious on whether or not you have an interest in exchanging links with my different websites. I’d be more than pleased if you can approve this remark and let me know the links that you really want me to insert into my website, and I’ll comply. Sorry my english not very good. Let me know.
    cartier tank francese imitazione

  53. cartier ballon bleu orologio copia 2017/03/16 at 11:31 am #

    cartierlovejesduas This is a very bad development that will undoubtedly inflame the anti-black-prez crowd. We in MT deserve answers, even if they can’t unring the bell.
    cartier ballon bleu orologio copia

  54. cartierlovejesduas I’m trying to get back to muscle tone up . I’m not sure what is the best solution for excerzing my leg muscle without injuring my knees . .
    bracelet love cartier or rose prix faux

  55. seo 2017/03/18 at 9:46 am #

    Hello Web Admin, I noticed that your On-Page SEO is is missing a few factors, for one you do not use all three H tags in your post, also I notice that you are not using bold or italics properly in your SEO optimization. On-Page SEO means more now than ever since the new Google update: Panda. No longer are backlinks and simply pinging or sending out a RSS feed the key to getting Google PageRank or Alexa Rankings, You now NEED On-Page SEO. So what is good On-Page SEO?First your keyword must appear in the title.Then it must appear in the URL.You have to optimize your keyword and make sure that it has a nice keyword density of 3-5% in your article with relevant LSI (Latent Semantic Indexing). Then you should spread all H1,H2,H3 tags in your article.Your Keyword should appear in your first paragraph and in the last sentence of the page. You should have relevant usage of Bold and italics of your keyword.There should be one internal link to a page on your blog and you should have one image with an alt tag that has your keyword….wait there’s even more Now what if i told you there was a simple WordPress plugin that does all the On-Page SEO, and automatically for you? That’s right AUTOMATICALLY, just watch this 4minute video for more information at. Seo Plugin

  56. nike air max 95 dark blue 2017/03/20 at 12:08 am #

    Sanders denied he agreed with any team aside from the Broncos.

  57. restaurants oceanside 2017/03/20 at 12:39 am #

    For those in Oceanside somewhat longer than several hours, the collection at the 101 (Coast Road) and Pier Watch is really a valuable stop.

  58. 360 frontal 2017/03/22 at 4:01 pm #

    Magnifique!! quel adorable 360 frontal, vendeur que sympa, confidence au top Indulgence!!!!!

  59. restaurants oceanside ca 2017/03/22 at 6:30 pm #

    Whether it is your very first time in Florida or you are
    a veteran visitor, there’s always something not used to find.

  60. jogging slim adidas femme 2017/03/24 at 10:08 am #

    Sanchez now has four road playoff wins in two seasons.

  61. Nancee 2017/03/24 at 11:17 am #

    When buying jewelry, ask a pal what looks good on you.

  62. Julie 2017/03/24 at 11:17 am #

    The perfectly matching jewelleries could make your get-up quite beautiful and fairly.

    For example, a white pearl necklace and earrings go advantageous with a lace-primarily based black gown. The costume jewelry shop in Newcastle has a great variety
    of ornaments for you.

  63. restaurants oceanside 2017/03/24 at 11:52 am #

    Need fresh cakes in oceanside, hello prime yelp searches in oceanside, cupcake lovers , prime yelp
    queries in oceanside.

  64. Abe 2017/03/24 at 8:30 pm #

    Diamonds in historic time had been referred to as Vajra, which transliterates to
    Thunderbolt in Sanskrit.

  65. Joma Jewellery UK 2017/03/24 at 10:00 pm #

    Over the course of his romances, Charlton, who died in 1974, purchased his wife vintage diamond earrings,
    bracelets, rings and necklaces.

  66. Elvin 2017/03/25 at 9:24 am #

    There are two essential the explanation why selling scrap gold is on the rise.
    Firstly, with the present financial local weather more of us want to lift further cash and
    may now not afford to have unused gold or jewelry simply caught in a drawer gathering mud.

  67. Billiemog 2017/03/27 at 7:32 am #

    There’s still a great deal of work to become completed with instructing people inside the endorsement of the diversified civilizations and national communities. Acceptance and respect will be the biggest dilemmas.
    custom coursework writing service – course work help – $13/page

  68. air max 90 red white grey 2017/03/27 at 10:58 pm #

    Sandersloss will still leave a lack of depth at the position.

  69. vanessasl 2017/03/28 at 12:13 am #

    Ich bei Sie ich kann fragen?

  70. colimas oceanside 2017/03/28 at 2:21 am #

    I try to dismiss all CA generalisation, because it’s this kind of diverse state (from what I
    Have read) that there surely is both a spot for all along with a location for all to not


  1. – Found: One Baby in a Pool of Bathwater - 2012/09/05

    […] MongoLabs published an interesting post on their take as to why MongoDB has become so popular. We here at Akiban really enjoyed this post. […]

  2. MongoLab explains why everyone loves MongoDB (and raises $5M) ← techtings - 2012/10/31

    […] explains the idea more fully in an August blog post on the topic, but the general idea is that document databases such as MongoDB let users store […]

  3. MongoLab explains why everyone loves MongoDB (and raises $5M) — Data | GigaOM - 2012/10/31

    […] explains the idea more fully in an August blog post on the topic, but the general idea is that document databases such as MongoDB let users store […]

  4. Links & reads for 2013 Week 6 | Martin's Weekly Curations - 2013/02/10

    […] Why is MongoDB wildly popular? It’s a data structure thing. […]

  5. Found: One Baby in a Pool of Bathwater | The Akiban Blog - Database Flexibility without Compromise - 2013/02/28

    […] MongoLabs published an interesting post on their take as to why MongoDB has become so popular. We here at Akiban really enjoyed this post. […]

  6. OPENDBTEAM.com - Why is MongoDB wildly popular? It’s a data structure thing. - 2013/05/09

    […] Source: http://blog.mongolab.com/2012/08/why-is-mongodb-wildly-popular […]

  7. MongoDB review - 2014/05/21

    […] During 30 years, coding objects were evolving but in the same time the data representation in database did not change. The ORM was time consuming. With NoSQL, and MongoDB, all the concept changed. See why MongoDB became so popular: http://blog.mongolab.com/2012/08/why-is-mongodb-wildly-popular/ […]

  8. MongoDB and Java | CM Software Technology - 2014/07/29

    […] http://blog.mongolab.com/2012/08/why-is-mongodb-wildly-popular/ […]

  9. MongoDB, Cassandra, and HBase — the three NoSQL databases to watch | Cloud Hooligans - 2014/12/14

    […] because it’s so easy to learn. Will Shulman, CEO of MongoLab (a MongoDB-as-a-service provider), says it this […]

  10. MEAN stack | techflashblog - 2015/12/02

    […] the beginning one would be repulsed by a database that lacks relational mapping but let me quote this article and list the good points about […]

  11. What is So Exciting About MongoDB? | 24NewsPage - 2015/12/06

    […] In the 90’s attempts were made to create object databases as alternatives to the relational databases, but there was no real success. MongoDB is one of the first successful document databases that no longer uses two-dimensional, flat tables for record storage. […]

Leave a Reply