Live data from Hacker News

Bye Bye Mongo, Hello Postgres

theguardian.com

391–400 of 427 posts

Re: Bye Bye Mongo, Hello Postgres

#391
post #363

Earlier quoted context omitted.

I think what happens (and I have this attitude too) is that "learning" SQL takes a weekend...but then you know you'll wind up having to spend a lot longer learning the patterns of the language, and the nuances of the specific dialect, and which of the integration tools will work well with your workflow and pipeline. So while "sure I'll just learn SQL" is great for a personal or school project, when you've got to get…

learning" SQL takes a weekend...but then you know you'll wind up having to spend a lot longer learning the patterns of the language, SQL is a skill that rewards investment in it 1000x over, in terms of longevity. It has spanned people’s entire careers! What’s the shelf life of the latest JS framework, 18 months at most...

Yes, I know that, and that's why I know and use SQL instead of MongoDB. But that's a very similar reason to why I've resisted learning Rust, and Ruby, and React, and Docker, and Scala, and many more. I know I could learn the utter basics in a weekend, but I also know that those basics are utterly useless in a real-world context, and I would prefer to spend the weekend hacking on my open-source project in Python or C, which I've already invested the years into. And that's how engineers age into irrelevance..

Re: Bye Bye Mongo, Hello Postgres

#392

Earlier quoted context omitted.

Because of how different they are, taking advantage of them requires using them in specific ways that are also very different. If you have an abstraction layer that hides those differences, it's practically a given that it does so with the lowest common denominator approach, where you get all the flaws of both and none of their unique benefits. (Alternatively, people find ways to use the abstraction layer such that i…

I'm pretty sure you can have one interface for YeSQL an NoSQL. * getUsers() * saveUser() * listUsers() * deleteUser() and implementation can implement it in specific way to take advantage of chosen technology. If you have some esoteric use cases they could be handled in special way separate from business code.

For that specific use case, maybe. Where it falls apart is in `searchUser`, where the methods (and performance characteristics) of digging through the respective databases are going to be radically different. In a newspaper's implementation, you're going to have to search by date, subject, keyword, body text string, reporter, etc. etc. In MongoDB, that generally involves creating an index on the combination of fields you'll be searching together. In SQL, that generally looks like adding a `where reporter = "Jane Smith"` predicate. The MongoDB version may be faster if you have an enormous amount of data spread across a cluster. The PostgreSQL version will be more flexible when your boss wants to know how many reporters wrote stories about candied yams within three days of the publication of any story containing the word "Thanksgiving".

Being tasked to come up with an abstraction layer that supports the speed of precomputed, clustered indexes with the flexibility of SQL - if I were in a content creation business and not a database engine writing business - sounds like the kind of project that would make me quit my job and go on a one year silent meditation retreat.

Re: Bye Bye Mongo, Hello Postgres

#393
post #217

Earlier quoted context omitted.

I'm glad that RedHat didn't feel that way when they were sponsoring kernel development, or that Netscape had panicked and locked down Netscape instead of opening it up, or that Sun had given Java a terrible license. Or Google and Kubernetes. LinkedIn and Kafka. Airbnb and Air Flow. I could keep going like this all day. Mongo made a lot of money building a projects that runs on top of many other projects that were rel…

So Redis, HAproxy, MongoDB, ect .. should feel good that nowdays multi-billion $ companies take your product and put more people on it that you do internally, sell it and give you nothing? Explain to me how a startup of 10-20 people can compete against AWS once they grab what you're working on to make an AWS service? Changes Mongo, Redis made to their licence were made to protected against those practices.

1. Redis — according to its creator — has always been, is, and will continue to be FOSS. Redis Labs did not create Redis, nor can they re-license it.

2. HAproxy is still GPLv2.

3. Redis Labs's CCL and MongoDB's SSPL are not open source licenses, but their purveyors sure do like to give off the impression that they are open source. If you want to keep your code proprietary, keep it proprietary. Don't pretend to be open source. If you are not okay with others using your work, even making money off of it, as long they adhere to the rules of the open source licence you used to license your work to them, then don't license your work to them under open source licenses, or don't cry foul when they use it under the terms of the license.

Re: Bye Bye Mongo, Hello Postgres

#394

Earlier quoted context omitted.

Would PostgreSQL + JSONB work for you there?

Allegedly, Mongo is more efficient if you need to ingest billions of records.

I remember when that was true, because MongoDB used to mmap files and skip fsync.

/dev/null is more efficient than just about anything at ingesting billions of records, but not very useful, is it?

Re: Bye Bye Mongo, Hello Postgres

#395
post #139

Earlier quoted context omitted.

Subtle data loss...

I'm not trying to cover mongo but I hear stability has improved and random data loss is an old story.

I'd rather go with the database that has never blatantly lied, especially about keeping my data safe.

Re: Bye Bye Mongo, Hello Postgres

#396

Earlier quoted context omitted.

FWIW and insofar as I can recollect, JSON was supported by Postgres before Mongo was a thing, and Mongo was built based on Postgres.

No, that's not correct: Initial json support in PG was added in early 2012 https://git.postgresql.org/gitweb/?p=postgresql.git;a=commit... whereas mongodb was made public in 2009, according to wikipedia: https://en.wikipedia.org/wiki/MongoDB I don't see how Mongo was built based on Postgres, either?

