Live data from Hacker News

MongoDB gets support for multi-document ACID transactions

techcrunch.com

101–110 of 245 posts

Re: MongoDB gets support for multi-document ACID transactions

#101

Earlier quoted context omitted.

I beg to differ. (Disclosure: I work for MongoDB.) Using JSON as your data model, rather than relational tables, lets you build different applications that don't need multi-document transactions as often, because the data is already together in a single document. But when you do need multi-document transactions (a small percentage of applications do, and only few use cases inside those applications), they are now ava…

Its usually only after a while you realize almost every piece of meaningful data is relational. It just didn't look that way when the project started. But now you're committed on the wrong database and its very costly to switch back to SQL. Literally every project I saw using MongoDB ended up going back to SQL within the first 2 years after realizing the data is indeed very much relational and theres no clean way to…

Video games storing player data are a great example of nonrelational data. I'm intending on writing a blog post after I finish my game detailing the structure of data I store and why it was so perfect for mongodb.

Re: MongoDB gets support for multi-document ACID transactions

#102
post #6

MongoDB has successfully played the 'hype first, features later' strategy. Now it is well on the way to being a decent swiss-army-knife database. The RethinkDB retrospective[0] contains a lot of insight into how MongoDB has succeeded despite being vastly inferior on a technical level back when it first launched. I have to admit them a certain respect for executing their strategy so successfully. Choice quote: Every t…

There is a trend I noticed where I work. Most people that “get it right” the first time around do not get any recognition whatsoever. It is the people that screw up, release with big flaws that the customer then pressures the company about, that are heralded as heroes and bacon savers when the fix those flaws. After 3 years and as many releases.

Reminds me of this old blog post: http://webchick.net/embrace-the-chaos

Re: MongoDB gets support for multi-document ACID transactions

#103
post #11
post #6

MongoDB has successfully played the 'hype first, features later' strategy. Now it is well on the way to being a decent swiss-army-knife database. The RethinkDB retrospective[0] contains a lot of insight into how MongoDB has succeeded despite being vastly inferior on a technical level back when it first launched. I have to admit them a certain respect for executing their strategy so successfully. Choice quote: Every t…

> MongoDB has successfully played the 'hype first, features later' strategy. Now it is well on the way to being a decent swiss-army-knife database. I have no idea how capable MongoDB is these days, as I haven't used Mongo in years (and even then it was not for long). However, I do not know any developers who, after living through the "hype first, features later" strategy, have been left with a positive enough opinion…

I don't know much about MongoDB. I am mostly a client-side developer after all.

But every time I see a team transitioning from Mongo to something else, they transition to a relational database. May be their problem is not with MongoDB, but that their data is relational after all?

Personally, I'd take a relational db over NoSQL for most of my needs, but all these stories don't really say anything about how Mongo compares to other NoSQL databases.

Re: MongoDB gets support for multi-document ACID transactions

#104
post #58

Earlier quoted context omitted.

On the other hand, PostgreSQL is a very good example of a successful implementation of the opposite strategy, that is, "correctness first". And since PostgreSQL fills that niche very well (correctness + real ACID + extensibility + decent performance), maybe it was really PostgreSQL who killed RethinkDB?

If you're playing the long game and not looking to make a profit that's fine, but PostgreSQL as a company would have been doomed a long time ago. You have to keep in mind the timelines of the business and what they need to do to keep the lights on. MongoDB has identified a real pain point: many developers don't like to use SQL to interface with a transactional database. I'm not going into the merits of SQL vs. NoSQL,…

There seems to be two points in this comment, one talking about the development of PostgreSQL and the other talking about the usability of it.

PostgreSQL remains one of the most mysteriously difficult common DBMSs to setup which is unfortunate, but since the advent of MongoDB they've adopted all the ease of use features that are warranted from it. Developing a quick-and-dirty product prototype on postgres is a breeze and bootstraping constraints and data-integrity to it afterwards is trivial. I am really not seeing any reason to start a new app on MongoDB exclusively at this point, start off in a strong DBMS like postgres and if you end up needing MongoDB-style document storage you can always branch to it later, but using it initially is a case of premature optimization, there is no need for it.

Re: MongoDB gets support for multi-document ACID transactions

#105
post #11
post #6

