Live data from Hacker News

Bye Bye Mongo, Hello Postgres

theguardian.com

81–90 of 427 posts

Re: Bye Bye Mongo, Hello Postgres

#81

Earlier quoted context omitted.

It's amazing how many insurmountable SQL performance problems can be surmounted by putting things in 3rd normal form.

But denormalization is one strategy to improve the performance of a rdbms.

Standard rules about performance optimization apply. Denormalization can improve performance, but it can just as easily harm it.

For code, I think by now we all understand that you should always start with clean, well-factored code, and then optimize only as much as is necessary, which is usually not at all, and always under profiler guidance. It's the same with DBs: You start with a clean, well-normalized schema, and then de-normalize only as much as is necessary, which is usually not at all, and always under profiler guidance.

Also, keep in mind that improvements in compiler technology over time mean that the performance tricks of old can be useless or even actively harmful nowadays. This is true of SQL every bit as much as C.

Re: Bye Bye Mongo, Hello Postgres

#82

They have some unique requirements to host within their own VPC. I just use mlab.

Define unique? My company does bespoke software development for large enterprises. If they're on AWS having all your services within a VPC you control is something of table stakes for a lot of large company engineering and security teams.

Well, guess I'm mostly talking about startups.

Re: Bye Bye Mongo, Hello Postgres

#83
post #48
post #23

Earlier quoted context omitted.

There are bunch of companies behind PG actually. From Fujitsu and EnterpriseDB to smaller ones like 2ndQuadrant, PostgresPro, CitusDB and many others.

Those companies did not create PG, the company behind Mongo did and does not want Google / AWS / MS to make a service using Mongo for free.

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 released as Free Software. Now they're upset that other people are building on top of Mongo in the same way.

Re: Bye Bye Mongo, Hello Postgres

#84
post #39

Document DBs are like blockchain projects - overhyped and worse than existing solutions for nearly every use case. Why do ostensibly smart engineers keep falling for this stuff?

Well, we're kind of comparing MongoDB of ~2011 (when The Guardian started using them) with Postgres of today.

One major change is that in 2010 you couldn't always run your whole DB in RAM, so there were some real performance benefits with MongoDB.

Another difference is that MongoDB was early with great JSON-support. Something that Postgres has since gained.

I think there are pros and cons with both. If I'd chose one today, for most tasks I'd probably chose Postgres.

That said, to understand why people made those choices, you need to 'teleport back' to that time and compare them in that year (given the tradeoffs at that time).

Re: Bye Bye Mongo, Hello Postgres

#85

As a reminder, PostgreSQL is distributable under a license that's basically BSD/MIT: https://www.postgresql.org/about/licence/ MongoDB, on the other hand, recently changed their license to an abomination that many people think is no longer Free: https://news.ycombinator.com/item?id=18301116

Downvoters, would you explain? I didn't think this was a controversial opinion: Mongo is now under a license that is not listed as Open Source, as defined at https://opensource.org/licenses/alphabetical

If you care about using FOSS - as many companies do - MongoDB is no longer open for consideration.

Re: Bye Bye Mongo, Hello Postgres

#87
post #39

Document DBs are like blockchain projects - overhyped and worse than existing solutions for nearly every use case. Why do ostensibly smart engineers keep falling for this stuff?

Well, we're kind of comparing MongoDB of ~2011 (when The Guardian started using them) with Postgres of today. One major change is that in 2010 you couldn't always run your whole DB in RAM, so there were some real performance benefits with MongoDB. Another difference is that MongoDB was early with great JSON-support. Something that Postgres has since gained. I think there are pros and cons with both. If I'd chose one…

Oh! From The Guardian write up I had the impression they were using it until mid 2018..

Re: Bye Bye Mongo, Hello Postgres

#88
post #49

> “But postgres isn’t a document store!” I hear you cry. Well, no, it isn’t, but it does have a JSONB column type, with support for indexes on fields within the JSON blob. Interesting. I didn't know you could make indexes for things /within/ the JSON.

With a GIN index and a JSONB column you can index the entire json document. It's the same index type as Postgres uses for the full text search, but not super efficient. You can also project out specific subsets of the document to an index and Postgres will use them.

Re: Bye Bye Mongo, Hello Postgres

#89
post #53
post #30

The Guardian example was heavily used by MongoDB as a case study to pitch their database to others in 2011: https://www.mongodb.com/customers/guardian https://www.mongodb.com/presentations/mongodb-guardian https://www.slideshare.net/tackers/why-we-chose-mongodb-for-... And reupping my previous, three-part series on MongoDB: On MongoDB NoSQL databases were the future. MongoDB was the database for "modern" web engineer…

What really happened is people wanted something new but did not want to change the ways they DESIGN their application and processes. There is place for NoSQL but if you are going to use it as if it was SQL then you would be better served by an SQL database. Also, I think MongoDB tried to be everything and failed to be good at anything. It offers neither stellar performance nor scalability and I guess for most project…

Just a few thoughts. A lot of little companies like picking hyped tools because they think it will differentiate them and server them well later, but most companies never get to that stage and don't really need what is being offered. Seems much safer to take the tried and true standard solution that has worked for decades and just make your UX outstanding rather than try to put together a "dream team" of new tech...

Re: Bye Bye Mongo, Hello Postgres

#90

>“But postgres isn’t a document store!” I hear you cry. Well, no, it isn’t, but it does have a JSONB column type, with support for indexes on fields within the JSON blob. > approximately 2.3m content items. I had a previous project where we did a similar thing (except with HSTORE instead of JSONB) and it exploded rather dramatically (very simple queries took multiple minutes or timed out entirely) after around 30m ro…

2.3m content items is tiny. So is 30m. You're at least 1-2 magnitudes away from something that will start to bother postgres. Anything before that is likely to be an index or IOPS issue.
Post reply on HN