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

121–130 of 291 posts

Re: Homebrew removes MongoDB from core formulas

#121

Post by eloff »

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

Earlier quoted context omitted.

So why not just use a RDMS from day one?

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…

I worked on a project with similar requirements. I just serialized the data with protobufs, encrypted it, and stashed it in S3. It was sensitive data so this also had the advantage of being easy to secure and audit.

No point using a relational db for that kind of thing.

Re: Homebrew removes MongoDB from core formulas

#122

Post by chrischen »

scarface74 wrote: post #86
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…

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.

Also Foundation DB supports mongodb clients. It also powers iMessage.

Re: Homebrew removes MongoDB from core formulas

#123

Post by hartator »

colordrops wrote: post #97
tedivm wrote: post #50

Earlier quoted context omitted.

MongoDB changed their licensed from an open source license to one that has restrictions specifically aimed at busting up Mongo (the company)'s competitors who offer managed MongoDB services. These restrictions mean it is no longer an open source project. It is also worrying for a lot of people that mongo was willing to change license terms like this, as it means they may be willing to do so in the future if it brings…

Couldn't someone just fork on the last fully open source version of Mongo, similar to the genesis of CentOS?

We should do that definitely.

Re: Homebrew removes MongoDB from core formulas

#124

Post by cameronbrown »

est31 wrote: post #93
mruts wrote: post #75

Earlier quoted context omitted.

I guess not no, I was thinking of userland.

You can make a simple HTTP/1.1 server in 200 lines of good C. Not one that runs HTTP/3.0 including QUIC and TLS.

HTTP 3 isn't even in production yet.

Re: Homebrew removes MongoDB from core formulas

#125

Post by scarface74 »

eloff wrote: post #121
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…

I worked on a project with similar requirements. I just serialized the data with protobufs, encrypted it, and stashed it in S3. It was sensitive data so this also had the advantage of being easy to secure and audit. No point using a relational db for that kind of thing.

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

Re: Homebrew removes MongoDB from core formulas

#126

Post by scarface74 »

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…

If your data store is behind an API you modify the API. You’re often using a different database for your OLAP and OLTP anyway.

Re: Homebrew removes MongoDB from core formulas

#127

Post by cycloptic »

threeseed wrote: post #96
chii wrote: post #76

Earlier quoted context omitted.

only if your source of profit is obtained by restricting the customer from being able to use your code in any way they see fit (including modifying it).

Most businesses make a profit by offering some unique product or service. With the GPL someone could take your unique product, make it their product, undercut you on price and then put you out of business. GPL is unquestionably great for consumers. Not so great for commercial businesses.

If someone can undercut you so easily then your products are overpriced. I would not say this is "not so great for commercial businesses" just because the GPL does not make an effort to prop up phony business models.

Re: Homebrew removes MongoDB from core formulas

#128

Post by 33degrees »

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.

Re: Homebrew removes MongoDB from core formulas

#130

Post by Thorrez »

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…

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 MongoDB as software, I don't see how they could have a problem.

Post reply on HN