MongoDB is a 12 year old database. And yet people are still using this disparaging argument that anyone that chooses it is doing so for their resume and not because it meets their needs in any way.
But by all means replace your production system with MangoDB which is unsupported, significantly slower, has no built-in HA/clustering and written in Go which is a GC language.
Would you please not post in the flamewar style to HN? You have a long history of doing this, and I have the impression that it got better in the last few years (yay! thanks), but I also have the impression that you've been relapsing recently (boo, please don't). You can make your substantive points respectfully and without snark, and we'd be very grateful if you'd stick to that.
It's crazy how this "flamewar" perspective has changed on HN about Mongo DB in the last 10 years. It used to be that any comment critical of MongoDB would get a warning. Now it's any comment supportive of it!
Hm, well, I never said that ANYONE who uses MongoDB is guilty of resume driven development. I specifically only indicated the ones that WERE chosen via resume driven development. Unless you were replying to the wrong comment?
I think it's disparaging to use the term resume driven development as though there is a large class of developers who are actively trying to harm projects by selecting inappropriate technologies.
I've worked with thousands of developers over the last 20+ years and never seen anyone do this.
Huh, so if we are trotting out experience credentials, I have also worked with thousands of developers (I guess?) over the last ~20 years as well. My first programming language was Apple BASIC on an Apple II, and I haven't stopped learning since!
I think we use this term differently, perhaps? This term is not intended to be an attack, but rather just an acknowledgment of a common type of technical debt that results from people getting influenced by marketing teams and choosing tech based on how "trendy" it seems. Sometimes this might be done explicitly since they are intending to jump ship anyway... I've had conversations at the bar out of earshot of "the suits" where this exact topic was discussed! Most of the time it's not intentional or explicit, but just novice engineers directed by poor management to greenfield apps, and then falling for marketing claims and choosing based on how "trendy" the marketing claims it is vs real, observed needs. MongoDB is still getting taught at many bootcamps and coding curriculums as an "SQL, but better for beginners since you don't need that annoying schema thing!"
Yeah, I think the person we are replying to is taking this a lot more negatively than I intended. I always sort of thought it was kind of an "open secret" that this stuff went on, at least here in SV / Bay Area. Perhaps elsewhere, where engineers don't hop around jobs every year or two, this sounds more like an insult or accusation?
Allow me to doubt that you have deep insight into the motivations of thousands of people that have all selected MongoDB for their projects. This seems unlikely for several reasons, if nothing else because of Dunbar's number.
There are thousands of projects where MongoDB was selected precisely because it was a new-shiny No SQL thingy.
For some of these things, it may have been the right thing. For most of them, it was a chance to play with new technologies. I have seen multiple commercial projects where MongoDB was chosen by the developers with _no_ oversight by management (I have killed a couple of those projects, too, because MongoDB was always the wrong technology).
The original comment about the number of projects where MongoDB was chosen under résumé-driven-development is absolutely correct. That doesn’t make it _bad_; how _else_ is one supposed to get experience with new technologies than to try something new? (Sticking with Mongo after multiple data-loss incidents due to the “architecture” of Mongo, on the other hand…)
> Be kind. Don't be snarky. Have curious conversation; don't cross-examine. Please don't fulminate. Please don't sneer, including at the rest of the community.
Note MangoDB is a stateless proxy as such you can use it with any PostgreSQL setup. For example you should be able to use it with Amazon Aurora PostgreSQL as backend which has HA built in
Which is the same proxy on top of PostgreSQL if I remember correctly. :) But MangoDB is cloud-agnostic. I imagine it has the same limitations as DocumentDB or more.
I agree either stay with mongodb or if you really want to migrate then just switch to Postgres by obviously exporting the data and putting it into Postgres
But by all means replace your production system with MangoDB which is unsupported, significantly slower, has no built-in HA/clustering and written in Go which is a GC language.