MongoDB has successfully played the 'hype first, features later' strategy. Now it is well on the way to being a decent swiss-army-knife database. The RethinkDB retrospective[0] contains a lot of insight into how MongoDB has succeeded despite being vastly inferior on a technical level back when it first launched. I have to admit them a certain respect for executing their strategy so successfully. Choice quote: Every t…

> MongoDB has successfully played the 'hype first, features later' strategy. Now it is well on the way to being a decent swiss-army-knife database. I have no idea how capable MongoDB is these days, as I haven't used Mongo in years (and even then it was not for long). However, I do not know any developers who, after living through the "hype first, features later" strategy, have been left with a positive enough opinion…

Yep this is me. I would require some pretty amazing reasons to even consider using Mongo again. Especially now all other relational databases i trust support json column types.

Re: MongoDB gets support for multi-document ACID transactions

#106

Earlier quoted context omitted.

PostgreSQL as a company: https://www.citusdata.com

There are several companies that are leveraging PostgreSQL for their own businesses, but that doesn't seem to me to be a rebuttal of the OP's assertion that PostgreSQL couldn't survive as a company itself. Citus Data is not "PostgreSQL as a company," it is "a company that exists because PostgreSQL already existed."

Well majority of key Postgres contributors work for 2ndQuadrant, EnterpriseDB, Crunchy Data, Citus etc. It basically means PostgreSQL is a distributed company and it would survive fine but being distributed it looks like it is able to innovate faster and is more resilient.

Re: MongoDB gets support for multi-document ACID transactions

#107

Most software developers have a negative impression of MongoDB, based on the many flaws that it had back in 2010. Among the people who did the best job of documenting those flaws, was Kyle Kingsbury, in his Jespen series: https://aphyr.com/posts/284-jepsen-mongodb But it is important to realize that the team at MongoDB has actually been working with Kingsbury, for several years now, and they have slowly and patiently…

Well...to the best of my knowledge the Mongo DB BI connector in 2018 is still Postgres: https://www.linkedin.com/pulse/mongodb-32-now-powered-postgr... Has this changed?

John radically overstates his case in that article based on incomplete information; note that none of the code he points to is even 1.0 code.

Nonetheless, it’s accurate enough to say that the 1.0 BI connector used Postgres code. It was definitely the fastest way to deliver it.

2.x was built from scratch, it uses no Postgres whatsoever.

Re: MongoDB gets support for multi-document ACID transactions

#109

Earlier quoted context omitted.

With all its problems, I built a MEAN (MongoDB, Express, Angular, Node) app from zero knowledge to production 2 years ago far faster than this React, Apollo, GraphQL, and Postgres app I'm building from zero knowledge.

Speed isn't always a great thing... If it takes you 2x faster to build but 10x extra support/maintenance after the fact and eventually you need to migrate to postgres anyway because of acid features and stability.. then the time/money loss > benefits. Build something the right way first, even if it does take longer though I use rbdms(mysql or postgres) all the time with an ORM and the ORM does most of the heavy lifti…

It is honestly a nightmare. I had to make a decision which framework to invest learning in with very limited funds. At the time, the big choices where Angular which had been established and backed by Google and React which was still very new with a much smaller community. I went with Angular and by the time I learned everything I needed, everyone wanted to hire React developers. Running out of money, I ended selling all my belongings, moving to a new city, and doing Backbone.js development. I've been working on learning React for the last several months not earning money and it is more difficult to learn than either Angular or Backbone because it isn't as opinionated driving me to have to learn each tool to decide which is best. My mind craves structure. Whereas most developers have 2 years React experience on me. I figure if I waited 6 months to learn JavaScript frameworks, React would have been the better choice and I would have been far better off than what happened. In a way the MEAN stack screwed me.

Re: MongoDB gets support for multi-document ACID transactions

#110

Most software developers have a negative impression of MongoDB, based on the many flaws that it had back in 2010. Among the people who did the best job of documenting those flaws, was Kyle Kingsbury, in his Jespen series: https://aphyr.com/posts/284-jepsen-mongodb But it is important to realize that the team at MongoDB has actually been working with Kingsbury, for several years now, and they have slowly and patiently…

Well...to the best of my knowledge the Mongo DB BI connector in 2018 is still Postgres: https://www.linkedin.com/pulse/mongodb-32-now-powered-postgr... Has this changed?

Yes this has changed. The BI Connector 2.0 is written in Go and uses the MySQL wire protocol: https://docs.mongodb.com/bi-connector/master/release-notes/
Post reply on HN