Live data from Hacker News

Goodbye MongoDB, Hello PostgreSQL (2015)

developer.olery.com

11–20 of 172 posts

Re: Goodbye MongoDB, Hello PostgreSQL (2015)

#11

I used both NoSQL and SQL databases. Proper replication topologies (e.g. multi-master configurations) and JSON columns killed the NoSQL movement. I'm glad the NoSQL movement existed and forced the SQL camp into out-of-the-box thinking, but I wouldn't go for any NoSQL solution today on a greenfield project.

What if you didn't need relational queries and was dealing with a large volume of data that needed to be sharded?

Re: Goodbye MongoDB, Hello PostgreSQL (2015)

#12

I'm a designer and front-end developer. I'm building a fullstack project by myself in Node and I'm using MongoDB. Can someone tell me why is it so bad? I've searched for concrete answers but I got none for the moment yet from time to time people say these kind of things and I worry.

These days MongoDB is mostly a subset of what SQL servers do. If all you need is a document store you can simply make a table with a JSONB column and get that. If you later discover you do need relations you can do that with e.g. Postgres but not with MongoDB.

Historically MongoDB has been known for dropping or mangling data in some unfortunate ways, I'm not entirely sure what the story there is these days but personally I wouldn't trust it ever again. Data integrity is too important.

Re: Goodbye MongoDB, Hello PostgreSQL (2015)

#13
post #7

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 inefficientl…

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)

#14
post #11

I used both NoSQL and SQL databases. Proper replication topologies (e.g. multi-master configurations) and JSON columns killed the NoSQL movement. I'm glad the NoSQL movement existed and forced the SQL camp into out-of-the-box thinking, but I wouldn't go for any NoSQL solution today on a greenfield project.

What if you didn't need relational queries and was dealing with a large volume of data that needed to be sharded?

If you just need a key-value store, a database like MongoDB is rather oversized. Redis or and a bunch of object storage system (now that they actually include locking) are much easier to operate.

As soon as you're back to needing complex queries (with or without relations, Postgres it is again.

Re: Goodbye MongoDB, Hello PostgreSQL (2015)

#15

I learned a framework several years ago and its default db was MongoDB. So I worked with MongoDB for a few years. Then at my job I used PostgreSQL for a several months. I will probably never use MongoDB again.

I'm sorry you had to go through that.

Re: Goodbye MongoDB, Hello PostgreSQL (2015)

#16

I'm a designer and front-end developer. I'm building a fullstack project by myself in Node and I'm using MongoDB. Can someone tell me why is it so bad? I've searched for concrete answers but I got none for the moment yet from time to time people say these kind of things and I worry.

It's not that bad. I have used both and while I wouldn't choose MongoDB anymore, it did its job as needed.

For me, the main problem with MongoDB is that it is "schemaless" - which doesn't mean that there is no schema, just that it is not explicitly stated and enforced. This leads to problems later when schema changes and you need to be extra careful not to end up with inconsistent data (good luck with that). But this is solveable, it just takes more effort than necessary.

If you are using MongoDB for a small-ish project you should be ok. And if your project becomes big, you will need people who know the difference and will be able to migrate (if needed) anyway. So no worries, and good luck with your project! :)

Re: Goodbye MongoDB, Hello PostgreSQL (2015)

#17
post #11

I used both NoSQL and SQL databases. Proper replication topologies (e.g. multi-master configurations) and JSON columns killed the NoSQL movement. I'm glad the NoSQL movement existed and forced the SQL camp into out-of-the-box thinking, but I wouldn't go for any NoSQL solution today on a greenfield project.

What if you didn't need relational queries and was dealing with a large volume of data that needed to be sharded?

In what scenarios does one work on data without any relations?

Honest question - perhaps I'm too used to think in SQL but even with e.g. a completely flat bunch of documents one usually needs at least access control (i.e. document owners, which is a relation).

Re: Goodbye MongoDB, Hello PostgreSQL (2015)

#18
I still feel somewhat that Mongo is blamed for things that it is not supposed to do. Removing millions of records surely is not a usecase that Mongo is comfortable with. Or if you absolutely need a schema to protect developer doing silly things, then traditional relational database is surely way to go. Mongo is superbly quick to serve read-heavy applications. I did one project with Mongo & Sinatra and the app was able to reach high transaction/second rates compared to the hardware stack it was running on. Of course we faced issues to design trustworthy design for very high scaling. I think it is one culprit with Mongo, sharding and things. But anyway, we as developers and architects, just need to have right tools for the task we try to solve!

Re: Goodbye MongoDB, Hello PostgreSQL (2015)

#19
post #11

I used both NoSQL and SQL databases. Proper replication topologies (e.g. multi-master configurations) and JSON columns killed the NoSQL movement. I'm glad the NoSQL movement existed and forced the SQL camp into out-of-the-box thinking, but I wouldn't go for any NoSQL solution today on a greenfield project.

What if you didn't need relational queries and was dealing with a large volume of data that needed to be sharded?

As a former Oracle DBA, and general skeptic of most of the use cases the NoSQL ends up getting chosen for, I’ll gladly say that document databases are pretty good at storing documents. I’ve seen them used very well in content management applications, and the document-database-as-a-materialized-view use case can make a lot of sense. Just like graph databases can be very good at storing graphs. As far as the bandwagoning goes though, I think Mongo has taught a lot of people about the strengths of the relational model.
Post reply on HN