Mongo DB Interview Questions

SQL databases store data in tables consisting of rows and columns, where every row follows the same predefined schema. Before storing data, developers must design tables and define relationships using primary and foreign keys.

MongoDB, on the other hand, stores information as documents inside collections. Each document can have its own structure, allowing some documents to contain additional fields without affecting others. Instead of relying heavily on joins, MongoDB often stores related data together inside the same document, reducing the need for multiple queries.

In short, SQL databases emphasize structured relationships and consistency, while MongoDB emphasizes flexibility, scalability, and rapid development.

MongoDB organizes data in a hierarchical structure.

At the top level is the Database, which contains one or more Collections. A collection stores multiple Documents, and each document contains key-value pairs.

Unlike SQL tables, documents inside the same collection do not need to have identical fields.

{
    "_id": 101,
    "name": "Laptop",
    "price": 70000,
    "brand": "Dell"
}

Outout
Document Inserted

MongoDB stores data as BSON (Binary JSON) instead of plain JSON.

BSON extends JSON by supporting additional data types such as:

• Date

• ObjectId

• Decimal128

• Binary Data

• Regular Expressions

Using BSON allows MongoDB to process and retrieve data efficiently while preserving rich data types that standard JSON cannot represent.

{
    "_id": ObjectId("687d123456789abcdef12345"),
    "createdAt": ISODate("2026-07-31")
}

Output
BSON Document Saved

Every MongoDB document automatically receives a unique ObjectId if one is not provided.

An ObjectId consists of 12 bytes and includes information such as:

• Timestamp

• Machine Identifier

• Process Identifier

• Incrementing Counter

Because of this structure, ObjectIds are globally unique and are generated without requiring a central server.

They are commonly used as the primary identifier for documents.

A collection is similar to a table in concept because both group related data together. However, a collection is much more flexible.

In a SQL table, every row must follow the same schema. If you want to add a new column, the table structure must be altered.

In MongoDB, documents within the same collection can contain different fields. This flexibility makes it easier to evolve applications without frequent schema migrations.

CRUD represents the four basic database operations:

• Create – Insert new documents.

• Read – Retrieve existing documents.

• Update – Modify existing documents.

• Delete – Remove documents.

These operations form the foundation of almost every MongoDB application.

MongoDB provides several methods for retrieving data.

The most commonly used methods are:

• find() – Returns multiple matching documents.

• findOne() – Returns the first matching document.

• countDocuments() – Counts matching records.

Queries can also include filters, projections, sorting, and pagination.

Indexes improve query performance by allowing MongoDB to locate documents quickly without scanning the entire collection.

Without an index, MongoDB performs a collection scan, checking every document until it finds a match.

With an index, MongoDB can jump directly to the required documents, making searches much faster, especially in large collections.

However, indexes also consume storage space and slightly slow down insert and update operations because the indexes must be maintained.

Although MongoDB is schema-flexible, it also supports Schema Validation to ensure documents follow specific rules.

Validation allows developers to define required fields, data types, minimum and maximum values, and other constraints before documents are inserted.

This helps maintain data quality while still preserving MongoDB's flexibility.

db.createCollection("users", {
    validator: {
        $jsonSchema: {
            bsonType: "object",
            required: ["name", "email"],
            properties: {
                name: {
                    bsonType: "string"
                },
                email: {
                    bsonType: "string"
                }
            }
        }
    }
})

Output 
Inserted Successfully

A transaction allows multiple database operations to be executed as a single unit of work.

If every operation succeeds, MongoDB commits the transaction.

If any operation fails, MongoDB rolls back all changes, ensuring data consistency.

Transactions are useful in scenarios such as:

• Banking Systems

• Payment Processing

• Order Placement

• Wallet Transfers

const session = client.startSession();

session.startTransaction();

await users.updateOne(
    { _id: 1 },
    { $inc: { balance: -500 } },
    { session }
);

await users.updateOne(
    { _id: 2 },
    { $inc: { balance: 500 } },
    { session }
);

await session.commitTransaction();

Output
Transaction Committed Successfully

Replication is the process of maintaining multiple copies of the same data across different servers using a Replica Set.

A typical replica set consists of:

• One Primary Node

• One or More Secondary Nodes

The primary node handles write operations, while secondary nodes continuously replicate data from the primary.

If the primary server fails, MongoDB automatically elects a new primary, ensuring high availability and minimizing downtime.

Sharding distributes data across multiple servers called shards.

Instead of storing all documents on one machine, MongoDB divides the dataset into smaller portions based on a shard key.

This allows the database to handle:

• Massive datasets

• High write traffic

• High read traffic

• Millions of users

As data grows, additional shards can be added without replacing existing hardware.

Optimizing MongoDB queries involves reducing unnecessary work and ensuring that queries access data efficiently.

Some best practices include:

• Create indexes on frequently searched fields.

• Retrieve only the required fields using projections.

• Filter documents before sorting whenever possible.

• Use pagination instead of loading all records.

• Design collections to match application query patterns.

• Avoid unnecessary large documents.

• Analyze slow queries using the explain() method.

By combining proper indexing with efficient query design, applications can handle larger datasets with better performance.

Embedding means storing related data inside the same document.

It works best when:

• The related data is always accessed together.

• The embedded data is relatively small.

• The data rarely changes independently.

• There is a one-to-one or one-to-few relationship.

For example, a user's address is usually embedded because it belongs only to that user and is commonly retrieved with the user's profile.

{
    "name": "Kartik",
    "address": {
        "city": "Delhi",
        "state": "Delhi",
        "pin": "110001"
    }
}

Output 
User Profile Loaded
↓
Address Loaded Together