Live data from Hacker News

Homebrew removes MongoDB from core formulas

github.com

31–40 of 291 posts

Re: Homebrew removes MongoDB from core formulas

#31

Serious question: can someone explain why the server side public license is not an open source license, with specific reference to AGPL? Is it because of the provision forcing the source code release of auxillary software used to run the software as a service? As far as I can tell, it meets the FSF's free software definition and the only that seems questionable in the OSI's open source definition is point 9.

Since it's literally impossible to comply with the article 13 of SSPL, MongoDB's license definitely doesn't give its users freedom 0[1], as defined by FSF.

[1] - The freedom to run the program as you wish, for any purpose

Re: Homebrew removes MongoDB from core formulas

#32
post #13
post #7

With MongoDB's license there is another reason to migrate away from it. I migrated an app from MongoDB to postgres. I ended up just using a varchar to store the IDs. The Mongo style IDs are in addition to an integer primary key, so joins happen with integers, but every time a user is shown the IDs, in the URLs, it's a BSON ID. It hasn't caused any issues, performance or otherwise, but there are thousands rather than…

PostgreSQL do have a variable unlimited length datatype : text. AFAIK, Varchar is internally a subtype that bound the text type. So in extreme situations you might even get a very slight performance advantage using text instead of varchar.

This is exactly how it is. You can find confirmation in Postgres docs [1]

[1] https://www.postgresql.org/docs/9.1/datatype-character.html

Re: Homebrew removes MongoDB from core formulas

#33

What are the best alternatives to mongo db going forward? Are there any forks with momentum?

My current thinking is to consider postgres as the default choice, especially for an MVP. It can handle just about any MVP-level scenario and helps you avoid over-engineering.

But if you really do need NoSQL to deal with scalability or more advanced requirements, I like DynamoDB. I like it not because it’s user-friendly (it’s not very), but because its limitations are very clear and out-front, and if you try to do something it’s not suited for, you’ll quickly realize it’s hopeless.

Mongo is the opposite—it gives you the impression that you can use it for all kinds of things, and it feels easy in the beginning. But without careful planning, it will lead you merrily into awful traps, because its underlying limitations are glossed and patched over by the api rather than being made explicit.

Re: Homebrew removes MongoDB from core formulas

#34
post #15

Earlier quoted context omitted.

DocumentDB is still really expensive as there's no pay what you use option. I stored about 2KB of data for 72 hours and got charged fifteen dollars before I realised the mistake. They really need to come up with a per mb per hour option.

What?!? I’m a big AWS skeptic for most people but this sounds insane. Details?

The cheapest option is 0.277$/hr just for the instance.

https://aws.amazon.com/documentdb/pricing/

Re: Homebrew removes MongoDB from core formulas

#35

Would love to see an overview of companies that fell into the mongoDB trap and have / are migrating to another DB store.

Didn’t Stripe go down this road?

Yes, in addition they apparently use a pretty outdated version of it. (Several people mentioned this on a related HN thread that I'm having trouble locating.)

Re: Homebrew removes MongoDB from core formulas

#36

asked this on a sqllite thread before but: anyone know a single file nosqldb that has good python bindings. i know I could just write to json or something but I'd like something that supports queries. right now I'm using MongoDB and it's completely Overkill

SQLite has really good JSON support these days. Any reason not to use that?

Re: Homebrew removes MongoDB from core formulas

#37
post #24

Can somebody tell me what is wrong is SSPL? I just don't understand what this hostility is all about. A company creates a crucial infrastructure component which is a database, open sources it, everybody can use it for free, cloud vendors started just installing it on their servers or making clones of it and making profit off it, everybody is using a component that took years and millions of dollars to develop but the…

I don't think your baker metaphor holds up though, because a major component of open source software is that people outside of the companies support it.

A better metaphor would be if the bakery had started by using volunteers to create all the recipes, and then the baker decided that people could only use those recipes if they followed his terms so that the baker could stop other bakeries from competing. This obviously upsets the people who contributed to the recipes thinking they would be open for anyone to use.

Mongo started as an open source project, used that openness to build community (and indeed their product itself), and then pulled the rug out from under everyone to gain a competitive advantage.

Re: Homebrew removes MongoDB from core formulas

#38
post #15

Earlier quoted context omitted.

DocumentDB is still really expensive as there's no pay what you use option. I stored about 2KB of data for 72 hours and got charged fifteen dollars before I realised the mistake. They really need to come up with a per mb per hour option.

What?!? I’m a big AWS skeptic for most people but this sounds insane. Details?

https://aws.amazon.com/documentdb/pricing/ At $0.277 it’s $19.94 for 72 hours.

Re: Homebrew removes MongoDB from core formulas

#39
post #36

asked this on a sqllite thread before but: anyone know a single file nosqldb that has good python bindings. i know I could just write to json or something but I'd like something that supports queries. right now I'm using MongoDB and it's completely Overkill

SQLite has really good JSON support these days. Any reason not to use that?

as far as i could tell you have to jump through some hoops to use it (compile extension from source?). and i couldn't tell if it supported querying

Re: Homebrew removes MongoDB from core formulas

#40
post #13
post #7

With MongoDB's license there is another reason to migrate away from it. I migrated an app from MongoDB to postgres. I ended up just using a varchar to store the IDs. The Mongo style IDs are in addition to an integer primary key, so joins happen with integers, but every time a user is shown the IDs, in the URLs, it's a BSON ID. It hasn't caused any issues, performance or otherwise, but there are thousands rather than…

PostgreSQL do have a variable unlimited length datatype : text. AFAIK, Varchar is internally a subtype that bound the text type. So in extreme situations you might even get a very slight performance advantage using text instead of varchar.

Interesting. When is there an advantage of using varchar in postgres, other than limiting the field length?
Post reply on HN