8 ms·

MongoDB History

34 points by jaysonqpt 6y ago

jaysonqpt 6y ago
A detailed and interesting history of MongoDB database.
jd_mongodb 6y ago
A pretty solid history. Kinda skipped over the launch of MongoDB Atlas, but this is the only miss in a pretty accurate account.
tobyhede 6y ago
A complete history with all the data ... unlike MongoDB. Boom tish etc.
- numlock86 6y ago
  I never got a definite answer: What problem does MongoDB even try to solve?
  - wmf 6y ago
    The problem of schemas slowing your development.
    - deleted 6y ago
      [deleted]
    - threeseed 6y ago
      There is this myth that schemas must be enforced at the database level. But the majority of databases are only accessed by one web app. And in that web app you can enforce that schema in code. In fact in code you have much safer and powerful options e.g. enforcing business rules such as this string field must start with aaa.
      - fiedzia 6y ago
        >There is this myth that schemas must be enforced at the database level. You must have single point to enforce anything. This is very rarely the case with the app, where a) there will be 20 places that access database and b) often some tasks are done by operating on a database directly Some rules cannot be enforced by database, sure, but "a field must exists and be a string" is infinitely better than noting.
        threeseed 6y ago
        You do have a single point to enforce everything: code. In most cases it is only a single web app connecting to a database and in micro-services architectures you can enforce it through a shared database access library. And any company that allows users to make direct changes to a database without going through some security layer is pretty incompetent. Quite sure you wouldn't be able to get PCI/HIPAA certified with that sort of behaviour either.
        fiedzia 6y ago
        >You do have a single point to enforce everything: code "code" usually is made of many smaller parts, what will keep those in sync to enforce anything? You are placing a burden on a developer (even more likely - on a group of developers), that just doesn't work in practice. > And any company that allows users to make direct changes to a database without going through some security layer is pretty incompetent Sure. But without schema at database level, there is no "security layer" to rely on. And you will eventually need to make a change that cannot be done via UI.
        adoxyz 6y ago
        The thing about MongoDB is that it does support $jsonSchema for enforcing a schema in a very flexible way. So rather than having to have a strict schema for every piece of data, you can use $jsonSchema for as little or as much of your data as you see fit so really you can have the best of both worlds. For reference: https://docs.mongodb.com/manual/reference/operator/query/jsonSchema/#json-schema https://docs.mongodb.com/manual/reference/operator/query/jso...
  - manigandham 6y ago
    Schemaless data (or at least schema-on-read rather than on-write) is the primary feature. Store JSON documents and index on any field. Also it was great at sharding and scaling horizontally when first released, and one of the few options available at that time. It's since been eclipsed by much better systems that don't have such a convoluted and fragile setup. These days there's not much benefit over a JSON field in a relational database, unless you're really invested in JSON/Javascript through your entire stack and want that to reach into the database as well.
    - trashcan 6y ago
      > Also it was great at sharding and scaling horizontally when first released, and one of the few options available at that time. It's since been eclipsed by much better systems that don't have such a convoluted and fragile setup. What applications are much better in your opinion?
      - manigandham 6y ago
        I'd recommend sticking with relational databases since they all support JSON columns now. If you need horizontal scalability then there are many choices like CockroachDB, Yugabyte, TiDB, Vitesse, MemSQL, and others. If still want a document-store then RavenDB is a great choice with proper clustering, full-text search, SQL-like querying, graph queries, etc. ArangoDB is also good choice.
        trashcan 6y ago
        I apologize, because I literally don't know, but have you used any of these solutions at the scale where there might be billions or trillions of rows in a table/collection? I'm currently using Mongo at that scale and would love to evaluate some alternatives. If it helps for context, we have accepted that ad-hoc queries are not possible, and we have our own solution for searching.
        jinqueeny 6y ago
        TiDB has a similar case study: Queries over 1.3 Trillion Rows of Data Within Milliseconds of Response Time at Zhihu.com https://pingcap.com/success-stories/lesson-learned-from-queries-over-1.3-trillion-rows-of-data-within-milliseconds-of-response-time-at-zhihu/ https://pingcap.com/success-stories/lesson-learned-from-quer... The latest stats in the same case scenario (already-read posts) Zhihu is: - 2.6 Trillion Rows - 560TB data - 200 TiKV instances
  - threeseed 6y ago
    MongoDB is the fastest and easiest to scale schema-on-read document store. So if your domain model is document orientated e.g. a star schema with dozens of joins, where you don't know the schema upfront or you have polymorphic relationships it is a really useful way to store your data.
    - kvn_95 6y ago
      I would also add that the replica set concept that is based on Raft [0] allows for built-in high availability, so the individual servers can be maintained while the whole set is running and servicing clients. [0] https://en.wikipedia.org/wiki/Raft_(computer_science) https://en.wikipedia.org/wiki/Raft_(computer_science)
    - numlock86 6y ago
      Hm, my impression was always that if I have such data I didn't really understand my data yet. What's a concrete prime example for using MongoDB?
      - staysaasy 6y ago
        That's actually kind of the point – if you're working on a new project whose requirements might change rapidly Mongo can be a really great fit (eg a toy project; a prototype for a new internal service; a hackathon; a pre-traction startup).
  - jaysonqpt 6y ago
    It is a free and open source NoSQL database that can horizontally scale if needed without any additional plumbing. A lot of projects use it due to its simplicity in developer workflow.
  - madarco 6y ago
    I can share why I used it for 2 products (and regret not using it in 1): - if you are using an ORM library, it avoids unnecessary sync/migration steps by moving the schema definition only in the ORM (as opposed as in the ORM and synced to prostgres/mysql) - It is the fastest while used in-memory. I run the full suite of integration tests for a medium complexity api in 30 seconds. On one product (w/ postgres) we did run tests on sqlite but it's much slower (10x times). - It includes a lot of small features common in web sites or apis: media storage, queues, auto removal of old rows, full text search, geo queries. A dedicated solution (solr, s3, redis) would be better, but for small scale projects mongo was just fine (and a single thing to maintain, backup, monitor) - easy to learn, never hired someone with previous mongo experience, but it was never a problem: having a less expressive query language means that's easier
