Hacker News Reader

Comment by Fre_d | Hacker News Reader

At least briefly consider whether or not you actually need a relational database when starting a project. I work with some rather complex data access using Postgres, JPA, Hibernate, HikariCP, and a second level cache, all within a separate microservice exposed via a REST API. To make matters worse, the responsible developer has since left the project to me.

We don't even use relations, so this essentially means that we are paying a hefty price for something that we don't actually need. A much simpler solution would be to have used MongoDB together with Spring Data, where we can still have caching and object mapping.

View on HN

I would personally never use MongoDB again. Broke one too many times. Postgres on the other hand has never failed me.

MongoDB was released nearly 10 years ago. Do you believe those issues are still relevant today?

If that’s the argumentation then Postgres is over 22 years old which makes it over two times better? On the other hand Windows is over 30 years old and it still hasn’t fixed many issues which for me are the reasons why I don’t want to have anything to do with it.

I'm not saying MongoDB is better because it is old, and I was rather hoping you would elaborate. For all I know, you could have had issues with it yesterday or 9 years ago.

I haven't tried it in 4 years myself. But I invested in a company that just launched their product two months ago and already regrets building it on Mongo.

Same. I went on hype train, got burned badly and I am never going to use MongoDB again.

I would turn the remark around and say that one should consider if a NoSQL database is required at all.

What would Mongo give you that Postgres doesn't?

Non-relational (NoSQL) databases like Mongo serve a different purpose. They store data in forms other than the traditional relational database table. Theoretically, for certain workloads, they make horizontal scaling easier and improve availability. However, most workloads are suited just fine with a relational database like Postgres.

Postgres also had document store functionality and for many workloads performs better than Mongo. In my personal experience, Postgres is better at being Mongo than Mongo.

Admittedly I'm not yet using it in production, but the simplicity is the most appealing factor, albeit this depends a lot on client libraries used. In addition to my original comment, with Postgres we also had to deal with schemas and migrations.

We can also easily leverage reactive streams with reactive Spring Data. Technically you could also use JDBC in a reactive manner, but it looks unlikely to work with the frameworks we use with Postgres.

If simplicity and lack of migrations is the only advantage of MongoDB then there is no reason to use it in place of Postgres, since you can just use JSONB instead and not worry about any of those.

> with Postgres we also had to deal with schemas and migrations.

Schemata are good things. Migrations are the database insisting on tedious bureaucratic nonsense like "don't blow your foot off" and "don't regret this later".

> Technically you could also use JDBC in a reactive manner, but it looks unlikely to work with the frameworks we use with Postgres.

The Spring team are pretty keen on removing that gap: http://r2dbc.io/

> with Postgres we also had to deal with schemas and migrations.

JIC, this is exactly what I meant with "paying that debt upfront". If your model does turn out to be relational and you don't have this, you are going to get burnt, badly.

Reply on news.ycombinator.com