Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Homebrew removes MongoDB from core formulas

github.com

Post reply on HN
Print view View original

141–150 of 291 posts

Re: Homebrew removes MongoDB from core formulas

#141

Post by judge2020 »

Thorrez wrote: post #130
zxcvbn4038 wrote: post #74

Earlier quoted context omitted.

A lot of companies got lured into using mongodb because it was so developer friendly. It cost nothing and it was easy bring in the back door and alleviated the need for thought. Then their sales people started coming around and asking for insane sums of money (like $10,000 per instance per year plus 100% markup on hardware to run in AWS - support is extra). They were worried about amazon and others offering a better…

Maybe I'm misunderstanding, but I thought the new license is just about offering MongoDB as a service by itself. But if you're making any other sort of website and use MongoDB as a database, you can still install it and use it for free. If the companies got lured into using MongoDB as a service, then I understand that prices could increase and companies could be in a pickle. But if companies got lured into using Mong…

You're correct, the new license only prevents AWS and other cloud from running the MongoDB software itself as a managed service unless they open-source their entire platform (although, as we see with DocumentDB, they can legally implement the API without the license coming into effect).

The parent comment states "their sales people started coming around and asking for insane sums of money" but I can't find any reference to this.

Re: Homebrew removes MongoDB from core formulas

#142

Post by geowwy »

zxcvbn4038 wrote: post #74
Thorrez wrote: post #28

Earlier quoted context omitted.

What you do mean by the "mongoDB trap"? Are you saying companies are hurt by the license, or are you saying companies are hurt by software's behavior (e.g. consistency model)?

A lot of companies got lured into using mongodb because it was so developer friendly. It cost nothing and it was easy bring in the back door and alleviated the need for thought. Then their sales people started coming around and asking for insane sums of money (like $10,000 per instance per year plus 100% markup on hardware to run in AWS - support is extra). They were worried about amazon and others offering a better…

  > If it had been SQL it would have been easy to drop in another database.
Not true at all. Way too many organisations are locked into Oracle just because it's too hard to switch to something cheaper.

Re: Homebrew removes MongoDB from core formulas

#143

Post by craigching »

33degrees wrote: post #128
craigching wrote: post #101

A lot of people advocate PostgreSQL as a replacement. Why not elasticsearch? It’s also a document store with a good history. At a previous job I shipped Mongo as the store (under AGPL) because at the time the replication story for PGSQL was too complex compared to mongo. But I reached a point where I was going to replace Mongo with elasticsearch and get rid of Solr at the same time.

ElasticSearch has some resiliency issues, which are well documented: https://www.elastic.co/guide/en/elasticsearch/resiliency/cur... I've run into some weird issues in the past with data types changing by themselves, but it may have been user error: in any case being able to reindex from scratch fixed the problem.

Just as an anecdote to the jepsen test findings, I’ve used elasticsearch at two jobs as a primary datasource and haven’t had data loss as mentioned in the tests. The tests are, at this point, pretty old and I’ve found that newer versions are pretty good at controlling data loss.

As a counterpoint, mongo also still has some outstanding issues with jepsen tests, but they are working on being compliant. Honestly, as far as resiliency, I’m not sure either has solved the problem perfectly.

Re: Homebrew removes MongoDB from core formulas

#144

Post by craigching »

McGlockenshire wrote: post #112
craigching wrote: post #101

A lot of people advocate PostgreSQL as a replacement. Why not elasticsearch? It’s also a document store with a good history. At a previous job I shipped Mongo as the store (under AGPL) because at the time the replication story for PGSQL was too complex compared to mongo. But I reached a point where I was going to replace Mongo with elasticsearch and get rid of Solr at the same time.

I asked myself this a few years ago and went to see who had thought of it first. At the time, the prevailing opinion was that this was a bad idea. Elasticsearch had no ACID data integrity guarantees at all at the time. Has this changed?

My mongodb knowledge is probably a bit out-of-date here. It didn’t have them either when I was using it. Multi-document ACID would have been really useful, is that a feature now? That would be one data point against elasticsearch.

Re: Homebrew removes MongoDB from core formulas

#146

Post by snorkel »

nevi-me wrote: post #118
threeseed wrote: post #98

Earlier quoted context omitted.