skywhopper 6y ago
Lots of interesting info, and I really like working with MongoDB. But I am baffled by the claim that "MongoDB is the king." In all the circles I work in, I only hear Mongo dismissed as a joke. Unfortunately the company's dismissiveness of RDBMSes, their hubris in pushing NoSQL, and their blunders over what are extremely poor default settings all combine to make MongoDB something I don't see anyone taking seriously. I use it in a project where it's basically just serving as a big cache, so the reliability and durability of the data is not critical. It's certainly way easier to query than any other document-oriented database, but getting a foothold to use for anything requiring long-term storage would be a major challenge.
- tbrock 6y ago
  I am biased but you are definitely missing out by just listening to your friends on this one. These days MongoDB is pretty mature and the “MongoDB sucks” meme is getting pretty long in the tooth. It turns out it takes a decade to build a new database that’s half decent and has all the features people want. It’s really hard! Ask anyone that’s tried. The path is littered with skeletons. Of course, there are those databases that are “perfect” from the start and never made any mistakes but is anyone talking about them today? Even Postgres gets it wrong sometimes.
  - ht85 6y ago
    > Even Postgres gets it wrong sometimes Imagining a timeline where people would say that about MongoDB is a good way to assess the project's quality...
  - pritambaral 6y ago
    MongoDB Inc. is still in the business of lying to its users through its teeth: https://news.ycombinator.com/item?id=23499658 https://news.ycombinator.com/item?id=23499658 And that's just a publicly available example. I have a client who paid for a MongoDB Inc. to send an "expert" down to assess the viability of a project, who flat out said the project can't be done and left it there; a week later the official MongoDB Inc. report says "We can definitely get it done. Why don't you move to our managed MongoDB Atlas service? That'll be $10K." For the record, my professional assessment was also that it'd be impossible to do it on a data model like Mongo's. ---- > Of course, there are those databases that are “perfect” from the start and never made any mistakes but is anyone talking about them today? Even Postgres gets it wrong sometimes. 1. The snark isn't helping your cause. 2. Then there are databases that claim to be "perfect" from the start, having always put up a facade without every admitting any of their own flaws. Like MongoDB. The thing MongoDB does best — though not something a DBMS can be judged by — is marketing. Not just the marketing they push themselves — "MongoDB is web scale!", "90% of RDBMS use can be replaced by MongoDB!" — but also the marketing it can get its fans to push.
surajs 6y ago
Hugh mongo... Sorry wrong website
slyall 6y ago
The "Mongo DB is Web Scale" video just turned 10 years old. I'm pretty sure that was a big factor in MongoDB not being taken seriously by many people. https://www.youtube.com/watch?v=b2F-DItXtZs https://www.youtube.com/watch?v=b2F-DItXtZs
- gramakri 6y ago
  Ah good memories. Such gems. "relation dbs have impotence mismatch" "does /dev/null support sharding" "redis will kick memcache's ass"
