Best practice max fields in a document

Is there a best practice maximum number of fields in a document ?


Welcome to the community @Normand_Rioux!

There isn’t a prescriptive maximum number of fields per document, but you should consider the relationships of fields in the same document and ensure that your data model efficiently supports your common use cases and indexing requirements. There are definite anti-patterns like having too many fields with unrelated data or array fields with unbounded growth, but interpreting those usually requires some understanding of your use case and data.

If you have a specific example of a data model you are considering (or working with), I suggest starting a new discussion topic on the forum with more details (example documents, common queries, planned indexes, version of MongoDB server, and your specific questions/concerns). It is likely that someone in the community will have useful suggestions.

Some worthwhile reads include:

There’s also a free online course at MongoDB University if you want some hands-on practice with video lectures & quzzes: M320: Data Modeling.


Hi Stennie,
Thx for your answer. :smiley:
Basically the collections are Products, Vendors, Customers etc.
And the documents can have 150-200 fields.
I was wandering if there would be a performance problem with this amount of fields hence my question?
I am taking the MongoDB university courses but it mostly deals with 10-15 fields which is not big.

Hi @Normand_Rioux,

As I mentioned, the consequences depend on how you use the data rather than a strict number of fields. The MongoDB University examples tend to be concise for clarity, but modelling more complex data (like products) can easily take more than a handful of fields.

Please have a read through the Patterns & Anti-Patterns series I mentioned, as those go into very helpful detail on schema design.

For example, in the case of products you will probably want to use the Attribute Pattern to reduce the number of indexes needed (which should generally improve performance). Some anti-patterns to watch out for would be combining many fields that aren’t accessed together into a large document (aka Bloated Documents) and creating Massive Arrays with unbounded growth.

If you have a single document with 200 fields but commonly only needed to read 10, the server still has to load the full document into memory (outside of the very special case of a covered query), but an anti-pattern would be separating data that is accessed together.

The best approach to model your data is informed by your common queries and use cases. You can certainly have hundreds (or thousands) of fields in a document if that is appropriate. There are also patterns like Subset and Outlier that are helpful to consider when working with portions of related data.

Modelling data to support efficient usage (rather than normalising for storage) is a key differentiator for effective use of MongoDB, but is a definite mindset shift from working with tabular data in SQL.


1 Like

This topic was automatically closed 5 days after the last reply. New replies are no longer allowed.