Hacker News new | comments | show | ask | jobs | submit login

As a large commercial user of MongoDB (almost 300 instances of it running in production), I've seen some big shifts in 10gen's focus lately. They've really ramped up the customer service, and they are making more regular releases that seem like improvements.

Unfortunately, the better customer service doesn't provide better answers or solutions to problems, and the improvements aren't targeting long standing, basic issues with the platform.

This feature announcement fits the pattern: an improvement, but not in a critical area like indexing, or document-level locking, sharding stability, etc. There are basic fundamentals that need addressing like overcoming the 20K maximum connections per server, or mongos CPU usage. These are the things I deal with in production and that are business critical, but those feature requests sit untouched in JIRA for months or years.

This feature seems interesting, but it solves a problem I don't have. I'd prefer them to solve real world problems.

Why do you need > 20k connections to your database?

Because I want to run more than 100 instances of a webserver per mongos process, but I can't because it causes the connections per server to go over 20K.

Right now my application stack is woefully under utilized due to this completely arbitrary decision on their part not to allow the end user to set the connection limit. They've even admitted that they just picked that number four years ago and haven't looked at it since.

Just like they limit replica sets to 12 members maximum. What if I have higher read requirements than that limitation allows? Well, too bad.

I think this points at a fundamental issue with MongoDB at the design level - they don't allow end users to make any decisions about how to configure the product, even if those decisions might turn out bad.

Every Enterprise-level DB allows end user tuning of parameters, so clearly MongoDB isn't Enterprise-level.

The 20,000 connection limit was removed in 2.5: https://jira.mongodb.org/browse/SERVER-8943

Most likely because the users runs a high number of workers or mongoses.

>This feature seems interesting, but it solves a problem I don't have. I'd prefer them to solve real world problems.

I think it is a little much to equate problems you have with being the only real world problem. Perhaps it's a real world problem that you don't have?

The problems I'm having with MongoDB at scale effect everyone at scale - server connection limits, data size, index inefficiencies, driver bugs and so on.

These aren't edge cases specific to my environment. They are very real, very visible issues that are discussed on the mailing lists all the time.

Guidelines | FAQ | Support | API | Security | Lists | Bookmarklet | Legal | Apply to YC | Contact