First off, this actually is being raised in the next version to 8MB
or 16MB
... but I think to put this into perspective, Eliot from 10gen (who developed MongoDB) puts it best:
EDIT: The size has been officially 'raised' to 16MB
So, on your blog example, 4MB is
actually a whole lot.. For example,
the full uncompresses text of "War of
the Worlds" is only 364k (html):
http://www.gutenberg.org/etext/36
If your blog post is that long with
that many comments, I for one am not
going to read it :)
For trackbacks, if you dedicated 1MB
to them, you could easily have more
than 10k (probably closer to 20k)
So except for truly bizarre
situations, it'll work great. And in
the exception case or spam, I really
don't think you'd want a 20mb object
anyway. I think capping trackbacks as
15k or so makes a lot of sense no
matter what for performance. Or at
least special casing if it ever
happens.
-Eliot
I think you'd be pretty hard pressed to reach the limit ... and over time, if you upgrade ... you'll have to worry less and less.
The main point of the limit is so you don't use up all the RAM on your server (as you need to load all MB
s of the document into RAM when you query it.)
So the limit is some % of normal usable RAM on a common system ... which will keep growing year on year.
Note on Storing Files in MongoDB
If you need to store documents (or files) larger than 16MB
you can use the GridFS API which will automatically break up the data into segments and stream them back to you (thus avoiding the issue with size limits/RAM.)
Instead of storing a file in a single document, GridFS divides the file into parts, or chunks, and stores each chunk as a separate document.
GridFS uses two collections to store files. One collection stores the file chunks, and the other stores file metadata.
You can use this method to store images, files, videos, etc in the database much as you might in a SQL database. I have used this to even store multi gigabyte video files.