9 ms·

A contrary anectdotal exemple. We use MongoDB where I work and the only justification is it was the new fad at the time. Now it bites us because we use it as a

A contrary anectdotal exemple. We use MongoDB where I work and the only justification is it was the new fad at the time. Now it bites us because we use it as a relational DB. PostgreSQL would’ve been much more suitable in our case but it wasn’t in vogue.

Traubenfuchs 4y ago
Is there any regret in technology selection more widespread and common than having picked MongoDB during its bizarre new hotness phase? That phase where SQL database administrators where crying, thinking they'd lose their jobs tomorrow and many people claimed SQL was now absolutely deprecated.
- hot_gril 4y ago
  This was probably the worst. Fads in business logic code or even APIs don't have anywhere near the lasting impact of a fad in screwing up the least easily replaceable part of your system, the DB.
- edgyquant 4y ago
  In my experience the sql guys were laughing because they knew mongo was a fad and not an actual replacement.
- CSMastermind 4y ago
  In the last 20 or so years I can't think of one. I've migrated 4 different companies off of Mongo to Postgres and it's a huge project each time.
  - hot_gril 4y ago
    Probably nearly a full code rewrite, right? My job the past 4 years has essentially been to clean up from bad DB decisions.
- CoolGuySteve 4y ago
  I think using language-provided async calls everywhere will be the next mistake. Instead of callback hell, you get callback hell along with weird async race conditions and a contagion of async functions.
  - hot_gril 4y ago
    I find async calls totally sensible in a lot of web frontends and backends. The alternative is explicit threading models, which are overly pedantic in a wide variety of use cases.
- mattgreenrocks 4y ago
  The fact that MongoDB hype could reach the level it did is an indictment of tech culture. Why was people's excitement allowed to trump data integrity? Are there not enough adults in the room to stop this from happening again?
madsbuch 4y ago
This seems to be a failure outside of fads. This is application of an unviable technology. Filesystems has been available for much longer than MongoDB. Using that as a database and having requirements changed to a relational database would be the same without anything about the filesystem being a fad.
- the_only_law 4y ago
  Yet for some reason I never hear about people complaining that some idiot chose a file system to be the database for their application . I do hear quite often, disdain for the choice of MongoDB.
  - madsbuch 4y ago
    That's on you, it happens quite often :)
    - dragontamer 4y ago
      I think most people know that filesystems make for poor databases. However, most people don't seem to realize that Excel spreadsheets are rather poor databases... they're the _real_ issue.
      - dsr_ 4y ago
        There are lots of situations where filesystems are good databases. The problem is that relational databases are flexible in ways that filesystems are not, so when your requirements change, a relational database is likely to be able to support the change whereas the filesystem may not. Excel spreadsheets are terrible as databases and are also terrible as a file format for sending database records.
        dragontamer 4y ago
        Filesystems already fail at step#1 of a database, which is concurrent read / concurrent writes. Its pretty obscure and arcane for the rules of read/write ordering on Linux/Windows systems and filesystems. You've got FILE* fwrites interacting with mmap regions, and locks don't exactly do what you think in Linux. In both Linux / Windows, you end up needing to create a Filesystem mutex of some kind (Linux flock, Windows Mutex). Then, and only then, is it really safe to read or write to a file.
nisegami 4y ago
That's just plain old using the wrong tool for the wrong job. Although, I suppose that part of the rise of any new tool will be trying to figure out which for which jobs it is the right tool, and sometimes the failure cases might live longer than expected.
- mrguyorama 4y ago
  The fad was "MongoDB is a tool that everyone has a job for" and it doesn't matter that I always knew that was a stupid take because I don't sign the purchase orders and if a manager listens to someone who makes way less than they do they feel less important.
pmarreck 4y ago
This could also be a case of developers not pressing hard enough back on technically-less-competent manager-driven architectural decisions
hot_gril 4y ago
NoSQL fad was the most destructive I can think of. Those had their place as niche tools, but they somehow became the default for a while. Once you pick the wrong DBMS, you're building on quicksand.
- satvikpendem 4y ago
  But, MongoDB is web-scale: https://www.youtube.com/watch?v=b2F-DItXtZs https://www.youtube.com/watch?v=b2F-DItXtZs
  - hot_gril 4y ago
    I heard Snapchat uses it to support their web-scale disappearing photos, cause it erases your data randomly
- stcroixx 4y ago
  Vendor lock in cloud fad is going to end badly. Kubernetes outside FAANG has potential to get bad.
- dathinab 4y ago
  I have come to realize why. SQL has a problem, less of technical nature but more of organizational/knowledge transfer nature. I have spent way to much time in discussions about schema, SQL types, SQL library usage and anything ORMs. Also a lot of hidden gotchas, like A LOT. Through most aren't really hidden it's more like people somehow having major knowledge gaps without realizing it. Like not understanding isolation levels and therefor misunderstanding which guarantees a transaction provides. Or somehow fundamentally rejecting that you design an application with a specific transaction level in mind and changing it later is non trivial, potentially to a point of making the change infeasible. Or pointless discussions about integer sizing and signing and the docent different ways you could map a unsiged 16bit number to SQL. Or people not understanding row/column locks. Or getting bitten by upserts not allowing upserting the same (compound)key twice in the same statement in some dbs. Or ... Well I'm kinda feed up. But I still had way worse experiences with Mongo (but that was ~8? years ago).