- threeseed 6y ago
  Anybody who makes complex technology decisions based on marketing copy doesn't deserve to be taken seriously either. Not that I think these people actually exist other than in the minds of many HN commenters. Oracle on their website right now says "we lead the market in autonomous, cloud, and applications technologies". I assume you think developers are going to suddenly abandon AWS, Python etc and move entirely to an Oracle stack based off this quote ?
  - blibble 6y ago
    at large firms the clueless technology managment often buy based on the marketing crap, then force it down the throats of the engineers at my firm we're being all but forced to use Azure even though it costs more and makes absolutely no sense whatsoever for the domain, but since it's the "technology strategy" fighting it becomes exceptionally difficult
    - jd_mongodb 6y ago
      In seven years working at MongoDB the one thing I have learned is technology is never "forced down the throat of the engineers". Developers have choices and would not stay in an organisation that made decisions that way. The reason developer relations exists is the acknowledgement that developers ARE the decision makers in most technology selection.
chrisfosterelli 6y ago
MongoDB still has an awful reputation on Hacker News but I really appreciate the take from "Why RethinkDB Failed" [0]: > People wanted RethinkDB to be fast on workloads they actually tried, rather than “real world” workloads we suggested. For example, they’d write quick scripts to measure how long it takes to insert ten thousand documents without ever reading them back. MongoDB mastered these workloads brilliantly, while we fought the losing battle of educating the market. > almost everyone was asking “how is RethinkDB different from MongoDB?” We worked hard to explain why correctness, simplicity, and consistency are important, but ultimately these weren’t the metrics of goodness that mattered to most users. > But over time I learned to appreciate the wisdom of the crowds. MongoDB turned regular developers into heroes when people needed it, not years after the fact. It made data storage fast, and let people ship products quickly. And over time, MongoDB grew up. One by one, they fixed the issues with the architecture, and now it is an excellent product. It may not be as beautiful as we would have wanted, but it does the job, and it does it well. In my mind Mongo is a database that had great developer experience, excellent marketing, and some seriously bad technical gotchas. But marketing drove momentum long enough to cover bills, grab the market, and address most of the gotchas, so now it's a decent DB. [0]: https://www.defmacro.org/2017/01/18/why-rethinkdb-failed.html https://www.defmacro.org/2017/01/18/why-rethinkdb-failed.htm...
- kvn_95 6y ago
  It also helps that the creator of the default storage engine (WiredTiger) are Keith Bostic of BerkeleyDB fame [0] and Michael Cahill, whose PhD thesis on serializable snapshot isolation [1] formed the basis of Postgres concurrency control [2]. Notably, both of them still work for MongoDB. [0] https://en.wikipedia.org/wiki/Keith_Bostic https://en.wikipedia.org/wiki/Keith_Bostic [1] https://dl.acm.org/doi/10.1145/1376616.1376690 https://dl.acm.org/doi/10.1145/1376616.1376690 [2] https://wiki.postgresql.org/wiki/SSI https://wiki.postgresql.org/wiki/SSI
- jaysonqpt 6y ago
  I think MongoDB 3.6 is when it became a "decent" DB. Azure CosmosDB provides protocol level for MongoDB 3.6. This offers developers a neat way of using the power of distributed CosmosDB without sacrificing cloud portability.
mattbillenstein 6y ago
Mongo is much maligned here and I hesitate to even comment for fear of attack, but in my mind it has some compelling use cases and after Wired Tiger became the default storage engine, that pretty much solved the issues with compaction I had seen in the past while delivering a lot more performance. I've built systems with it where we didn't own the schema - we were scraping data from other places and schemaless was a feature. And I benchmarked it against Postgres and a couple other things and I just couldn't get the same performance - note our operations were idempotent to the db, so even in a hard crash, we could just re-run the scraping job and we wouldn't really "lose" any data -- or even if the data was stale by a day, not a big deal... That system would do tens of millions of upserts per night on not crazy AWS hardware and it ran for years like this without problems. Would I use mongo for situations where I needed transactions? Almost never - I actually like Postgres a lot and it's my default for your run of the mill CRUD apps since you can do geo, crypto, search, etc by just installing a few extensions. Do I got on HN on every mongo article and bash them constantly? No, I think they've built a pretty decent thing if you understand the implications of not confirming writes to replicas and whatnot and tune it to your needs.

