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....
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.
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.
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.
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....