4 ms·

Mongo FUD has more to do with the fact that RDS...es work better with almost any line of business application. The ONLY application I have ever seen Mongo, or a

Mongo FUD has more to do with the fact that RDS...es work better with almost any line of business application. The ONLY application I have ever seen Mongo, or any other key:document store work well is integrating with form.io for custom forms. And even then, RDS might have been a better choice.

rglover 4y ago
Work better in what way? Speed? Reliability? Scalability? And is that based on direct experience or indirect?
- cynusx 4y ago
  Simple operations like joining data together or filtering a table for a specific value are way more performant. They are also extremely common operations. Mongodb became obsolete when postgresql added the json column type.
- throw1234651234 4y ago
  Extensive experience with the lower-end (in terms of revenue) Fortune 1000 companies. Every single cloud and MongoDB pushes horizontal scaling and sharding. This rarely a necessity in practice. Traditional RDS normalization is almost always necessary to keep clean data. As I said, I have used MongoDB extensively for non-normalized, client created forms, and it was fine for that, but I wouldn't do it again given the choice now. In more simple terms - when I work for a staffing agency and delete a profession from the database, I want the DB to yell at me about FK constraints that needs to be considered (e.g. millions of jobs and candidates set to that profession_id)
redwood 4y ago
Sorry but "any other key:document store" seems to imply that you're not aware of the value of consistent secondary indexes: a lot of people are not aware and conflate K/V stores which are fundamentally inflexible with more general purpose alternatives like Postgres and MongoDB: frankly these two are both able to express a wide variety of modern needs and whether you prefer one versus the other is a question of tradeoffs. The world is no as reductive as you imply
- robertlagrant 4y ago
  MongoDB isn't a general purpose alternative. You're right that there are tradeoffs, but relational databases are the general purpose "good at everything" engines. MongoDB is amazing at some things, but worse at others. Indexes can help, but - as with any index - don't always help. Some performance characteristics are more structural than that, which is why document databases exist.
  - redwood 4y ago
    I struggle to understand how relational isn't a subset of documents (namely flat documents): what am I missing?
    - robertlagrant 4y ago
      I'm no expert but my understanding is that a lot of these specialised databases' strengths and weaknesses come from laying the data out on disk differently to how a relational database would. A relational database saves data by table, and within each table by row. This means it's very good at getting a row of data out of a table, and pretty good at column operations (e.g. sum the "price" column in this list) and pretty good at joining data (e.g. "fetch me related data from these other tables"). A document database such as MongoDB saves all the data per-key together, so it doesn't have to do work to relate data. It just reads and returns it. That means it's exceptional at getting related data (as long as you saved all the related data in one document), but terrible at joining to other documents by field, and terrible at column operations across documents (e.g. "sum the price of these books, where each book is a different document"). A columnar database is amazing at column-oriented operations (e.g. "compress this data" or "sum this column", but bad at getting all the data for one record, as it has to traverse all the columns to find the right data, and therefore bad at relating data, as it has to do column traversal across multiple tables. A graph database is amazing at getting related tables or entities (e.g. "I'm a person, now through a self-referential edge back to the Person node get me all my friends of friends of friends"). I can't think off the top of my head what that would be bad at, but perhaps it's bad at summing columns, that sort of thing. Again: I'm no expert. That's just my understanding.
