Our organisation will be abandoning MongoDB as our database in favour of a more reasonably spec'd DB due to this issue, including closing our Atlas accounts and backing out of future payments. This has permanently damaged the reputation of MongoDB in the eyes of our development team, who have agreed it will not be a generally production-ready candidate for any projects in future.

"People are using your product, and everyone is complaining about the same issue. You respond by saying this won't be addressed and that you're focusing on other critical problems. If people give up on your product, all the critical issues you're working on won't matter because there will be no returns. Why don't you listen to your customers a bit and make it more customer-centric? You won't get feedback from someone walking down the street; it will come from your users. Take every comment into account."

2025. . . . . . .

This should definitely be configurable by the customer. I don't understand why that's out of the question.

Sure, there are work arounds, but the customer should have the choice if their system can handle it.

It would be invaluable to me. I never understood why things like this aren't user configurable in the server config. the 100mb memory limit, the 16mb document limit. My server has 6 tb of ram for gods sake and almost 300 cpu cores, i think it can handle bigger documents

Hi Shameek

You wrote:
"At this time, MongoDB is not planning on increasing or making its document size limit configurable. This is due to fact that this large, customer-breaking change presents a significant element of risk for us"

Then don't make this a customer-breaking change - it doesn't need to be if it's an opt-in setting.

You wrote:
"At this time, we are focused on spending our time improving other critical facets of the MongoDB database."

Just a reminder that the 16 MB document size limitation is *the* critical facet of the MongoDB database as per your customers, and it's not even close, compared to the next most voted-on issue.

You wrote:
"I understand this may be frustrating as with certain use cases, having a configurable document size limit may be desirable. However, we have seen most use cases successfully achieve their same goal by working with a number of our workarounds."

The MongoDB team have spent years now Mongo-splaining to their customers how documents greater than 16MB aren't really what we want. There are many things to say about this, but I'll limit my comment to this: Through the passage of time - and the 16MB limit is now 13 years old as of 2024 - as we have moved from managing Gigabytes 13 years ago to managing Terabytes today - this attitude is becoming closer and closer to the proverbial "640KB ought to be enough for anybody".

You wrote:
"Thank you all for taking the time to leave this feedback and we apologize for the lack of activity on this ticket. Please reach out to me directly if there is further feedback or inquiry."

It's late - but not too late - to listen to and respect your customers by implementing the single most important issue to them.

Hi Shameek,

Thank you for taking your time to respond with a lengthy answer.

With the information you provide it's to some extend understandble to why this ticket is a "Can't Do".

Nonetheless, my hope from this discussion was that there might be a chance (and this would be my suggestion here) to see a branched alpha version with an increased document size to e.g. 32 MB so that your customers can try it out and see what breaking changes would occur.
IF step 1 worked out well, and many devs out there would already enjoy that huge gain, the document size could be made configurable (within a reasonable range of sizes) in a second, much later step.

Please let us know if it would technically be possible to increase to 32MB or if developers with the requiremend of larger documents than 16MB will have to work with that size restriction for an undefined long time.

Kind regards from Germany!
Marcel

Large change, yes. The rest, no. You've made the change before, the only thing stopping you is will. All of these other issues are solvable, if you want to solve them. You do not. Other databases have made such breaking changes to their protocols simply by supporting both the old and new protocols for a period, and new features require the new protocol. This isn't hard (though the implementation is anything but trivial). The idea that you're pitching these excuses *to a group of developers who have to solve hard problems like this before lunch on a daily basis* is quite patronising and tells us a lot about what you think of us.

I'll need to figure out how to unsubscribe from this because we will be moving from Mongo to something that does support this ("Postgres") in the foreseeable future. This ship has sailed.

If we're going to have to work around a document database's limitations by being relational, we definitely should be using a relational database which is going to handle this properly.

Good luck to those that remain, you have my condolences.