I might admittedly be remembering this wrong, but I seem to recollect that Postgres had a couple of (unofficial) contrib modules to support JSON back in 2008 or so, and that (unfortunately buried in Postgres vs Mongo articles) the initial release of Mongo was actually a fork of Postgres for all practical intents.

The relevant data structures and indexing mechanisms (hstore, tsvector, gin, gist) were all available -- if only experimentally -- before Mongo launched.

Re: Bye Bye Mongo, Hello Postgres

#397
post #294

Earlier quoted context omitted.

No, that's not correct: Initial json support in PG was added in early 2012 https://git.postgresql.org/gitweb/?p=postgresql.git;a=commit... whereas mongodb was made public in 2009, according to wikipedia: https://en.wikipedia.org/wiki/MongoDB I don't see how Mongo was built based on Postgres, either?

My guess is the grandparent is (mis-)remembering the kerfuffle[0] around mongo shipping a copy of PG as a "BI Connector". But yeah, the timeline is off, that was in 2015. 0: https://news.ycombinator.com/item?id=10697692

Actually, no. I'm remembering asking myself how Mongo worked back when it launched, and reading somewhere that it was a heavily modded Postgres under the hood (like Amazon Redshift, which makes no secret about it, since).

I might be misremembering, though. And there's a possibility that what I read then was inaccurate.

Re: Bye Bye Mongo, Hello Postgres

#398
post #310
post #225

It's not a great article tbh, it's well written but it shows the clear lack of knowledge running a backend. The title should be "we didn't know what we were doing so we switched to a managed DB" I mean yeah who knew that blocking NTP therefore time drifting would break everything... For those criticizing MongoDB, Fortnite generates $3B/year and runs on MongoDB, you should tell them it's a mistake and that they should…

Epic have also had at least 2 major outages directly related to MongoDB https://www.epicgames.com/fortnite/en-US/news/postmortem-of-... https://www.epicgames.com/fortnite/en-US/news/postmortem-of-...

It was not because of MongoDB itself if you've read the article.

Re: Bye Bye Mongo, Hello Postgres

#399
post #70

Earlier quoted context omitted.

This actually resonates with me, maybe not in the way Ellison intended as I’m not familiar with the context he said it in. A bit off the main topic but the more I revert to just using emacs for some task I previously used a .app bundle or web page for, the more I question how much we the computer industry has just been spinning its wheels for the last 30+ years. I honestly can’t really tell what value WIMP-centric GU…

Discoverability and self documentation is generally the advantage of GUI systems. Well built systems can be understood in a few moments without needing to consult a manual. That's almost impossible in a pure CLI environment. Of course it's entirely possible to screw this up, modern phone-centric design standards are really bad about it for example, but in general you need to consult the manual (or Google) far less of…

I’m not convinced these are inherent properties of GUIness. We have had GUIs in use for long enough that many elements even across slightly different GUIs are familiar enough, this had allowed conventions and then conventional wisdom to develop.

Early GUI developers also put effort into making their GUIs at least somewhat intuitive, but they also bundled thick books of documentation on how to use their systems.

To a degree, they are self-documenting, but not because of their GUIness so much as their design choices; menus helped a lot with this. Menus actually are a good subject to touch upon, they are definitely one of the better conventions we developed, and they were based upon and analogous to a restaurant menu. However their very nature as a list of commands you can issue a GUI does also typically but not always, limit the application. If the only options available to you are what is on the menu and there is no other interface, then an application is much more limited. This isn’t even true of most restaurants which will often allow you to issue an order for something not on the menu if they have the ingredients, equipment and expertise to make it.

But as a convention, it is not limited solely to GUIs, you can incorporate menus into any interactive interface.

I think the real innovation wasn’t GUIs, it was interactive software. The innovation beyond that is scriptable software.

What is important isn’t GUIness, but the developer’s intent. If you develop software with the intent to be self-documenting and discoverable, you will end up with an interface that is both of these things provided you did a competent job of it. A GUI might help, relying on platform conventions might help, and using common cultural conventions might help, but these aren’t the necessary ingredients for those qualities.

Emacs has the quality of self-documentation, but it is emphatically not a GUI even though it is interactive.

I would say well built systems, provided you intend to do anything productive and even slightly complex, should have a manual included, or else it isn’t a well built system.

Re: Bye Bye Mongo, Hello Postgres

#400
post #109
post #70

Earlier quoted context omitted.

This actually resonates with me, maybe not in the way Ellison intended as I’m not familiar with the context he said it in. A bit off the main topic but the more I revert to just using emacs for some task I previously used a .app bundle or web page for, the more I question how much we the computer industry has just been spinning its wheels for the last 30+ years. I honestly can’t really tell what value WIMP-centric GU…

> I suspect that in a year I’ll be using what is effectively an Elisp machine with an Apple logo paired with an iPhone. It's been working for me for quite a while now. And it's depressing, but here we are.

It isn’t all bad. My laptop is 6, almost 7 years old at this point and it has received a few upgrades in that time. This change in habits does lower the minimum system requirements for its eventual replacement from “runs Mac OS X” to “runs emacs”, but I might be able to stretch its life out a bit longer now.
Post reply on HN