Re:Goodbye MongoDB, Hello PostgreSQL (2015)
by menzoic on Thursday March 11, 2021 @02:15AM
(#26421219)
MongoDB and Postgres have very different strengths and weaknesses. It sounds like they didn't consider the needs of their read and write patterns before they decided to go with MongoDB and then blamed it for not being a good fit for their use case. The article doesn't give any insight at all into the cause of the performance issues, just that they happened. It could've been that they were doing something inefficiently. They also don't give any reasons for the performance increase when switching to Postgres. It could've been anything like they were doing application layer joins with Mongo and things got faster when switching to a relational database because they could do joins in one process without serially fetching data over the network. They also touch on schema on read vs schema on write but instead of talking about the tradeoffs and use cases of both patterns, they just claim schema on read is bad.
[ Parent
| on HN ]
Re:Goodbye MongoDB, Hello PostgreSQL (2015)
by chris_wot on Thursday March 11, 2021 @02:26AM
(#26421277)
The article doesn't give any insight into the cause of the performance issue because they coudn't work out what that cause was:
In another instance we noticed degraded performance of our applications and managed to trace it to our MongoDB cluster. However, upon further inspection we were unable to find the actual cause of the problem. No matter what metrics we installed, tools we used or commands we ran we couldn’t find the cause.
Re:Goodbye MongoDB, Hello PostgreSQL (2015)
by menzoic on Thursday March 11, 2021 @04:04AM
(#26421878)
True, but it seems like they blamed it on MongoDB just being bad without justification and proposed Postgres as the solution.
Re:Goodbye MongoDB, Hello PostgreSQL (2015)
by chris_wot on Thursday March 11, 2021 @04:54AM
(#26422246)
No, it seems like the diagnostics tools they were provided didn't help them get to the bottom of the very bad performance issue they were actually having with MongoDB, and then they proposed Postgres as the solution. As most companies do, eventually.
Re:Goodbye MongoDB, Hello PostgreSQL (2015)
by menzoic on Thursday March 11, 2021 @05:35PM
(#26429882)
Without knowing the context it's impossible to say if it was user error or application error. I don't see it as a fair write up.
Re:Goodbye MongoDB, Hello PostgreSQL (2015)
by chris_wot on Thursday March 11, 2021 @06:20PM
(#26430308)
It's a fair write up in that they were unable to diagnose the actual problem with MongoDB. Which leads to one of the problems with the product - it is hard to know what is causing the issue when it has problems.
Re:Goodbye MongoDB, Hello PostgreSQL (2015)
by wilco_vd on Friday March 12, 2021 @03:34PM
(#26440550)
Hey, I was one of the developers on the team at that time. It's been fun re-reading that write up. I learned a lot since then, and I think the whole industry has learned a lot regarding NoSQL databases, their strengths and weaknesses and how to deal with those in your applications.
You are correct that the biggest issue was that we couldn't diagnose problems when they occurred, and therefore we couldn't learn. Some of those problems were for sure "user error", others were absolutely problems with MongoDB at the time. It was a "young" database back in 2015.
Re:Goodbye MongoDB, Hello PostgreSQL (2015)
by sam_goody on Thursday March 11, 2021 @11:25AM
(#26425752)
Is there a good table charting the unique strengths and weaknesses of databases (or database types), so that people that are looking to build things but don't have the background could choose the right tool for the job?
If not, that may make a popular HN post!
Cassandra, CouchDB or Mongo? Redis? SQLite? Mysql/Maria/Percona or Postgres? Cockroach? Timescale or Influx? Why in the world do all these tools exist?