5 ms·

No one ever got fired for choosing Postgres, but I know plenty of people who were out on their ass when they built a client's application using MongoDB and then

No one ever got fired for choosing Postgres, but I know plenty of people who were out on their ass when they built a client's application using MongoDB and then as it matured it became too cumbersome for some of the more esoteric features a client needed.

petepete 8y ago
I once undertook a contract at a place that opted for MongoDB based purely on 'speed' and then effectivity used it to build a relational database once they realised the need to apply different permissions to different parts of a document. Some hilarious bugs included a "relationships" collection that stored a record's identifier and an array of all the other documents it was related to. It was intended to be used for "joins" (yeah, I know). As the system grew and some customers created tens of thousands of records, all of which belonged to them so were represented in this collection. Eventually, the max array size in MongoDB was hit, which failed silently, rendering all of the data worthless. I spent much of my time creating a roadmap for them to migrate to PostgreSQL. I'm not blaming MongoDB here, it was just the wrong tool for that job. But some companies ate up through marketing material and thought it was the solution to all their problems.
- yoz-y 8y ago
  We fell into same pattern. I do not know why MongoDB was used for the project I am currently maintaining, but to me it seems that it is a bad idea to use a relation-less database for inherently related data. I think that the original thinking was along the lines "well, we do not know what structure the data will have yet"
- rbanffy 8y ago
  > I'm not blaming MongoDB here Failing silently is almost never the right thing to do.
  - petepete 8y ago
    Like I said in another thread, as I remember Perl's MongoDB driver used to default WriteConcernResult to false, essentially making it assume that everything was successful. It's been years since I touched it so my memory is a little hazy.
- dmichulke 8y ago
  > which failed silently, rendering all of the data worthless. I am not in any way related to mongodb, nor do I really like it. That being said, I can't image they failed silently. Much more likely that some return code from an insert was ignored in the application. Otherwise that would be just the mother of all errors of DB development. However, I do recall many questionable things like: - Some sort of fast but in the worst-case inconsistent default config - In order to execute the command to free space (which you had to do regularly) you'd need to have lots of free space Both issues are probably 5 years old, so I also don't remember any details. Migrated to postgres a year later or so.
  - petepete 8y ago
    That contract took place in 2011. As I recall the Perl MongoDB driver had a setting called WriteConcernResult that used to default to false. That meant that it operated in 'fire and forget' mode and assumed that everything worked. It was one of the main reasons it was so fast! I think over the years the defaults have improved and favour safety over speed.
- borplk 8y ago
  I've seen my fair share of MongoDB dumpster fire codebases as well and one thing that makes it so much worse is it's almost always MongoDB + noob developers who picked MongoDB because a blog post told them it's all cool and it's a part of a "hip stack". That's the deadly combination. If it was MongoDB + experienced developers who picked it out of careful consideration things would be different. But you never see that because experienced developers are smart enough to pick Postgres instead.

petepete 8y ago

I once undertook a contract at a place that opted for MongoDB based purely on 'speed' and then effectivity used it to build a relational database once they realised the need to apply different permissions to different parts of a document. Some hilarious bugs included a "relationships" collection that stored a record's identifier and an array of all the other documents it was related to. It was intended to be used for "joins" (yeah, I know). As the system grew and some customers created tens of thousands of records, all of which belonged to them so were represented in this collection. Eventually, the max array size in MongoDB was hit, which failed silently, rendering all of the data worthless. I spent much of my time creating a roadmap for them to migrate to PostgreSQL. I'm not blaming MongoDB here, it was just the wrong tool for that job. But some companies ate up through marketing material and thought it was the solution to all their problems.

yoz-y 8y ago
We fell into same pattern. I do not know why MongoDB was used for the project I am currently maintaining, but to me it seems that it is a bad idea to use a relation-less database for inherently related data. I think that the original thinking was along the lines "well, we do not know what structure the data will have yet"
rbanffy 8y ago
> I'm not blaming MongoDB here Failing silently is almost never the right thing to do.
- petepete 8y ago
  Like I said in another thread, as I remember Perl's MongoDB driver used to default WriteConcernResult to false, essentially making it assume that everything was successful. It's been years since I touched it so my memory is a little hazy.
dmichulke 8y ago
> which failed silently, rendering all of the data worthless. I am not in any way related to mongodb, nor do I really like it. That being said, I can't image they failed silently. Much more likely that some return code from an insert was ignored in the application. Otherwise that would be just the mother of all errors of DB development. However, I do recall many questionable things like: - Some sort of fast but in the worst-case inconsistent default config - In order to execute the command to free space (which you had to do regularly) you'd need to have lots of free space Both issues are probably 5 years old, so I also don't remember any details. Migrated to postgres a year later or so.
- petepete 8y ago
  That contract took place in 2011. As I recall the Perl MongoDB driver had a setting called WriteConcernResult that used to default to false. That meant that it operated in 'fire and forget' mode and assumed that everything worked. It was one of the main reasons it was so fast! I think over the years the defaults have improved and favour safety over speed.
borplk 8y ago
I've seen my fair share of MongoDB dumpster fire codebases as well and one thing that makes it so much worse is it's almost always MongoDB + noob developers who picked MongoDB because a blog post told them it's all cool and it's a part of a "hip stack". That's the deadly combination. If it was MongoDB + experienced developers who picked it out of careful consideration things would be different. But you never see that because experienced developers are smart enough to pick Postgres instead.