neuronexmachina 4y ago
Anecdotally, I've been at several companies where MongoDB was a crucial part of a tech stack due to early tech decisions. In every case, most of the engineers working with it wished there was a reasonable way to migrate away from MongoDB to PostgreSQL. I've never seen the opposite (engineers wanting to transition from SQL to MongoDB).
lmm 4y ago
> Mongo FUD has more to do with the fact that RDS...es work better with almost any line of business application. Nope. That's simply not true, and it has nothing to do with why people dislike MongoDB (you don't see similar attacks on Cassandra for example). The issue is that it has a lot of cases of data loss especially in its default configuration, and that's not a document database problem, it's a MongoDB problem. (Indeed it's very similar to the reputation that MySQL used to enjoy, for those of us who can remember back that far).

rglover 4y ago

Work better in what way? Speed? Reliability? Scalability? And is that based on direct experience or indirect?

cynusx 4y ago
Simple operations like joining data together or filtering a table for a specific value are way more performant. They are also extremely common operations. Mongodb became obsolete when postgresql added the json column type.
throw1234651234 4y ago
Extensive experience with the lower-end (in terms of revenue) Fortune 1000 companies. Every single cloud and MongoDB pushes horizontal scaling and sharding. This rarely a necessity in practice. Traditional RDS normalization is almost always necessary to keep clean data. As I said, I have used MongoDB extensively for non-normalized, client created forms, and it was fine for that, but I wouldn't do it again given the choice now. In more simple terms - when I work for a staffing agency and delete a profession from the database, I want the DB to yell at me about FK constraints that needs to be considered (e.g. millions of jobs and candidates set to that profession_id)

redwood 4y ago

Sorry but "any other key:document store" seems to imply that you're not aware of the value of consistent secondary indexes: a lot of people are not aware and conflate K/V stores which are fundamentally inflexible with more general purpose alternatives like Postgres and MongoDB: frankly these two are both able to express a wide variety of modern needs and whether you prefer one versus the other is a question of tradeoffs. The world is no as reductive as you imply

robertlagrant 4y ago
MongoDB isn't a general purpose alternative. You're right that there are tradeoffs, but relational databases are the general purpose "good at everything" engines. MongoDB is amazing at some things, but worse at others. Indexes can help, but - as with any index - don't always help. Some performance characteristics are more structural than that, which is why document databases exist.
- redwood 4y ago
  I struggle to understand how relational isn't a subset of documents (namely flat documents): what am I missing?
  - robertlagrant 4y ago
    I'm no expert but my understanding is that a lot of these specialised databases' strengths and weaknesses come from laying the data out on disk differently to how a relational database would. A relational database saves data by table, and within each table by row. This means it's very good at getting a row of data out of a table, and pretty good at column operations (e.g. sum the "price" column in this list) and pretty good at joining data (e.g. "fetch me related data from these other tables"). A document database such as MongoDB saves all the data per-key together, so it doesn't have to do work to relate data. It just reads and returns it. That means it's exceptional at getting related data (as long as you saved all the related data in one document), but terrible at joining to other documents by field, and terrible at column operations across documents (e.g. "sum the price of these books, where each book is a different document"). A columnar database is amazing at column-oriented operations (e.g. "compress this data" or "sum this column", but bad at getting all the data for one record, as it has to traverse all the columns to find the right data, and therefore bad at relating data, as it has to do column traversal across multiple tables. A graph database is amazing at getting related tables or entities (e.g. "I'm a person, now through a self-referential edge back to the Person node get me all my friends of friends of friends"). I can't think off the top of my head what that would be bad at, but perhaps it's bad at summing columns, that sort of thing. Again: I'm no expert. That's just my understanding.

neuronexmachina 4y ago

Anecdotally, I've been at several companies where MongoDB was a crucial part of a tech stack due to early tech decisions. In every case, most of the engineers working with it wished there was a reasonable way to migrate away from MongoDB to PostgreSQL. I've never seen the opposite (engineers wanting to transition from SQL to MongoDB).

lmm 4y ago

> Mongo FUD has more to do with the fact that RDS...es work better with almost any line of business application. Nope. That's simply not true, and it has nothing to do with why people dislike MongoDB (you don't see similar attacks on Cassandra for example). The issue is that it has a lot of cases of data loss especially in its default configuration, and that's not a document database problem, it's a MongoDB problem. (Indeed it's very similar to the reputation that MySQL used to enjoy, for those of us who can remember back that far).