I work in the enterprise and we spend tens of millions a year with AWS. Our Security, Cloud Engineering and Finance teams understand VPC, IAM, Costs etc back to front and so when you add a new AWS product they know how to manage, secure, finance and support it. And of course there is no Procurement process with adding a new AWS product. With a managed MongoDB (even though it's on AWS) you need to get buy in from doze…

This still doesn't sound like a good reason to pay AWS instead of MongoDB. Didn't your Security, Cloud Engineering and Finance teams have no understanding of AWS at some point? Why can't they start to 'understand' how a managed MongoDB works, and give buy-in? There's a common saying we have in our consulting circles, that "Processes should support business, but business decisions shouldn't be made because of lack of…

Unfortunately that’s typical in enterprises. Procurement staffers are typically not technologists, rather they are contract wranglers, responsible for setting terms with vendors that have longevity, references, willing to negotiate, approved by security, are provably better than at least two comparable competitors, etc. If you want to sell to enterprises you have to bend the knee to their procurement team.

Re: Homebrew removes MongoDB from core formulas

#147

Post by scarface74 »

jaequery wrote: post #138
scarface74 wrote: post #125

Earlier quoted context omitted.

And then when you need to do reports on the data and query it?

Why not just use Postgres, set a field as jsonb, done?

Why use Postgres just to store JSON? The entire tooling around Mongo is better for JSON Data.

Not to mention the LINQ driver....

And you can’t do updates on individual JSON fields in Postgres.

Re: Homebrew removes MongoDB from core formulas

#148

Post by zxcvbn4038 »

6nf wrote: post #94
scarface74 wrote: post #86

Earlier quoted context omitted.

But Mongodb is so different from anything else that you need a major rewrite to get away from it. Well actually.... One corner case. If you are using Mongo with the Mongo Linq driver in C#, you can switch it out for an RDMS without changing too much code with just a little foresight.

So why not just use a RDMS from day one?

A lot of people have difficulty trying to organize complex hierarchical data into rows and columns. A lot of places make you go through a dba to create or change a database which rubs power users the wrong way - and admittedly most of the dbas I’ve worked with are a lot more concerned with making backups fast then in your applications performance. Mongodb doesn’t make you do any of that. It doesn’t make you have authentication either. I think that’s a big reason why it got so popular.

Re: Homebrew removes MongoDB from core formulas

#149

Post by nevi-me »

mbreese wrote: post #140
nevi-me wrote: post #137

Earlier quoted context omitted.

My point is that those support functions' lack of understanding of realms outside of AWS shouldn't be the sole motivator for not using a technology. What happens if a company that uses Software A has good motivation to use B, but their support functions don't understand B? Aren't the support functions supposed to improve by seeking to understand B, even at the initial inconvenience of time and resources?

I certainly don’t disagree with you on principle. It’s just a bad example in this specific case because A is roughly equivalent to B in this case. Also, Amazon doesn’t have the same reputation as Google for killing products, so it’s a pretty safe bet. And AWS will be around for quite a long time. The financial stability of MongoDB (the company) isn’t as guaranteed. Maybe the parent’s company’s processes did work in t…

They're roughly equivalent, but what if B costs a tenth of A?

It's not about the safety of the bet, because from an OSS perspective, the issue seems to be that many are moving away from MongoDB to something even more opaque. I don't follow AWS, but do they publish a roadmap of planned changes in their document DB?

Re: Homebrew removes MongoDB from core formulas

#150

Post by xchaotic »

liability wrote: post #117
scarface74 wrote: post #99

Earlier quoted context omitted.

Because we had data that fit better in a non relational store. We stored data that created from user generated forms and we loaded data back into those forms. Why use a relational store? If you’re working with a system that will only be read and written by an object based language? Why keep converting back and forth between a relational model and an object oriented model? In C# var seniorMales = from c in context.Cus…

> Why use a relational store? If you’re working with a system that will only be read and written by an object based language? Why keep converting back and forth between a relational model and an object oriented model? Well I can't tell you what the right choice in your system is, but in the general case I think going with a relational model by default generally makes sense because it's rather future proof. By that I…

I think you got it backwards. A relational schema change is required and probably a data reindex or reload when you change a data model so relational is the least flexible as opposed to something like Mongo nosql?
Post reply on HN