111–120 of 245 posts
Earlier quoted context omitted.
I'm sure that there are tasks for which non-relational stores might be better suited, but pretty much anything MongoDB does, Postgres does it better and in a more performant way (esp after the optimizations to the JSONB data type in the last few major releases).
This is a very bold comment, explain how you scale write, do HA in pg?
Use Postgres, problem solved.
MongoDB of course has right to change their license to anything they want. One day they might decide to go proprietary with no notice too... According to our poll many users will seek alternatives for MongoDB because of the license change https://www.percona.com/blog/2018/10/24/poll-mongodb-license... MongoDB probably feels they have reached critical mass so it does not matter any more...
They have become a new standard and they are aware of it.
Just look at any bootcamps for devs this days , it’s basically always JS + MongoDB. Not Postgres or MySQL , Mongo.
Mongo has become the new MySQL for a lot of devs these days.
It’s often the only DBMS they know...
These move is somewhat coherent with what others are doing in the industry ( Redis Enterprise Modules new licence , Docker preventing download without creating an account etc...)
Open Source is now Venture Backed , as a result it needs to make profit.
Earlier quoted context omitted.
While I like relational data and I _love_ Postgres specifically, there are some tasks and contexts for which non-relational stores are better suited.
I'm sure that there are tasks for which non-relational stores might be better suited, but pretty much anything MongoDB does, Postgres does it better and in a more performant way (esp after the optimizations to the JSONB data type in the last few major releases).
I can understand the sentiment and realize the need to monetize, it's hard when others take your code and make more money out of it then you (which I am assuming is the case). But even if they are right, this doesn't seem smart, it feels like a knee jerk reaction. I imagine that they hope that by doing this they'll cause people who are using mongo on other providers to move to mongolabs, since there is 0 chance of th…
Just my opinion, of course, but I think this is only true for sales and management types who are profit driven. For engineers and artists, it's not really an issue. We want to see our best work appreciated, primarily.
Only a data point here -- after I read about this license change on HN, it took me about 2 hours to struggle over the issue, discuss with my team, and switch from MongoDB to PostgreSql. We are very lucky in that we were into this project for only two months, prototyping and learning the ropes with MongoDB schema. With PostgreSql now, everyone feels secure in a familiar territory. Yes, we have to make changes and its…
not nit-picking, just attempting to help other readers who aren't native English speakers
I don't understand the line of reasoning. Can anyone give me a lay explanation? My understanding of the license change is basically "if you use MongoDB to support any site, all software higher in the stack needs to be released as well". Is that accurate? If so, why can't an author make this part of the license?
Earlier quoted context omitted.
Postgres HA: https://www.postgresql.org/docs/9.5/static/high-availability...
This is not what I called HA or horizontal scaling. Have a look at what MongoDB or Cassandra do.
Only a data point here -- after I read about this license change on HN, it took me about 2 hours to struggle over the issue, discuss with my team, and switch from MongoDB to PostgreSql. We are very lucky in that we were into this project for only two months, prototyping and learning the ropes with MongoDB schema. With PostgreSql now, everyone feels secure in a familiar territory. Yes, we have to make changes and its…
weary (tired) -> wary (concerned) not nit-picking, just attempting to help other readers who aren't native English speakers
Earlier quoted context omitted.
I'm sure that there are tasks for which non-relational stores might be better suited, but pretty much anything MongoDB does, Postgres does it better and in a more performant way (esp after the optimizations to the JSONB data type in the last few major releases).
Performance is definitely an important aspect, but coming from a background working at smaller companies, bootstrapping time and development time are a factor as well -- and while Postgres is easy to set up if you're familiar with it (and I dare say it makes DB design fairly straightforward), Mongo and other NoSQLs are pretty objectively easier to just get working if you aren't fluent in relational databases.