34 points by jaysonqpt 6y ago

A detailed and interesting history of MongoDB database.

A pretty solid history. Kinda skipped over the launch of MongoDB Atlas, but this is the only miss in a pretty accurate account.

tobyhede 6y ago

A complete history with all the data ... unlike MongoDB. Boom tish etc.

numlock86 6y ago
I never got a definite answer: What problem does MongoDB even try to solve?
- wmf 6y ago
  The problem of schemas slowing your development.
  - deleted 6y ago
    [deleted]
  - threeseed 6y ago
    There is this myth that schemas must be enforced at the database level. But the majority of databases are only accessed by one web app. And in that web app you can enforce that schema in code. In fact in code you have much safer and powerful options e.g. enforcing business rules such as this string field must start with aaa.
    - fiedzia 6y ago
      >There is this myth that schemas must be enforced at the database level. You must have single point to enforce anything. This is very rarely the case with the app, where a) there will be 20 places that access database and b) often some tasks are done by operating on a database directly Some rules cannot be enforced by database, sure, but "a field must exists and be a string" is infinitely better than noting.
      - threeseed 6y ago
        You do have a single point to enforce everything: code. In most cases it is only a single web app connecting to a database and in micro-services architectures you can enforce it through a shared database access library. And any company that allows users to make direct changes to a database without going through some security layer is pretty incompetent. Quite sure you wouldn't be able to get PCI/HIPAA certified with that sort of behaviour either.
        fiedzia 6y ago
        >You do have a single point to enforce everything: code "code" usually is made of many smaller parts, what will keep those in sync to enforce anything? You are placing a burden on a developer (even more likely - on a group of developers), that just doesn't work in practice. > And any company that allows users to make direct changes to a database without going through some security layer is pretty incompetent Sure. But without schema at database level, there is no "security layer" to rely on. And you will eventually need to make a change that cannot be done via UI.
      - adoxyz 6y ago
        The thing about MongoDB is that it does support $jsonSchema for enforcing a schema in a very flexible way. So rather than having to have a strict schema for every piece of data, you can use $jsonSchema for as little or as much of your data as you see fit so really you can have the best of both worlds. For reference: https://docs.mongodb.com/manual/reference/operator/query/jsonSchema/#json-schema https://docs.mongodb.com/manual/reference/operator/query/jso...
- manigandham 6y ago
  Schemaless data (or at least schema-on-read rather than on-write) is the primary feature. Store JSON documents and index on any field. Also it was great at sharding and scaling horizontally when first released, and one of the few options available at that time. It's since been eclipsed by much better systems that don't have such a convoluted and fragile setup. These days there's not much benefit over a JSON field in a relational database, unless you're really invested in JSON/Javascript through your entire stack and want that to reach into the database as well.
  - trashcan 6y ago
    > Also it was great at sharding and scaling horizontally when first released, and one of the few options available at that time. It's since been eclipsed by much better systems that don't have such a convoluted and fragile setup. What applications are much better in your opinion?
    - manigandham 6y ago
      I'd recommend sticking with relational databases since they all support JSON columns now. If you need horizontal scalability then there are many choices like CockroachDB, Yugabyte, TiDB, Vitesse, MemSQL, and others. If still want a document-store then RavenDB is a great choice with proper clustering, full-text search, SQL-like querying, graph queries, etc. ArangoDB is also good choice.
      - trashcan 6y ago
        I apologize, because I literally don't know, but have you used any of these solutions at the scale where there might be billions or trillions of rows in a table/collection? I'm currently using Mongo at that scale and would love to evaluate some alternatives. If it helps for context, we have accepted that ad-hoc queries are not possible, and we have our own solution for searching.
        jinqueeny 6y ago
        TiDB has a similar case study: Queries over 1.3 Trillion Rows of Data Within Milliseconds of Response Time at Zhihu.com https://pingcap.com/success-stories/lesson-learned-from-queries-over-1.3-trillion-rows-of-data-within-milliseconds-of-response-time-at-zhihu/ https://pingcap.com/success-stories/lesson-learned-from-quer... The latest stats in the same case scenario (already-read posts) Zhihu is: - 2.6 Trillion Rows - 560TB data - 200 TiKV instances
