Hacker News Reader

Comment by SergeAx | Hacker News Reader

I've spent last 5 years with MongoDB and currently trying to use Postgres for my pet project. Alas, it seems to me that Postgres is not really production-ready.

It needs external connection manager (pgbouncer). Replication is very basic: one should do a backup/restore first and then start a replication praying in the meantime for WAL not to run too far. Until version 13 (released year ago) it was either that, or dedicated replication slot will overflow the disk and kill your master if any replica falls out of sync.

No automatic failover out of the box? That's not what I used to with Mongo. Come on, even Redis learned that trick (with Sentinel, yes, but it is part of the package).

Continuous WAL archiving and point-in-time-recovery is a nice feature, but it needs fs-level backup, not the one from pg_dump. What pg_dump is for, then?

Need time and experience to wrap my head around all this.

View on HN

Your comment is borderline flamebait with that intro, making me wonder if you're just trolling...

Anyway, to start of: why would you want a connection manager Middleware for a pet project? Do you honestly expect to need hundreds/thousands of simultaneous db connections?

The original replication does exactly what it was supposed to, but is not what developers often think they want, which is clearly the reason for your outrage. Clustering isn't easy, as mongodb continues to prove to day by making creation of them easy but then catastrophically fail in production under load as the countless post mortems show. I really doubt you're going to need it anyway for a pet project....

You are right, I am being a bit emotional about this topic recently. I am reading that Postgres is a most popular database today and I can't beleive it is so immature in critical points.

I see a recommendation of using pgbouncer almost on every tutorial and how-to and feel it is really a vital point. As a newbie user I want to be on a safe side with that. Also, heavily concurrent app architecture, even with connection pooling, may easily produce tens of connections with moderate load and jump to hundreds during peaks. I know from the experience that API users tend not to think about load they create on the other side, just hacking together series of wrapped calls.

Can you elaborate on "countless postmortems", please? On my work we recently had a 12 hours downtime on one of our 20 Mongo databases, but it was caused by a mistake during recovery from storage overflow. I will give a credit to Postgres here, by the way: on disk with 0 bytes free it still works in read-only mode.

Countless port-mortems or the same post-mortem recounted over and over?

As an employee of MongoDB we treat "catastrophic" failures of our software pretty seriously. If you have experienced a failure we want to hear about. Paying customer or no...

I haven't had any real contact to speak of with MongoDB in years, so my previous comment was uncalled for. I'm sorry for that strong sentence. Not to excuse that kind of claim, but I was indeed strongly triggered by SergeAx comment.

I've heard that MongoDB has improved a lot over the years, so I really shouldn't have said that.

No worries. We have improved over the years. I joined 8 years ago and it is a very different product today. Appreciate your comments.

I really don't understand the hate on MongoDB. There are plenty of failures on PostgreSQL or any other database you care to name, especially if you go back far enough in time. Any installed database with less than 10 years of prod deployments is going to have problems sooner or later. I can't think of any significant exceptions.

> Alas, it seems to me that Postgres is not really production-ready.

It is production ready as long as you want to run it on a single box and scale vertically - which is a lot of projects out there. Agree on the other points.

Having a single point of failure in the form of a single box database is the stuff nightmares are made of for me. Even for the least critical things I've deployed as an SRE, redundancy is a must. It costs so little upfront, and can be life saving later on.

For my pet projects I want more reliability than for work ones. At work we can afford dedicated SREs and PagerDuty and on-call shifts and stuff. As an individual developer I want things to just work and deal with problems when I am awake and not busy with more important tasks.

(Please, don't mention Redis it is not database, and its failover is for availability but no consistency)

You are right. Despite I love PostgreSQL, MongoDB is eons ahead in terms of replication and sharding.

Mongo solves it by not being ACID compliant, which is sort of a big deal. This is like comparing apples to watermelon. Essentially, mongo solves this the same way redis does, but you said redis doesn't count as a database.

Also, it is possible to horizontally scale postgres. It's not for the light of heart, but the easiest way is with read only replicas, which is pretty easy (especially with RDS), and read heavy loads are where postgres really shines, and also most apps out there.

MongoDB is ACID compliant. Yes, I know someone will post the 18 month old Jepsen report, but the fact is those issues were fixed almost immediately. The Jepsen test suite continues to be part of MongoDB's release testing.

I am strongly against treating Redis as yet another cache. For me it is a perfect database for non-critical short-lived data, that can be reproduced from more reliable databases in case of failure.

Reply on news.ycombinator.com