Traubenfuchs 4y ago

Is there any regret in technology selection more widespread and common than having picked MongoDB during its bizarre new hotness phase? That phase where SQL database administrators where crying, thinking they'd lose their jobs tomorrow and many people claimed SQL was now absolutely deprecated.

hot_gril 4y ago
This was probably the worst. Fads in business logic code or even APIs don't have anywhere near the lasting impact of a fad in screwing up the least easily replaceable part of your system, the DB.
edgyquant 4y ago
In my experience the sql guys were laughing because they knew mongo was a fad and not an actual replacement.
CSMastermind 4y ago
In the last 20 or so years I can't think of one. I've migrated 4 different companies off of Mongo to Postgres and it's a huge project each time.
- hot_gril 4y ago
  Probably nearly a full code rewrite, right? My job the past 4 years has essentially been to clean up from bad DB decisions.
CoolGuySteve 4y ago
I think using language-provided async calls everywhere will be the next mistake. Instead of callback hell, you get callback hell along with weird async race conditions and a contagion of async functions.
- hot_gril 4y ago
  I find async calls totally sensible in a lot of web frontends and backends. The alternative is explicit threading models, which are overly pedantic in a wide variety of use cases.
mattgreenrocks 4y ago
The fact that MongoDB hype could reach the level it did is an indictment of tech culture. Why was people's excitement allowed to trump data integrity? Are there not enough adults in the room to stop this from happening again?

madsbuch 4y ago

This seems to be a failure outside of fads. This is application of an unviable technology. Filesystems has been available for much longer than MongoDB. Using that as a database and having requirements changed to a relational database would be the same without anything about the filesystem being a fad.

the_only_law 4y ago
Yet for some reason I never hear about people complaining that some idiot chose a file system to be the database for their application . I do hear quite often, disdain for the choice of MongoDB.
- madsbuch 4y ago
  That's on you, it happens quite often :)
  - dragontamer 4y ago
    I think most people know that filesystems make for poor databases. However, most people don't seem to realize that Excel spreadsheets are rather poor databases... they're the _real_ issue.
    - dsr_ 4y ago
      There are lots of situations where filesystems are good databases. The problem is that relational databases are flexible in ways that filesystems are not, so when your requirements change, a relational database is likely to be able to support the change whereas the filesystem may not. Excel spreadsheets are terrible as databases and are also terrible as a file format for sending database records.
      - dragontamer 4y ago
        Filesystems already fail at step#1 of a database, which is concurrent read / concurrent writes. Its pretty obscure and arcane for the rules of read/write ordering on Linux/Windows systems and filesystems. You've got FILE* fwrites interacting with mmap regions, and locks don't exactly do what you think in Linux. In both Linux / Windows, you end up needing to create a Filesystem mutex of some kind (Linux flock, Windows Mutex). Then, and only then, is it really safe to read or write to a file.

nisegami 4y ago

That's just plain old using the wrong tool for the wrong job. Although, I suppose that part of the rise of any new tool will be trying to figure out which for which jobs it is the right tool, and sometimes the failure cases might live longer than expected.

mrguyorama 4y ago
The fad was "MongoDB is a tool that everyone has a job for" and it doesn't matter that I always knew that was a stupid take because I don't sign the purchase orders and if a manager listens to someone who makes way less than they do they feel less important.

pmarreck 4y ago

This could also be a case of developers not pressing hard enough back on technically-less-competent manager-driven architectural decisions

hot_gril 4y ago

NoSQL fad was the most destructive I can think of. Those had their place as niche tools, but they somehow became the default for a while. Once you pick the wrong DBMS, you're building on quicksand.

satvikpendem 4y ago
But, MongoDB is web-scale: https://www.youtube.com/watch?v=b2F-DItXtZs https://www.youtube.com/watch?v=b2F-DItXtZs
- hot_gril 4y ago
  I heard Snapchat uses it to support their web-scale disappearing photos, cause it erases your data randomly
stcroixx 4y ago
Vendor lock in cloud fad is going to end badly. Kubernetes outside FAANG has potential to get bad.
dathinab 4y ago
I have come to realize why. SQL has a problem, less of technical nature but more of organizational/knowledge transfer nature. I have spent way to much time in discussions about schema, SQL types, SQL library usage and anything ORMs. Also a lot of hidden gotchas, like A LOT. Through most aren't really hidden it's more like people somehow having major knowledge gaps without realizing it. Like not understanding isolation levels and therefor misunderstanding which guarantees a transaction provides. Or somehow fundamentally rejecting that you design an application with a specific transaction level in mind and changing it later is non trivial, potentially to a point of making the change infeasible. Or pointless discussions about integer sizing and signing and the docent different ways you could map a unsiged 16bit number to SQL. Or people not understanding row/column locks. Or getting bitten by upserts not allowing upserting the same (compound)key twice in the same statement in some dbs. Or ... Well I'm kinda feed up. But I still had way worse experiences with Mongo (but that was ~8? years ago).