14 ms·

Yeah, I could imagine this being a useful step to migrate away from MongoDB. I suspect there are plenty of "resume-driven development" MongoDB installations out

Yeah, I could imagine this being a useful step to migrate away from MongoDB. I suspect there are plenty of "resume-driven development" MongoDB installations out there that could use something like this.

threeseed 5y ago
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.
- zitterbewegung 5y ago
  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
- michaelpb 5y ago
  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?
  - threeseed 5y ago
    No I am replying to the right 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.
    - mapcars 5y ago
      Since you haven't seen it means it doesn't happen? Sad that 20+ years didn't teach you basics of logic.
      - ryanianian 5y ago
        From the HN guidelines: > 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.
    - marginalia_nu 5y ago
      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.
      - threeseed 5y ago
        I don’t need to have deep insights. Developers almost always have to justify why they pick certain technologies. And given how old MongoDB is not sure how it benefits anyone’s resume.
        marginalia_nu 5y ago
        If you don't understand their motivations, how can you claim to know their motivations?
        rmdashrfstar 5y ago
        Welcome to HN, where nothing makes sense and sources don’t matter
        halostatue 5y ago
        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…)
- PeterZaitsev 5y ago
  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
  - threeseed 5y ago
    If you are using the cloud then you can just use DocumentDB.
    - kdasme 5y ago
      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.
    - PeterZaitsev 5y ago
      It depends. With MangoDB you can test on your laptop with PostgreSQL and deploy to Production to Aurora... or any other PostgreSQL compatible DBaaS.
    - kevinsundar 5y ago
      But then you have to use DocumentDB.
- deleted 5y ago
  [deleted]
- pulse7 5y ago
  "and written in Go which is a GC language" => Would it be better for you if it would be "written in JavaScript which is a GC language"?
- dang 5y ago
  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. https://news.ycombinator.com/newsguidelines.html https://news.ycombinator.com/newsguidelines.html
  - VWWHFSfQ 5y ago
    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!
    - dang 5y ago
      > It used to be that any comment critical of MongoDB would get a warning That can't possibly be true, or even close to true!
vosper 5y ago
> Yeah, I could imagine this being a useful step to migrate away from MongoDB. What is the state of the art in this area? I did a little PoC of moving data from Mongo to a new schema in Postgres with Hexo and DBT. It worked nicely, but it was only a PoC.
- michaelpb 5y ago
  Oh, I don't know about the state of the art, I was just speculating. I'd imagine this technique would only useful if you want to support a MongoDB app at the same time as building new features with Postgres, and then gradually phase out the MongoDB interface (e.g. gradually transitioning between a v1 prototype and a v2 rewrite) If it's not much data (eg ~100k or something), and you don't need any sort of gradual transition, then I'd do something really KISS like dump into a CSV or something and then re-import with whatever the new database management system has for importing files

threeseed 5y ago

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.

zitterbewegung 5y ago
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
michaelpb 5y ago
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?
- threeseed 5y ago
  No I am replying to the right 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.
  - mapcars 5y ago
    Since you haven't seen it means it doesn't happen? Sad that 20+ years didn't teach you basics of logic.
    - ryanianian 5y ago
      From the HN guidelines: > 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.
  - marginalia_nu 5y ago
    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.
    - threeseed 5y ago
      I don’t need to have deep insights. Developers almost always have to justify why they pick certain technologies. And given how old MongoDB is not sure how it benefits anyone’s resume.
      - marginalia_nu 5y ago
        If you don't understand their motivations, how can you claim to know their motivations?
        rmdashrfstar 5y ago
        Welcome to HN, where nothing makes sense and sources don’t matter
      - halostatue 5y ago
        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…)
PeterZaitsev 5y ago
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
- threeseed 5y ago
  If you are using the cloud then you can just use DocumentDB.
  - kdasme 5y ago
    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.
  - PeterZaitsev 5y ago
    It depends. With MangoDB you can test on your laptop with PostgreSQL and deploy to Production to Aurora... or any other PostgreSQL compatible DBaaS.
  - kevinsundar 5y ago
    But then you have to use DocumentDB.
deleted 5y ago
[deleted]
pulse7 5y ago
"and written in Go which is a GC language" => Would it be better for you if it would be "written in JavaScript which is a GC language"?
dang 5y ago
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. https://news.ycombinator.com/newsguidelines.html https://news.ycombinator.com/newsguidelines.html
- VWWHFSfQ 5y ago
  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!
  - dang 5y ago
    > It used to be that any comment critical of MongoDB would get a warning That can't possibly be true, or even close to true!

vosper 5y ago

> Yeah, I could imagine this being a useful step to migrate away from MongoDB. What is the state of the art in this area? I did a little PoC of moving data from Mongo to a new schema in Postgres with Hexo and DBT. It worked nicely, but it was only a PoC.

michaelpb 5y ago
Oh, I don't know about the state of the art, I was just speculating. I'd imagine this technique would only useful if you want to support a MongoDB app at the same time as building new features with Postgres, and then gradually phase out the MongoDB interface (e.g. gradually transitioning between a v1 prototype and a v2 rewrite) If it's not much data (eg ~100k or something), and you don't need any sort of gradual transition, then I'd do something really KISS like dump into a CSV or something and then re-import with whatever the new database management system has for importing files