At this time, MongoDB is not planning on increasing or making its document size limit configurable. This is due to fact that this large, customer-breaking change presents a significant element of risk for us (e.g. validations customers are used to, drivers expecting documents to be a certain size, the current size limit of the MongoDB Wire Protocol being 48MB, etc.). At this time, we are focused on spending our time improving other critical facets of the MongoDB database.

I understand this may be frustrating as with certain use cases, having a configurable document size limit may be desirable. However, we have seen most use cases successfully achieve their same goal by working with a number of our workarounds. Please contact MongoDB Support or engage in the MongoDB Community Forums for more in-depth explanations and examples.

This feedback has not gone unheard; several products have made improvements to allow for most of the use cases mentioned here. Notably, this includes $changeStreamSplitLargeEvent, which can be used to split events greater than 16MB into smaller fragments.

Thank you all for taking the time to leave this feedback and we apologize for the lack of activity on this ticket. Please reach out to me directly if there is further feedback or inquiry.

I wonder if there's a better way to reach out to the developers.

Obviously our voices are being ignored for years. It's a real shame actually.

Mongodb team changed the document size to 16 MB in 2009; since then, compute power has gone up quite a bit, and 64MB should be very much doable.

I think one thing has been overlooked in this conversation and that is $graphLookup. I work in the media industry and we have a fairly complex hierarchical model. $graphLookup is crucial to handle swift retrieval of related and sizeable portions of of our data. Our documents are relatively small, probably around 10kb max, but performing the lookup essentially creates a massive document which can easily exceed the 16MB limit. We cannot even limit the data returned during the process, in an effort to artificially reduce the size. Now I do not know this for sure, but I would take an educated guess that the $graphLookup facility was added after the 16MB limit was defined but can easily threaten it and therefore maybe the limit should have been reviewed at the point $graphLookup was introduced in order to effectively support the new functionality?

Is this being worked on ?

This feature implementation is both critical and crucial!
Implementing a feature that allows administrators to configure the maximum BSON document size limit is the only way to go forward.

When using Splunk to import Active Directory groups, users, and computers, this limitation causes users to not see all their data beyond some tens of thousands of objects. Many larger AD environments have more than this. They must reconfigure inputs to pull in one piece at a time, which causes delays and frustration. If MongoDB would increase this limit to 64MB, this could help modern IT shops manage their data more easily with Splunk. This is just one more use case to add to the list of reasons to increase this limit from 2009 or 2011.

Limit is good, 16MB as a default is ok, 64MB is even better but to make MongoDB flexible and suitable for even more use cases, limit should be configurable.

How can you still think 16MB are enough in 2023? You defined this limit in 2011.
We have more data, larger document, sensors, socials, please raise the limit to 64MB.

I see a lot of "you're doing it wrong" comments in this thread: https://www.mongodb.com/community/forums/t/increase-max-document-size-to-at-least-64mb/124424/28 from Asya Kamsky. Unfortunately 5G configuration data cannot be broken out into separate collections/documents. It absolutely HAS to be in a single document. If the document size cannot be increased then unfortunately my organization WILL have to go to Couchbase to store our 5G data.

Is this being worked on? any update?

This limitation is a serious risk for a lot of production systems.
The only way to safely stay under the document size limit is to use MongoDB as a relational database: wherever a record might contain any non-fixed size lists, you have to put those in separate documents, as once in a million times everything _will_ grow longer than you've expected.
And once any of the document reaches 16MB, your production system is broken. You can patch up your system, to split that new thing that became too long in the "offending" document, but that is not operation/support, it's a never-ending crisis managent.
And once you've split them all up, you will realise that you are using MongoDB as a relational database, just without rdbms features. It just defeats the purpose.

Saying that 16MB is the maximum _recommended_ document size is all fine, a design can easily be built around it, ensuring that the wast majority of documents is going to fit within that size. And anything above that will be significantly slower. Once in a million, it can be slow all right. But if a document above the limit can not be handled at all with the system without significant development, that renders the system highly vulnerable and completely intolerant to a lot of unexpected events (and to DOS attacks). Which very significantly limits it's usability.