Introduction to MongoDB. Examples of document queries.

In this project, queries will be created and defined in MongoDB for a hypothetical database belonging to an instant messaging app. The statements for the MongoDB shell and the results obtained in each of the sections are provided.

What this MongoDB guide covers

The article works as a compact MongoDB query notebook. Each example starts from a concrete requirement, shows the shell command and explains why operators such as $gt, $lt, $elemMatch, $regex or aggregate are useful when data is stored as nested documents instead of relational tables.

If you are comparing document databases with other NoSQL models, this page is best read together with basic NoSQL concepts and models and the updated overview of what MongoDB is used for.

Find in the collection `Usuarios_Individuales` the users from Madrid who are between 20 and 40 years old, excluding those who are 20 or 40. Show them ordered descending by age, listing only their email and age.

The query performed is the following:

With the following result

The most interesting part of this query is the use of `$gt: 20` and `$lt:40`. These two tags allow us to find users who are between 20 and 40 years old without including those who are exactly 20 or 40.

List the names of the blocking users in the collection `Bloqueos` who created a block between 9:25 and 10:00.

This query has an additional difficulty compared with the previous one. In this case we are going to search inside a subdocument, so it is necessary to use `$elemMatch` to obtain the desired result.

The results with time verification are:

Without the verification:

Find how many documents in the collection `Grupos_usuarios` have:

Identifier `(G-nnnn)` ending in an even number, that is, `nnnn` is even,
`Id_propietario (U-mmmm)` ending in an even number, that is, `mmmm` is even

In this query I use `$regex` to determine whether it is an even number or not.

The results were:

The result of the second command is: 11

List the first name and surname of the users in the collection `Usuarios_desbloqueadores` who have created at least one unblock action in the month of October, between 10 and 15 hours, with 15 included.

The results were:

Following the requirements of the statement, I obtain:

For the collection `Grupos_usuarios`, find the cities that have more than 15 members older than 35. List the cities found in descending order by number of members.

In this case I used `aggregate` to solve the requirement. In this way I grouped the information and selected what interested me. To select the desired subdocuments I used the `$match` stage and to group them I used `$group`.

Conclusion

These examples show why MongoDB is useful when the application naturally works with documents that contain nested fields, arrays and variable structures. Simple filters are readable, but the most important part is learning when to use array operators and aggregation stages so that the query expresses the shape of the stored document.

For production systems, the next step would be to review indexes, expected query frequency and document growth. A query that is clear in a learning dataset may need a compound index or a different document design when the collection grows.

Indexing and data-model notes

The examples are intentionally written for learning, but the same requirements in a real messaging application would need indexes. Filtering by city and age, searching nested arrays or grouping by member attributes can become expensive when collections grow. Before moving a query to production, run explain(), inspect whether MongoDB uses an index and measure how many documents are scanned.

A second decision is whether the nested structure is still convenient. Embedding users inside groups makes some reads simple, but it can create update pressure when the same user data appears in many documents. MongoDB is most effective when the document model follows the access pattern: store together what is read together, and reference data that changes independently.

Common mistakes when learning MongoDB queries

Beginners often translate SQL tables directly into MongoDB collections and then wonder why the model feels awkward. MongoDB is not only a different syntax; it encourages a different way of grouping information. Before writing queries, describe the screens and operations the application needs: list conversations, search users, count group members or detect blocked accounts. The document model should make those operations natural.

Another common mistake is relying on regular expressions for everything. Regex is useful in a learning exercise, but in production it can be slow if the pattern cannot use an index. When search becomes central to the product, consider text indexes, normalized fields or a dedicated search service.