- threeseed 6y ago
  MongoDB is the fastest and easiest to scale schema-on-read document store. So if your domain model is document orientated e.g. a star schema with dozens of joins, where you don't know the schema upfront or you have polymorphic relationships it is a really useful way to store your data.
  - kvn_95 6y ago
    I would also add that the replica set concept that is based on Raft [0] allows for built-in high availability, so the individual servers can be maintained while the whole set is running and servicing clients. [0] https://en.wikipedia.org/wiki/Raft_(computer_science) https://en.wikipedia.org/wiki/Raft_(computer_science)
  - numlock86 6y ago
    Hm, my impression was always that if I have such data I didn't really understand my data yet. What's a concrete prime example for using MongoDB?
    - staysaasy 6y ago
      That's actually kind of the point – if you're working on a new project whose requirements might change rapidly Mongo can be a really great fit (eg a toy project; a prototype for a new internal service; a hackathon; a pre-traction startup).
- jaysonqpt 6y ago
  It is a free and open source NoSQL database that can horizontally scale if needed without any additional plumbing. A lot of projects use it due to its simplicity in developer workflow.
- madarco 6y ago
  I can share why I used it for 2 products (and regret not using it in 1): - if you are using an ORM library, it avoids unnecessary sync/migration steps by moving the schema definition only in the ORM (as opposed as in the ORM and synced to prostgres/mysql) - It is the fastest while used in-memory. I run the full suite of integration tests for a medium complexity api in 30 seconds. On one product (w/ postgres) we did run tests on sqlite but it's much slower (10x times). - It includes a lot of small features common in web sites or apis: media storage, queues, auto removal of old rows, full text search, geo queries. A dedicated solution (solr, s3, redis) would be better, but for small scale projects mongo was just fine (and a single thing to maintain, backup, monitor) - easy to learn, never hired someone with previous mongo experience, but it was never a problem: having a less expressive query language means that's easier

skywhopper 6y ago

Lots of interesting info, and I really like working with MongoDB. But I am baffled by the claim that "MongoDB is the king." In all the circles I work in, I only hear Mongo dismissed as a joke. Unfortunately the company's dismissiveness of RDBMSes, their hubris in pushing NoSQL, and their blunders over what are extremely poor default settings all combine to make MongoDB something I don't see anyone taking seriously. I use it in a project where it's basically just serving as a big cache, so the reliability and durability of the data is not critical. It's certainly way easier to query than any other document-oriented database, but getting a foothold to use for anything requiring long-term storage would be a major challenge.

tbrock 6y ago
I am biased but you are definitely missing out by just listening to your friends on this one. These days MongoDB is pretty mature and the “MongoDB sucks” meme is getting pretty long in the tooth. It turns out it takes a decade to build a new database that’s half decent and has all the features people want. It’s really hard! Ask anyone that’s tried. The path is littered with skeletons. Of course, there are those databases that are “perfect” from the start and never made any mistakes but is anyone talking about them today? Even Postgres gets it wrong sometimes.
- ht85 6y ago
  > Even Postgres gets it wrong sometimes Imagining a timeline where people would say that about MongoDB is a good way to assess the project's quality...
- pritambaral 6y ago
  MongoDB Inc. is still in the business of lying to its users through its teeth: https://news.ycombinator.com/item?id=23499658 https://news.ycombinator.com/item?id=23499658 And that's just a publicly available example. I have a client who paid for a MongoDB Inc. to send an "expert" down to assess the viability of a project, who flat out said the project can't be done and left it there; a week later the official MongoDB Inc. report says "We can definitely get it done. Why don't you move to our managed MongoDB Atlas service? That'll be $10K." For the record, my professional assessment was also that it'd be impossible to do it on a data model like Mongo's. ---- > Of course, there are those databases that are “perfect” from the start and never made any mistakes but is anyone talking about them today? Even Postgres gets it wrong sometimes. 1. The snark isn't helping your cause. 2. Then there are databases that claim to be "perfect" from the start, having always put up a facade without every admitting any of their own flaws. Like MongoDB. The thing MongoDB does best — though not something a DBMS can be judged by — is marketing. Not just the marketing they push themselves — "MongoDB is web scale!", "90% of RDBMS use can be replaced by MongoDB!" — but also the marketing it can get its fans to push.

surajs 6y ago

Hugh mongo... Sorry wrong website

slyall 6y ago

The "Mongo DB is Web Scale" video just turned 10 years old. I'm pretty sure that was a big factor in MongoDB not being taken seriously by many people. https://www.youtube.com/watch?v=b2F-DItXtZs https://www.youtube.com/watch?v=b2F-DItXtZs

