4 ms·

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

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.
  - fiedzia 6y ago
    I think the core issue here is not the quality of marketing , but simply the fact that it exists. People need some database, and nobody is spending money on advertising Postgres, so they don't know anything about it. Also Mongo wins by a large margin on "how little you need to know to get started" with any relational db.
conradfr 6y ago
I interviewed recently at a payment provider that is rewriting its PHP/Mysql monolith in Java & go microservices with MongoDb. The architect would praise static typing but would prefer MongoDb "because it's easier to add a column". It felt weird but I've never used MongoDb so I could not really argue about it.
- manigandham 6y ago
  Sounds like a bad architect or someone who only knows surface features and doesn't have experience with the actual databases. Adding a column is not hard in any relational database, and pretty much all modern ones support no-downtime transactional schema updates with backfills, concurrent index builds, etc. Also the schema always exists somewhere, and it's usually to put it in the database so it's next to (and validates) your data rather than keeping spread out in your application code.
  - threeseed 6y ago
    Database schemas only validate the data type and whether it's null or not. It's next to useless for ensuring data integrity and why every app you see will have data validation inside the code itself. Whether it's checking that an email has a valid structure or that a payment is not negative. Majority of the logic will be the code so it makes no sense to me other than if you have multiple clients accessing that database why it must be enforced at the database level as well.
    - RedShift1 6y ago
      The examples you give are perfectly possible in any decent SQL server (mssql, postgres). If anything, database servers are made to ensure data consistency, checks like "payment not negative" are no brainers. If you don't define these constraints at the database level you are leaving its power on the table and are re-inventing the wheel by putting it in your application layer somewhere.
    - zaphirplane 6y ago
      In companies with DBAs the constrains are baked into the DB, in places without DBAs (or weak DBAs dev relation) that is absorbed into the code. To be fair depending on the culture of the company it maybe easier to put in code and update it there than to wait to have it approved, discussed and scheduled by the DBA
deleted 6y ago
[deleted]

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.
- fiedzia 6y ago
  I think the core issue here is not the quality of marketing , but simply the fact that it exists. People need some database, and nobody is spending money on advertising Postgres, so they don't know anything about it. Also Mongo wins by a large margin on "how little you need to know to get started" with any relational db.

conradfr 6y ago

I interviewed recently at a payment provider that is rewriting its PHP/Mysql monolith in Java & go microservices with MongoDb. The architect would praise static typing but would prefer MongoDb "because it's easier to add a column". It felt weird but I've never used MongoDb so I could not really argue about it.

manigandham 6y ago
Sounds like a bad architect or someone who only knows surface features and doesn't have experience with the actual databases. Adding a column is not hard in any relational database, and pretty much all modern ones support no-downtime transactional schema updates with backfills, concurrent index builds, etc. Also the schema always exists somewhere, and it's usually to put it in the database so it's next to (and validates) your data rather than keeping spread out in your application code.
- threeseed 6y ago
  Database schemas only validate the data type and whether it's null or not. It's next to useless for ensuring data integrity and why every app you see will have data validation inside the code itself. Whether it's checking that an email has a valid structure or that a payment is not negative. Majority of the logic will be the code so it makes no sense to me other than if you have multiple clients accessing that database why it must be enforced at the database level as well.
  - RedShift1 6y ago
    The examples you give are perfectly possible in any decent SQL server (mssql, postgres). If anything, database servers are made to ensure data consistency, checks like "payment not negative" are no brainers. If you don't define these constraints at the database level you are leaving its power on the table and are re-inventing the wheel by putting it in your application layer somewhere.
  - zaphirplane 6y ago
    In companies with DBAs the constrains are baked into the DB, in places without DBAs (or weak DBAs dev relation) that is absorbed into the code. To be fair depending on the culture of the company it maybe easier to put in code and update it there than to wait to have it approved, discussed and scheduled by the DBA

deleted 6y ago

[deleted]