gramakri 6y ago
Ah good memories. Such gems. "relation dbs have impotence mismatch" "does /dev/null support sharding" "redis will kick memcache's ass"
threeseed 6y ago
Anybody who makes complex technology decisions based on marketing copy doesn't deserve to be taken seriously either. Not that I think these people actually exist other than in the minds of many HN commenters. Oracle on their website right now says "we lead the market in autonomous, cloud, and applications technologies". I assume you think developers are going to suddenly abandon AWS, Python etc and move entirely to an Oracle stack based off this quote ?
- blibble 6y ago
  at large firms the clueless technology managment often buy based on the marketing crap, then force it down the throats of the engineers at my firm we're being all but forced to use Azure even though it costs more and makes absolutely no sense whatsoever for the domain, but since it's the "technology strategy" fighting it becomes exceptionally difficult
  - jd_mongodb 6y ago
    In seven years working at MongoDB the one thing I have learned is technology is never "forced down the throat of the engineers". Developers have choices and would not stay in an organisation that made decisions that way. The reason developer relations exists is the acknowledgement that developers ARE the decision makers in most technology selection.

chrisfosterelli 6y ago

MongoDB still has an awful reputation on Hacker News but I really appreciate the take from "Why RethinkDB Failed" [0]: > People wanted RethinkDB to be fast on workloads they actually tried, rather than “real world” workloads we suggested. For example, they’d write quick scripts to measure how long it takes to insert ten thousand documents without ever reading them back. MongoDB mastered these workloads brilliantly, while we fought the losing battle of educating the market. > almost everyone was asking “how is RethinkDB different from MongoDB?” We worked hard to explain why correctness, simplicity, and consistency are important, but ultimately these weren’t the metrics of goodness that mattered to most users. > But over time I learned to appreciate the wisdom of the crowds. MongoDB turned regular developers into heroes when people needed it, not years after the fact. It made data storage fast, and let people ship products quickly. And over time, MongoDB grew up. One by one, they fixed the issues with the architecture, and now it is an excellent product. It may not be as beautiful as we would have wanted, but it does the job, and it does it well. In my mind Mongo is a database that had great developer experience, excellent marketing, and some seriously bad technical gotchas. But marketing drove momentum long enough to cover bills, grab the market, and address most of the gotchas, so now it's a decent DB. [0]: https://www.defmacro.org/2017/01/18/why-rethinkdb-failed.html https://www.defmacro.org/2017/01/18/why-rethinkdb-failed.htm...

kvn_95 6y ago
It also helps that the creator of the default storage engine (WiredTiger) are Keith Bostic of BerkeleyDB fame [0] and Michael Cahill, whose PhD thesis on serializable snapshot isolation [1] formed the basis of Postgres concurrency control [2]. Notably, both of them still work for MongoDB. [0] https://en.wikipedia.org/wiki/Keith_Bostic https://en.wikipedia.org/wiki/Keith_Bostic [1] https://dl.acm.org/doi/10.1145/1376616.1376690 https://dl.acm.org/doi/10.1145/1376616.1376690 [2] https://wiki.postgresql.org/wiki/SSI https://wiki.postgresql.org/wiki/SSI
jaysonqpt 6y ago
I think MongoDB 3.6 is when it became a "decent" DB. Azure CosmosDB provides protocol level for MongoDB 3.6. This offers developers a neat way of using the power of distributed CosmosDB without sacrificing cloud portability.

mattbillenstein 6y ago

Mongo is much maligned here and I hesitate to even comment for fear of attack, but in my mind it has some compelling use cases and after Wired Tiger became the default storage engine, that pretty much solved the issues with compaction I had seen in the past while delivering a lot more performance. I've built systems with it where we didn't own the schema - we were scraping data from other places and schemaless was a feature. And I benchmarked it against Postgres and a couple other things and I just couldn't get the same performance - note our operations were idempotent to the db, so even in a hard crash, we could just re-run the scraping job and we wouldn't really "lose" any data -- or even if the data was stale by a day, not a big deal... That system would do tens of millions of upserts per night on not crazy AWS hardware and it ran for years like this without problems. Would I use mongo for situations where I needed transactions? Almost never - I actually like Postgres a lot and it's my default for your run of the mill CRUD apps since you can do geo, crypto, search, etc by just installing a few extensions. Do I got on HN on every mongo article and bash them constantly? No, I think they've built a pretty decent thing if you understand the implications of not confirming writes to replicas and whatnot and tune it to your needs.