DEV Community: VisuaLeaf

How to Import JSON into MongoDB and Export to CSV with Data Masking

VisuaLeaf — Thu, 23 Jul 2026 09:20:23 +0000

Every morning, an online store receives the previous day’s orders from a marketplace partner.

The file comes in JSON format. The company needs to add those orders to its main MongoDB orders collection. The sales manager also needs a CSV report that can be opened in Excel.

That sounds like a small task. Import the file, copy the documents, export the report.

But in practice, a few things can break the process.

A date can be imported as a string. A field can have the wrong name. One batch may use total, while the main collection uses totalAmount. A temporary collection can keep old records and trigger duplicate key errors. A CSV export can create null values because the mapping points to fields that do not exist.

And then there is customer data. The manager may need the sales numbers, but they probably do not need real customer names or internal customer IDs.

This article walks through a real daily workflow:

Import marketplace JSON
        ↓
Store the batch in a temporary MongoDB collection
        ↓
Copy the orders into the main orders collection
        ↓
Mask customer fields during export
        ↓
Create a CSV report

The goal is not just to move data from JSON to CSV. The goal is to make the process repeatable, easier to check, and safer to share.

The workflow

The workflow has three jobs:

Import Yesterday Orders
        ↓
Add Orders to Main
        ↓
Export Daily Sales Report

The important part is the parent relationship between the jobs.

Add Orders to Main depends on Import Yesterday Orders, so it only runs after the JSON file is imported successfully.

Export Daily Sales Report depends on Add Orders to Main, so the CSV is created only after the main orders collection has been updated.

This prevents the report from being generated when data is missing or incomplete.

The incoming JSON file

The partner sends a file with yesterday’s completed orders.

A single order looks like this:

{
  "orderId": "ORD-2026-07-201",
  "customerId": "CUST-1003",
  "customerName": "Sofia Rossi",
  "orderDate": "2026-07-21T08:20:00Z",
  "status": "completed",
  "paymentStatus": "paid",
  "currency": "EUR",
  "items": [
    {
      "sku": "EL-002",
      "productName": "Wireless Mouse",
      "category": "Electronics",
      "quantity": 1,
      "unitPrice": 24.99,
      "lineTotal": 24.99
    },
    {
      "sku": "EL-003",
      "productName": "Mechanical Keyboard",
      "category": "Electronics",
      "quantity": 1,
      "unitPrice": 79.99,
      "lineTotal": 79.99
    }
  ],
  "itemsSummary": "1x Wireless Mouse, 1x Mechanical Keyboard",
  "itemCount": 2,
  "subtotal": 104.98,
  "discount": 10,
  "shippingFee": 4.99,
  "totalAmount": 99.97,
  "couponCode": "WELCOME10"
}

There are two fields worth pointing out here.

The first is items. This is the real order structure. It keeps each product as a nested object with its own SKU, quantity, price, and line total.

The second is itemsSummary. This is not as rich as the items array, but it works better in a CSV report. Instead of putting a full JSON array into one spreadsheet cell, the manager sees a readable value:

1x Wireless Mouse, 1x Mechanical Keyboard

MongoDB handles nested arrays well. CSV does not. So for the database, keep the array. For the report, export the summary.

The first job imports the file into a temporary collection:

online_store.daily_sales_import

Why use a temporary collection?

The first job imports the JSON file into online_store.daily_sales_import instead of writing directly to orders.

This extra step is worth it.

The file comes from another system. Even if the partner usually sends the correct structure, a single change can break your report. A field can be renamed. A value can arrive as text instead of a number. A date can be formatted differently. Or the import job can use an old field mapping from another file.

The temporary collection gives you a place to check the batch before it becomes part of the main order history.

If it keeps old documents, the next run may copy the same orders again. That can cause duplicate key errors later.

Generate field mappings every time the JSON structure changes

This is the easiest step to skip, and it is also where a lot of bad imports start.

When you select the JSON file, click:

Generate Field Mappings

For this order file, the mapping should include:

_id           → _id
orderId       → orderId
customerId    → customerId
customerName  → customerName
orderDate     → orderDate
status        → status
paymentStatus → paymentStatus
currency      → currency
items         → items
itemsSummary  → itemsSummary
itemCount     → itemCount
subtotal      → subtotal
discount      → discount
shippingFee   → shippingFee
totalAmount   → totalAmount
couponCode    → couponCode

If you do not regenerate the mappings, the job may reuse fields from an older import.

For example, if the previous import was a customer file, the mapping may still expect fields like:

country
email
joinedAt
name
customerId
status

The import may still run. But the order fields will be missing, and the result will look wrong. You may see null values or documents that only contain a few shared fields like customerId and status.

That is not a MongoDB issue. It is a mapping issue.

Copy the batch into the main orders collection

The second job copies documents from:

daily_sales_import

into:

orders

This job should use Import Yesterday Orders as its parent.

A simple configuration is:

Source: online_store.daily_sales_import
Target: online_store.orders
Mode: Insert or Append
Parent: Import Yesterday Orders

Use insert or append because you are adding new orders to the order history.

Do not use replace mode on orders unless you really want to overwrite the full collection.

The main collection should keep all orders. The temporary collection should only hold the latest imported file.

Duplicate key errors are useful, but they still need a fix

If you run the same batch twice, MongoDB may return this error:

E11000 duplicate key error

That means MongoDB blocked a duplicate value for a unique field, often _id or orderId.

This is usually good. It stops the same order from being inserted twice.

But in a daily workflow, the error also tells you something is wrong with the process.

Common causes:

The temporary collection was not cleared.
The same JSON file was imported twice.
The partner sent duplicate order IDs.
The copy job tried to insert records already present in orders.

In testing, the temporary collection is often the problem.

If daily_sales_import contains old records and new records, the copy job tries to insert all of them. MongoDB accepts the new ones and rejects the duplicates.

The fix is simple: clear or replace the temporary collection before each new import.

Export the weekly report from the main collection

The company imports marketplace orders every day, so the main MongoDB orders collection stays up to date.

But the manager does not need a CSV file every morning. In this case, the manager needs a weekly sales report.

That changes the source of the export job.

If you export from daily_sales_import, you export only the latest imported batch.

If you export from orders, you export the main order history, including the orders that were imported during the week.

For this workflow, the export job uses:

Source: online_store.orders
Output: weekly-sales-report-{{yyyy-MM-dd}}.csv
Parent: Add Orders to Main

The parent relationship still matters. The weekly CSV should be created only after the latest imported orders have been added to the main orders collection.

This gives the manager one report with the updated sales data, instead of sending a separate file every day.

Mask customer data during export

The manager needs sales data, but they do not need the real customer name or internal customer ID.

Instead of changing the original MongoDB documents, the export job applies masking only in the CSV output.

In this workflow:

customerId   → hash(value)
customerName → maskName(value)

This keeps the original data intact in MongoDB, while the exported report hides sensitive customer details.

What maskName(value) does

The maskName(value) transformation keeps the first character and replaces the rest with asterisks.

Example:

Alex Ionescu → A***********
Mia Thompson → M***********

It does not create a fake name.

It masks the original value. The report still has a customer-name column, but the real name is hidden.

This is useful when the report needs to show that a customer exists, but not who the customer is.

What hash(value) does

The hash(value) transformation changes the customer ID into a hashed value.

Example:

CUST-1002 → 043a5f9b...

The same input should produce the same hashed output.

That means the report can still show that two orders belong to the same customer without exposing the original customer ID.

Example:

Original customerId: CUST-1002
Masked customerId:   043a5f9b...

Original customerId: CUST-1002
Masked customerId:   043a5f9b...

This is useful for analysis.

The manager can group orders by the masked ID, but they cannot see the real internal ID.

Schedule the workflow

Once each job works on its own, schedule the full workflow.

The final process is:

Receive marketplace JSON
        ↓
Import the daily batch
        ↓
Add orders to MongoDB
        ↓
Mask customer details
        ↓
Export the CSV report

Set the schedule to run every morning at 09:00.

The parent relationships keep the jobs in order.

The report does not run before the copy job. The copy job does not run before the import job.

That is the main reason to use a workflow instead of three separate jobs.

What this workflow actually solves

This workflow is not only about converting JSON to CSV.

It solves a real process that many teams deal with: marketplace data comes in one format, MongoDB stores the operational data, and the manager needs a spreadsheet they can review without seeing unnecessary customer details.

In this setup, the daily JSON file is imported into daily_sales_import. Then the new orders are copied into the main orders collection. At the end, the weekly CSV report is created from the updated orders collection.

Before the CSV is exported, sensitive customer fields are masked:

customerName → A***********
customerId   → 043a5f9b...

The original MongoDB documents stay complete. Only the exported report hides customer details.

This makes the process repeatable, easier to check, and safer to share.

Final result

At the end, you have one scheduled workflow that handles the daily marketplace file and keeps MongoDB up to date.

You avoid repeating the same import and export steps by hand. You reduce the chance of copying old batches again. You keep the report readable with fields like itemsSummary. And you share the sales data without exposing the original customer identities.

The small details still matter: generate the mappings when the JSON structure changes, keep field names consistent, store dates as DATE_TIME, and preview the export before trusting the CSV.

Once those pieces are set, the workflow is easier to run, easier to check, and safer to share.

I built this example in VisuaLeaf using Task Manager and export transformations.

If you work with MongoDB imports, scheduled exports, or masked reports, you can try it here: https://visualeaf.com/download

How to Copy and Sync a Local MongoDB Collection to Atlas

VisuaLeaf — Mon, 20 Jul 2026 14:04:46 +0000

Moving data from a local MongoDB database to Atlas usually means exporting files, importing them again, and repeating the same process when something changes.

I wanted to test a simpler way in VisuaLeaf: copy a local collection to MongoDB Atlas and keep the Atlas collection updated automatically.

For this example, I used a local visits collection containing seven documents. The documents included ordinary fields, nested objects, arrays, dates, and ObjectIds, so I could also check whether the original MongoDB structure remained intact in Atlas.

Here is the complete process, followed by an insert, update, and delete test.

What I used

My source and target were:

Role	Connection	Database	Collection
Source	`Local Replica Set`	`database_compare_demo`	`visits`
Target	`MongoDB Atlas`	`database_compare_demo`	`visits_atlas_sync`

I used a different target collection name so I could verify the copied data without mixing it with anything already stored in Atlas.

The local source was a replica set because continuous synchronization relies on MongoDB change streams. Change streams are available for replica sets and sharded clusters, not standalone MongoDB deployments. (MongoDB change streams)

If the source is standalone, the job can still perform an initial copy, but it cannot continue watching for later changes.

The local visits collection before it was copied to Atlas.

Preparing the Atlas connection

Before creating the sync job, I made sure VisuaLeaf could write to my Atlas cluster.

Before using a standard Atlas connection, I configured two access items:

A database user with permission to access the target database.
My computer’s public IP address added to the project’s IP access list.

Atlas database users are separate from the account used to sign in to the Atlas website. For this test, I used a database user with read and write access to database_compare_demo.

I added only my current IP address to the Atlas access list instead of allowing connections from every IP. Atlas only accepts standard client connections from addresses included in that list. (MongoDB Atlas connection prerequisites)

From the Atlas cluster’s *Connect* window, I copied the driver connection string. Its general format was:

mongodb+srv://<username>:<password>@<cluster-host>/

I used that URI to create a connection in VisuaLeaf and named it MongoDB Atlas. I tested the connection before continuing.

Creating the sync job

I opened *Mongo Sync* and created a new job with these details:

Setting	Value
Job name	`Local Visits to Atlas`
Description	`Copy local clinic visits to Atlas and keep later changes synchronized.`
Source connection	`Local Replica Set`
Source database	`database_compare_demo`

The source connection showed full change-stream support, which meant I could select Full sync later.

The local replica set and database_compare_demo database selected as the source.

Mapping the local collection to Atlas

In the Rules step, I added the Atlas connection as the target and configured one rule:

Setting	Value
Target connection	`MongoDB Atlas`
Target database	`database_compare_demo`
Source collection	`visits`
Target collection	`visits_atlas_sync`
Filter	Empty
Transformation	`None (pass-through)`

I left the filter empty because I wanted all seven documents.

I also used *None (pass-through)* instead of generating field mappings. Both sides were MongoDB, so I wanted to preserve each document exactly as it was, including its _id, nested objects, arrays, dates, and optional fields.

Field mappings are useful when renaming fields, changing types, masking values, or sending data into a different schema. They were unnecessary for this direct MongoDB-to-MongoDB copy.

The visits collection mapped to visits_atlas_sync with pass-through documents.

Choosing Full sync

The Options step offered three modes:

Mode	What it does	When to use it
Initial Only	Copies the documents that currently exist, then stops	One-time collection copy
Incremental Only	Watches only for changes made after the job starts	The target is already populated
Full sync	Copies existing documents and then watches for later changes	Initial copy plus continuous synchronization

I selected *Full sync* and enabled Start sync immediately after creation.

This mode first copies the seven documents already stored locally. After the initial phase finishes, it continues listening for new inserts, updates, and deletes.

Full sync copies existing documents and continues watching the local collection.

Reviewing and launching the job

The Review screen showed:

Local Replica Set / database_compare_demo as the source;
MongoDB Atlas / database_compare_demo as the target;
one rule from visits to visits_atlas_sync;
no filter or transformation;
Full sync with automatic start.

It also estimated an initial copy of approximately seven documents.

The complete local-to-Atlas configuration before launching the job.

I clicked *Create & launch* and waited for the initial phase to finish. Once the monitor showed that the job was running and waiting for changes, I checked the Atlas collection directly.

The initial copy is complete and the job is monitoring later changes.

Verifying the initial copy in Atlas

I opened database_compare_demo.visits_atlas_sync on the Atlas connection and counted its documents:

db.visits_atlas_sync.countDocuments({})

The result was 7, matching the local source collection.

I also opened several documents and checked their BSON types. The ObjectIds, dates, nested patient and doctor objects, and arrays were preserved because the job used pass-through documents rather than converting them into a new schema.

The initial count proved that the collection was copied. It did not yet prove that the Full sync job would handle later changes, so I tested each main operation separately.

Test 1: Inserting a new local document

I inserted one clearly labeled test visit into the local source:

Insert a new document into the local connection.

Then I searched for the same visitId in Atlas:

db.visits_atlas_sync.findOne({
  visitId: "VIS-ATLAS-TEST"
})

A new local visit appears automatically in the Atlas collection.

The new document appeared in the target collection without restarting or recreating the job. The target count increased from seven to eight.

Test 2: Updating the local document

Next, I updated both a top-level field and a nested field:

db.visits.updateOne(
  { visitId: "VIS-ATLAS-TEST" },
  {
    $set: {
      status: "completed",
      "doctor.roomNumber": "204",
      updatedAt: new Date()
    }
  }
)

I checked the Atlas document again:

Top-level and nested changes from the local document are visible in Atlas.

Test 3: Deleting the local document

Finally, I deleted the test document from the local collection:

db.visits.deleteOne({
  visitId: "VIS-ATLAS-TEST"
})

I verified the target one more time:

db.visits_atlas_sync.countDocuments({
  visitId: "VIS-ATLAS-TEST"
})

Deleting the local test document removes its synchronized Atlas copy.

The result returned to 0, and the full Atlas collection returned to seven documents.

When this workflow is useful

This type of Mongo Sync job makes sense when I want to:

copy selected local collections to an Atlas development or staging environment;
keep a cloud copy updated while continuing to write locally;
move a collection without repeatedly exporting and importing JSON files;
test an application against Atlas using recent local data;
synchronize only the collections needed for a specific workflow.

The important word is *selected*. This was a collection-level sync, not a complete production migration.

Live MongoDB sync from local replica set to Atlas.

How this differs from other Atlas migration methods

MongoDB provides other tools for different jobs:

mongodump and mongorestore are useful for a self-managed, one-time transfer using a BSON dump.
Atlas Live Migration is designed for moving a deployment into Atlas and managing a production cutover with minimal downtime.
This Mongo Sync workflow focuses on copying selected collections and continuing to apply their changes.

Atlas recommends its Live Migration workflow when performing a supported production migration. It uses MongoDB’s mongosync technology underneath and includes a cutover process for redirecting applications to the Atlas destination. (Atlas Live Migration)

I would not present a collection-level sync as a replacement for that process.

What I would still verify before using it in production

This small test verified document copying and three change types. It did not test:

high write volume or very large collections;
long network interruptions and recovery;
schema changes while the job was running;
independent writes made to both source and target;
users, roles, indexes, validation rules, or other database metadata;
a full application cutover from local MongoDB to Atlas.

I treated the local collection as the source of truth and used an empty target collection. That kept the test easy to understand and avoided conflicts with existing Atlas documents.

Final takeaway

The first copy was easy to check: 7 local documents appeared in Atlas.

But the more important part was what happened after that. When I inserted, updated, and deleted a local document, the same changes appeared in Atlas without exporting another file or recreating the job.

Because both sides were MongoDB, I could use pass-through mode and keep the original document structure.

For development, staging, testing, or selected collection sync, this is a practical way to move local MongoDB data to Atlas and keep it updated. For a full production migration, I would still follow MongoDB’s official migration process and plan the cutover separately.

Want to try it?

Download for Free and test Mongo Sync with your own local MongoDB database and Atlas cluster.

References

7 MongoDB Query Mistakes That Return the Wrong Results

VisuaLeaf — Tue, 14 Jul 2026 09:39:05 +0000

MongoDB queries look simple. You type a field, give it a value, hit run, and you get your data back.

But just because a query runs without throwing an error doesn't mean it worked right. Sometimes you get a blank screen. Sometimes you get way too many records. Other times, the data looks fine at first glance, but it doesn't actually match what you asked for.

Most of these slip-ups happen for one basic reason: the query structure doesn't match the way the data actually sits in the database.

To show you what we mean, we’ll use a clinic database with a collection called visits. Here is what a typical document looks like:

JSON

{
  "_id": "6871b6f9c3f1d1a4c2a10001",
  "status": "completed",
  "visitDate": "2026-07-01T09:30:00.000Z",
  "patient": { "name": "Anna Keller", "age": 34 },
  "doctor": { "name": "Dr. James Carter", "specialty": "Cardiology" },
  "symptoms": ["cough", "fever"],
  "prescriptions": [
    { "name": "Ibuprofen", "active": false },
    { "name": "Paracetamol", "active": true }
  ],
  "invoice": { "paid": true, "method": "card", "total": 250 }
}

You can run these examples right in the VisuaLeaf MongoDB Shell. Using visual tools makes a big difference because you can see exactly what MongoDB is returning in real time.

1. Forgetting the Curly Braces

This is just a quick typo, but it breaks things right away.

The Mistake:

db.visits.find(status: "completed")

The Correct Query

The find() tool always expects an object. Even if you are only looking for one specific thing, you still need to wrap that condition in curly braces {}.

2. Treating `$or` Like a Regular Object

This one trips a lot of people up because the broken version looks like it should work.

The Mistake:

db.visits.find({
  $or: {
    status: "completed",
    "invoice.paid": false
  }
})

What is wrong:

$or expects an array of conditions, but this query gives it one object.

The error will usually be something like:

MongoServerError: $or must be an array

The Correct Query

The first query is wrong because $or needs an array, not one regular object.

Each condition has to be written as its own object inside [].

The corrected query returns visits where the status is pending or completed.

3. Querying Nested Fields Like They Are Flat

MongoDB documents often have fields inside other fields.

In our visits collection, doctor is an object:

doctor: {
  name: "Dr. Michael Brown",
  specialization: "Neurology"
}

Query to avoid:

db.visits.find({
  doctor: "Neurology"
})

This asks MongoDB to find a doctor field that is exactly "Neurology".

But doctor is not a string. It is an object.

Better query:

db.visits.find({
  "doctor.specialization": "Neurology"
})

The dot tells MongoDB to go inside the doctor object and check the specialization field.

So instead of asking:

Is the whole doctor field equal to Neurology?

you are asking:

Is the doctor’s specialization Neurology?

4. Typing the Same Field Twice

Say you want to find visits with doctors from Cardiology or Dermatology.

Query to avoid:

db.visits.find({
  "doctor.specialization": "Cardiology",
  "doctor.specialization": "Dermatology"
})

Better query:

In JavaScript and MongoDB, you should not reuse the same key within a single object.

If you type "doctor.specialization" twice, the second value can overwrite the first one. So MongoDB may only search for Dermatology.

If one field can match more than one value, use $in.

5. Treating Dates Like Plain Text

Dates can look like regular text, but in MongoDB they are often stored as real Date values.

In our visits collection, the invoice date is stored inside the invoice object:

invoice: {
  issuedAt: ISODate("2026-05-18T10:15:00Z")
}

So this query will not work as expected:

db.visits.find({
  "invoice.issuedAt": "2026-05-18"
})

This searches for a string, not a Date, so it will usually return nothing.

Better query:

This returns invoices created on May 18, 2026.

The range matters because dates usually include time. A visit at 1:15 PM is still on May 18, but it is not equal to midnight.

So instead of asking:

Is the date exactly "2026-05-18"?

you are asking:

Is the date on or after May 18 and before May 19?

6. Expecting Text Search to Work Automatically

MongoDB does not search text like Google by default.

In our visits collection, the doctor name is stored like this:

doctor: {
  fullName: "Dr. Michael Brown"
}

So this query will not work:

db.visits.find({
  "doctor.fullName": "Michael"
})

This searches for an exact value. MongoDB checks if doctor.fullName is exactly "Michael".

But the real value is "Dr. Michael Brown".

Better setup:

For text search, you need to create a text index first:

db.visits.createIndex({
  "doctor.fullName": "text"
})

Then you can search inside the text field:

Now MongoDB can search for the word Michael inside the indexed field.

The important part is this:

$text search does not work unless the collection has a text index.

7. Reading `$or` Logic Backwards

This query runs fine, but it is easy to read it *the wrong way*:

db.visits.find({
  status: "completed",
  $or: [
    { "doctor.specialization": "Neurology" },
    { "invoice.paymentStatus": "unpaid" }
  ]
})

This does not mean:

completed OR Neurology OR unpaid

It actually means:

completed AND (Neurology OR unpaid)

Because status is outside the $or block, MongoDB treats it as required.

So MongoDB first looks for visits where status is completed. Then, from those visits, it checks if the doctor is specialized in Neurology or the invoice is unpaid.

If you want all three conditions to be part of the OR logic, move status inside the $or array.

Better query:

db.visits.find({
  $or: [
    { status: "completed" },
    { "doctor.specialization": "Neurology" },
    { "invoice.paymentStatus": "unpaid" }
  ]
})

Now the query means:

completed OR Neurology OR unpaid

Same fields. Different structure. Different result.

One More Thing to Do before Using Your Query

A MongoDB query is only as good as your understanding of the underlying document structure.

Before you spend hours rewriting a broken query, do one simple thing: Open a single raw document from your collection.

Look closely at the exact spelling of field names.
Check the data types (Are numbers stored as strings? Are dates stored as objects?).
Map out your nested objects.

This is exactly where a visual tool like VisuaLeaf saves the day. Instead of guessing from your code editor, you can test your queries inside the built-in shell and instantly toggle over to the Table View or Tree View to see exactly how your documents are laid out in real-time. No more guessing.

DBeaver Alternative for MongoDB Queries, Aggregations, and Visual Workflows

VisuaLeaf — Wed, 08 Jul 2026 13:29:52 +0000

DBeaver is a strong tool if you work with many databases.

It makes sense for teams using PostgreSQL, MySQL, SQL Server, Oracle, and MongoDB in the same place. But if most of your work is in MongoDB, the workflow matters more.

DBeaver does support MongoDB, but according to its documentation, the MongoDB driver is available in Lite, Enterprise, and Ultimate editions only. So this is not about saying DBeaver cannot work with MongoDB. It can, if you pay for those versions.

Many developers stick with DBeaver because they are comfortable writing SQL. But VisuaLeaf bridges that gap natively with its own SQL Mode, allowing you to write standard SQL queries that automatically translate into optimized MongoDB syntax.

The question is whether you want a broad database tool, or a workspace built more directly around MongoDB documents, queries, aggregations, schemas, and charts.

That is where VisuaLeaf fits better.

It is focused on MongoDB workflows, not every database type at once.

" width="800" height="480">

VisuaLeaf brings MongoDB queries, schema diagrams, charts, dashboards, and team workflows into one visual workspace.

Why MongoDB Users May Want a Different Tool

MongoDB work is usually more visual than people expect.

You are not only reading rows, but you are also checking what is inside each document.

You are opening nested objects, or you are filtering by fields that may or may not exist in every record.

You are building aggregation pipelines and trying to understand what changes after each stage.

A general database tool can help, but it may not always feel built for this kind of work.

VisuaLeaf is designed for the daily MongoDB tasks that users actually repeat:

-> querying data, reading documents, building aggregations, checking schemas, creating charts, and working with collections more visually.

Build MongoDB Queries Visually

Writing MongoDB queries by hand is useful.

But not every filter needs to start with code.

Sometimes you just want to find documents where status is paid, sort them by date, limit the results, and check the output.

In VisuaLeaf, you can build that query visually.

You add filters, combine conditions, sort results, and see the generated MongoDB query behind it.

That last part matters.

The tool does not hide the query from you. It helps you understand it.

So if you are learning MongoDB, you can see how the query is created.

And if you already know MongoDB, you can move faster without typing every condition from scratch.

" width="800" height="480">

Build MongoDB queries visually and keep the generated code visible.

Build Aggregation Pipelines Step by Step

Aggregation pipelines are powerful, but they can get hard to read fast.

A pipeline with one $match stage is simple.

A pipeline with $match, $group, $sort, $project, $lookup, and $unwind is different.

At that point, the problem is not only writing the syntax.

The problem is knowing what happened to the data after each stage.

VisuaLeaf lets you build aggregation pipelines visually and check the output as you go.

You can add a stage, see the result, then continue.

That makes it easier to find mistakes, test ideas, and explain the pipeline to someone else.

You are not guessing what the pipeline does. You can see it.

" width="800" height="480">

Build MongoDB aggregation pipelines step by step with live preview

Read MongoDB Documents More Clearly

MongoDB documents can be clean, but real data is often messy.

A document may have nested fields, arrays, dates, ObjectIds, embedded data, and references to other collections.

If everything is forced into a flat table, the structure can be hard to follow.

VisuaLeaf gives you different ways to browse MongoDB data, so you can inspect documents without losing the shape of the data.

You can look at the document structure, check nested values, and switch views depending on what you need.

This is useful when you open a collection you did not create yourself.

You should not have to guess what is inside the data. You should be able to see it clearly.

" width="800" height="480">

Browse MongoDB collections in the 3 different view modes.

See the MongoDB Schema

MongoDB is flexible, but that flexibility can make the structure harder to understand.

In SQL, tables and foreign keys usually show the structure.

In MongoDB, relationships may be embedded inside documents, stored as references, or only suggested by field names.

VisuaLeaf helps by showing collections, fields, nested structures, and relationships in a visual schema diagram.

This helps when you are learning a project, documenting a database, or explaining the structure to someone else.

Instead of opening collection after collection and trying to remember everything, you can see the schema in one place.

Visual schema diagrams make flexible NoSQL data easier to understand.

Turn Query Results Into Charts

Sometimes a result table is enough. Sometimes it is not.

If you want to see payments by method, orders by status, revenue by month, or expenses by category, a chart is easier to understand.

VisuaLeaf lets you turn MongoDB data into charts and dashboards without exporting the results into another tool.

You can query the data, check the result, and build a chart from the same workflow.

That makes it easier to understand patterns in the data, not just read raw documents.

" width="800" height="480">

Create charts and dashboards from real MongoDB data.

Mongo Shell for Developers

Visual tools are helpful, but developers still need direct access to the database.

VisuaLeaf includes a MongoDB shell, so you can run commands without leaving the workspace.

You can test a find() query, run an update, check an aggregation, or execute MongoDB commands directly with autocomplete and syntax highlighting.

The difference is that the shell stays connected to the rest of the MongoDB workflow.

You can write commands when you need full control, then switch back to visual results, query building, schema views, or charts when they help.

" width="800" height="480">

Run MongoDB commands with autocomplete, syntax highlighting, and visual results.

DBeaver vs VisuaLeaf for MongoDB Users

Feature	DBeaver	VisuaLeaf
MongoDB access	Available in Lite, Enterprise, and Ultimate	Free Community Edition + 14-day Pro trial
Query building	SQL and JavaScript workflow	Visual MongoDB query builder
Aggregations	Manual SQL or JavaScript workflow	Visual aggregation builder with stage preview
Charts	Available in paid editions	Charts and dashboards in Professional
Best fit	Teams using many database types	Developers focused on MongoDB

DBeaver is stronger when you need one tool for many database systems.

VisuaLeaf is a better fit when MongoDB is your main focus, and you want visual tools for queries, aggregations, schema, documents, and charts.

Final Thoughts

DBeaver is a practical choice if you need one tool for many databases.

But if you came here looking for a DBeaver alternative for MongoDB, you probably care more about the MongoDB workflow than the number of databases a tool supports.

That is where VisuaLeaf is different.

It gives you a MongoDB-focused workspace for browsing collections, building visual queries, creating aggregation pipelines, using the shell, viewing schema structure, and turning results into charts. And these are only some of the features. VisuaLeaf also includes tools for indexes, validation rules, collection comparison, query profiling, dashboards, saved queries, and more.

Try VisuaLeaf if you want a MongoDB workspace that feels more focused, visual, and easier to follow.

MongoDB vs PostgreSQL: The Arguments Everyone Gets Wrong

VisuaLeaf — Wed, 08 Jul 2026 13:08:13 +0000

Most of the Postgres vs Mongo arguments I see online are based on assumptions that are either super outdated or just kind of technically wrong. The same topics keep coming up over and over on reddit, youtube, or whatever, and I wanted to write some of them down.

"PostgreSQL JSONB is basically MongoDB"

JSONB lets Postgres store documents, but it doesn't turn Postgres into a document database. Mongo's storage engine, replication, sharding, aggregation framework, indexing, update semantics, and query engine were all designed around documents from day one. JSONB is bolted onto a relational engine.

It's still really useful. But "just use JSONB" is kind of like saying "just throw a truck bed on a sedan and now it's a pickup." Like, technically there's overlap, but they're still doing different things.

"MongoDB is schemaless"

Actually, that's one of the most common misconceptions.

Mongo lets you have flexible documents, but modern Mongo has schema validation, required fields, type enforcement, unique indexes, and most of the guardrails you'd want from a regular database.

Most Mongo deployments that actually work in production aren't truly schema-free. They just enforce schema differently (usually at the app layer or with validators).

"MongoDB loses data"

This one is basically a meme from like 2013.

Back then:

Default durability settings were weaker
A lot of deployments ran without replica sets
Some people disabled journaling (which... yeah)

Modern Mongo defaults are way safer. You get journaling, replica sets, majority-acknowledged writes, multi-document transactions, point-in-time recovery, and distributed replication. The "MongoDB loses data" thing is mostly people repeating something they heard a decade ago.

"MongoDB is only for lazy devs"

There are a lot of really smart database engineers and architects working at companies that run Mongo at scale. Choosing the "correct" database usually has to do with the workload, not with anyone being lazy, and some workloads just map to documents better than they map to normalized tables.

The misconception usually comes from MongoDB's flexibility, plus developers designing their databases recklessly without thinking about the future. In Postgres, it's much harder to do that because of all its guardrails. But that doesn't mean MongoDB is for lazy developers.

"Postgres is always better"

That's... debatable. Postgres is one of the best databases ever made, and it's usually a safe default. I'm not arguing against that. But like everything in software engineering, databases are tools, not teams to root for.

The question isn't "which one is better." It's "which one matches the workload better."

If your data is super relational, Postgres usually wins. If your data is document-shaped, Mongo usually wins. A lot of real systems end up using both.

Why JSONB vs BSON Benchmarks Are Kinda Misleading

You see a lot of benchmarks where someone compares Mongo documents against Postgres JSONB documents and concludes Mongo is faster. From this video: https://www.youtube.com/watch?v=ZZ2tx8iL3P4 (I am not the author of the video).

And for that test, the numbers are probably right. But the conclusion people pull from them often isn't.

There's two things going on with benchmarks like this.

1. The data models aren't really comparable.

JSONB isn't really Postgres's main data model. So when you benchmark Mongo documents against Postgres JSONB documents, what you're actually comparing is:

A document database
A relational database being used as a document database

A fairer Postgres benchmark would model the same data using normalized tables, foreign keys, real indexes, joins, the whole thing. A lot of workloads that suck in JSONB are actually really fast once you model them properly. The reverse is true too. Workloads that feel natural in Mongo get weird when you force them into rows and joins.

2. The durability defaults aren't comparable either.

In that video specifically, Mongo was running with its default writeConcern, which only flushes the journal every 100ms. Postgres was running with its default WAL fsync on every commit. So Mongo gets to acknowledge writes faster, because it's literally promising less durability per write. That's not "Mongo is faster than SQL." That's "Mongo is faster when you let it relax its durability." Crank Mongo up to j: true or w: "majority" with proper sync and the gap closes a lot.

Durability Isn't a Mongo Weakness Anymore

Like I mentioned above, the "Mongo loses data" thing is mostly an artifact of how people ran Mongo in the early 2010s.

Modern Mongo gives you journaling, replica sets, majority-acknowledged writes, multi-doc transactions, point-in-time recovery, and distributed replication.

A write with:

writeConcern: { w: "majority" }

is durable across multiple replica set members before it even gets acknowledged.

The actual durability gap between a properly configured Mongo cluster and a properly configured Postgres cluster is way smaller than people assume. Most "is it durable" arguments these days are really arguments about operational choices and consistency models, not about the storage engine.

Where Mongo Actually Wins

There are real workloads where Mongo is just the better tool.

Documents that get mutated a lot

Mongo is great when you're updating documents constantly and each update only touches a small piece of the doc. Stuff like:

Counters
User state
Device state
Telemetry that gets enriched over time
Session data

Postgres JSONB has to rewrite the whole JSONB value every time. Mongo often doesn't. This gap is huge in practice. Mongo can churn through partial updates at a rate that JSONB just can't match unless you pull the hot fields out into real columns.

Deeply nested data

Mongo handles nested objects, arrays, and embedded docs naturally. You don't have to join your way through five tables to assemble a real object.

Query patterns you can't predict yet

If your users can add arbitrary fields and then query them later, Mongo's flexibility is hard to beat. You don't have to know the schema ahead of time.

Horizontal write scaling

Mongo's sharding was built into the database from the start. Postgres can scale out too, but you usually end up with partitioning, extensions, distributed variants, or app-level sharding. None of those feel as native as Mongo's sharding does. That's one of MongoDB's biggest strengths.

Document-centric workloads

Mongo really shines when each request reads one doc, updates one doc, writes one doc. No joins, no fan-out, just the doc as the unit of work.

Big documents that change a lot

If your documents are large, mutated frequently, and accessed as a single unit, Mongo is basically designed for that.

Where Postgres Still Wins

Mongo's good at a lot, but Postgres still owns a few areas pretty cleanly.

Complex joins

Postgres's query planner is incredible. It's hard to overstate how good it is at joins. It actually outperforms MongoDB by a lot in a couple of public benchmarks.

Referential integrity

Foreign keys actually enforce relationships. Mongo can't really do this natively.

Reporting / analytics

SQL is still the language for analytics and BI. Pretty much every tool on the planet speaks it.

Heavily relational data

When your data is naturally graphy/relational, Postgres usually produces a cleaner design.

Multi-row transactions

Postgres's transaction model is one of its biggest strengths. Mongo has transactions too, but they're more limited.

A Java vs Python Way of Thinking About It

Here's an analogy that kind of clicks for me. You can almost think of SQL like Java and Mongo like Python.

Java has built-in types, strict structure, classes everywhere. It kind of forces you to organize your code and keep things modular. You can't really get away with being sloppy, because the language won't let you. SQL is similar. Schemas, types, constraints, foreign keys. The structure is enforced for you whether you want it or not.

Python is more like Mongo. Super flexible, super widely used, still really popular and not going anywhere. But if you don't have the self-discipline to make actual classes, structure your modules properly, and keep things organized, your codebase falls apart pretty fast. It's the same with Mongo. The flexibility is great until you stop enforcing schema at the app layer and your collections turn into a mess of inconsistent docs.

Neither is bad. Python is huge, Mongo is huge. They give you a lot of room to move fast. But the room to move fast is also the room to shoot yourself in the foot. Java and SQL take that choice away from you, which sucks when you want flexibility and is great when you need guardrails.

Different Tools, Different Assumptions

The way I think about it is that Postgres and Mongo aren't really competing for the same spot. They're built on different assumptions.

Postgres assumes:

Relationships matter
Consistency matters
Joins matter
Transactions matter

Mongo assumes:

Documents are the unit of work
Schema evolves
Updates are localized
Horizontal scaling matters

Neither one is universally right. The mistake is forcing your workload into the wrong set of assumptions, and then being mad when the database fights you. The best database is usually just the one whose assumptions most closely match what your app actually does.

A Quick Note on Where This Is Coming From

For context: I've been building a tool called VisuaLeaf for the last year and a half. It's a visual GUI for both MongoDB and PostgreSQL. Same workspace, same workflow, whichever database your data happens to live in. You can even migrate from sql databases to a mongodb database using VisuaLeafs Tasks/

Building it means I spend a kind of unreasonable amount of time inside both engines. A lot of these misconceptions come up in support tickets, Reddit threads, and questions from people picking between the two, so I figured I'd dump them in one spot instead of typing the same reply over and over.

PostgreSQL JSONB vs MongoDB BSON: The Real Architectural Tradeoffs

VisuaLeaf — Wed, 08 Jul 2026 13:04:12 +0000

Most teams pick between Postgres and Mongo by arguing about SQL vs documents, transactions, joins, or what everyone's using at the moment. The format on disk barely makes it into the discussion. That’s the wrong place to stop, because each database’s byte-level design carries the philosophy of the engine. BSON is a binary echo of MongoDB's runtime: a self-describing wire format that the server can scan, mutate, and ship easily. JSONB is a parse tree frozen into a Postgres tuple: optimized for read-time access, indifferent to write-time mutation, and beholden to MVCC.

Once you know what each format actually is, the rest of the comparison stops being a religious argument and starts being a set of engineering tradeoffs you can reason about. This piece walks through what BSON and JSONB are at the byte level, how they behave once they hit storage, what each one costs to index, update, and read back, and which workloads each one quietly punishes.

Why the format matters more than the API

Application developers see JSON. Both engines accept JSON on the way in and serve JSON on the way out, so it is tempting to assume the storage format is a cosmetic detail. It is not. The storage format dictates:

How much byte juggling the server does on every read.
Whether a partial update can mutate a value in place or has to rewrite the entire document.
What kinds of indexes can be built and how big they get.
How much write amplification you pay when a single field changes.
Whether the disk representation survives a torn page or a partial flush.

A query that runs in 1ms on a hot row can run in 30ms if the format forces the server to materialize and reparse the row. A field update that flips a boolean can rewrite 8KB of heap, generate WAL, trigger toast churn, and invalidate three indexes, or it can patch four bytes. The format decides which world you live in.

BSON: a binary echo of MongoDB's runtime

BSON stands for Binary JSON. BSON is a length-prefixed, type-tagged, ordered key-value format that was designed with three properties in mind: cheap to parse linearly, cheap to mutate in place when the new value is the same size, and rich enough to carry types that JSON cannot express.

The wire layout of a BSON document looks roughly like this:

int32  total_document_length_in_bytes
{ element }*
byte   0x00  // terminator

Each element is itself:

byte    type_tag    (0x01 double, 0x02 string, 0x03 embedded doc, 0x07 ObjectId, ...)
cstring field_name
<payload depending on type>

Two things follow from that layout. First, every document and every embedded subdocument carries its own length prefix, which means a parser can skip an entire subtree in one pointer arithmetic step. Second, fields are ordered. The same logical document can be encoded in different byte sequences depending on insertion order, and the server preserves that order.

The type tag set is wider than JSON's. BSON has dedicated tags for:

32 bit and 64 bit integers (JSON has only a generic number).
IEEE 754 decimal128 for financial workloads.
ObjectId (12 bytes: timestamp, machine id, counter).
UTC datetime (int64 milliseconds since epoch).
Binary blobs with a subtype byte.
UUID (a binary subtype).
Regular expressions.
A JavaScript code type, mostly historical.
MinKey and MaxKey sentinels used for index bounds.

Two consequences for engineers. One: BSON round trips numeric types faithfully. A column that stores 64 bit account ids does not silently become a double the way it would in pure JSON. Two: BSON carries metadata that JSON cannot, which is part of the reason a MongoDB driver feels chatty when you push it through a strict JSON pipeline.

The clever bit, and the one that distinguishes BSON from a hundred other binary JSON formats: every field's payload is preceded by enough information that a server can walk the document linearly without recursive parsing, and many field updates can be performed by patching the payload in place. If you change an int32 field from 7 to 8, the document length does not change, the field offset does not move, and the engine writes four bytes. That property is what lets WiredTiger keep update latency flat across a wide range of document sizes.

It also explains the cost of BSON. Field names are stored as raw cstrings in every document. A collection of a billion documents with a created_at field carries the literal bytes created_at\0 a billion times. There is no schema, no dictionary, no shared symbol table. Wide documents with long field names waste a lot of disk and a lot of memory.

JSONB: a parse tree frozen on disk

JSONB is the spiritual opposite of BSON. Where BSON is a wire format that happens to live on disk, JSONB is a storage format that happens to be transferable. Postgres parses incoming JSON, normalizes it (keys sorted, whitespace stripped, duplicate keys deduplicated with last write wins), and serializes the result into a binary structure that maps directly onto the engine's value tree.

There is no public byte spec the way there is for BSON. Internally, a JSONB value is a header plus a sequence of entries that describe each key value pair, plus the data area. The headers contain length and type bits so the engine can binary search keys inside an object, and offsets are stored every N entries to bound the cost of finding a specific key. That structure has two big implications.

First, JSONB is a read optimized format. Once the document is stored, looking up a key by name is logarithmic in the number of keys, not linear. For wide objects with hundreds of fields, this matters. BSON, by contrast, is linear: it walks the document until it finds the key, leveraging the length prefixes to skip subtrees.

Second, JSONB cannot be patched in place. The header layout, the offset cache, and the dedup pass all assume the value is being constructed from scratch. Updating a single boolean inside a 4KB JSONB document materializes a brand new 4KB JSONB document, writes a new heap tuple, marks the old one dead, and updates every index that references it. This is not a JSONB design flaw, it is the consequence of binding the format to Postgres's MVCC and TOAST machinery. JSONB does what makes Postgres fast at reads. Postgres pays for the rest at write time.

JSONB throws away two things compared to JSON. Key order is lost (objects are stored with keys sorted), and duplicate keys are collapsed. Most applications never notice, but if you are relying on either property, you want json (the text type) not jsonb. Almost nobody should be relying on either property.

JSONB also does not preserve numeric type fidelity in the same way BSON does. Postgres has its own numeric type which is arbitrary precision, and JSONB encodes numbers using that representation. You will not lose precision the way you would with a 64 bit float, but you also do not get a distinct int32 vs int64 tag the way BSON gives you.

Binary blobs and where the type systems leak

The gap between BSON and JSONB shows up the fastest when data falls outside JSON's native type system.

Binary blobs are the usual offender. BSON has a native binary type with a subtype tag, JSONB does not. In Postgres your options are base64 encoding the bytes into JSONB (ugly), or pulling them out into a separate bytea column and referencing them by id (cleaner). Splitting the document works fine when you own the schema, it becomes awkward when you are ingesting third party documents that already embed binary fields, like S3 events with attachments or message payloads with thumbnails.

Storage: WiredTiger pages vs heap tuples plus TOAST

The byte format is half the story. The other half is what the storage engine does with the bytes.

MongoDB stores BSON documents inside WiredTiger, a B+ tree storage engine that also backs a number of other databases. WiredTiger gives MongoDB two important properties:

Block compression by default. Snappy compresses each block; zstd is available and can roughly halve the disk footprint on text heavy collections. The compression happens at the storage layer, so the in memory representation is uncompressed but the on disk and on wire (replication) footprint is much smaller. For a workload that stores web event payloads or product catalogs, the ratio of on disk size to logical size is routinely 3:1 or better.
In place updates when possible. If a field changes and the new BSON encoding fits in the existing slot, WiredTiger patches the page. If the document grows beyond its allocated space, WiredTiger rewrites the document, which is the expensive path. Schema decisions matter here: documents with arrays that grow over time will rewrite often, and the standard advice is to size arrays carefully or break them out into separate collections.

WiredTiger maintains a journal (write ahead log) that commits to disk every 100ms by default, and snapshots dirty pages to disk at 60 second checkpoints. The two intervals together keep recovery time bounded without grinding the write path on every commit.

PostgreSQL stores JSONB inside a heap tuple, the same structure that holds every other Postgres row. The heap is a page based store (8KB pages by default) with row level MVCC. Every update writes a new tuple, links it to the old one, and lets autovacuum reclaim the dead copy later.

JSONB also interacts with TOAST (The Oversized Attribute Storage Technique). Any column value that exceeds approximately 2KB after compression gets pushed into a separate TOAST table and replaced in the main heap with a pointer. JSONB documents larger than that threshold therefore live in two places: the heap tuple holds a pointer, and the actual JSONB lives in toast chunks. Reading the document means following the pointer and reassembling the chunks. The default TOAST strategy for jsonb is EXTENDED, which means values are first compressed (using the cluster's default compression, pglz or lz4 since PG 14), and then chunked if still over threshold.

The two consequences are easy to miss:

A SELECT * on a table with TOASTed JSONB columns will fetch the entire chain even if you only wanted three scalar fields from the row. Project the columns you need or extract the JSONB fields explicitly.
Updating one field in a JSONB document materializes a new JSONB, which gets TOASTed again. The old TOAST chunks become dead and wait for autovacuum. On a heavy update workload against large JSONB documents, the TOAST table can balloon faster than the main heap.

Postgres 14 added LZ4 compression for TOAST, which is meaningfully faster than the legacy pglz both for compression and decompression. If your JSONB columns are large and updated often, switching to LZ4 is the single highest leverage TOAST change you can make.

Updates: in place vs MVCC tombstones

Spend ten minutes profiling a heavy update workload on each engine and the contrast jumps out.

In MongoDB, a field level update with $set, $inc, or $push is interpreted by the server and translated into a targeted mutation of the BSON document. If the new value fits, WiredTiger updates the page in place. If it does not fit, the document is rewritten. Index entries are only touched for the fields that actually changed and that are indexed. The journal records the delta, not the whole document.

In PostgreSQL, UPDATE on a JSONB column always rewrites the entire JSONB value. The jsonb_set function looks surgical at the SQL layer (it lets you set a specific path) but underneath, it builds a new JSONB and the row update replaces the old tuple. MVCC then leaves a dead tuple behind, autovacuum reclaims it later, and every index on the table that does not satisfy the HOT (Heap Only Tuple) conditions has to insert a new entry pointing at the new tuple. If your indexes reference fields inside the JSONB column, HOT is off the table and every update is amplified.

In practice this means two patterns dominate.

MongoDB rewards documents with mutable internals. A counter inside a document, a status field that flips often, an array that gets pushed to on every event: these are cheap operations. The flip side is that document growth is the silent killer. A document that starts at 1KB and grows to 50KB over a year is rewritten by WiredTiger every time it crosses its current allocation, which means the late life updates are dramatically more expensive than the early life updates.

PostgreSQL rewards documents that are read more than they are updated. Catalog data, feature flags, event payloads that are written once and read many times, configuration that changes weekly rather than per second: JSONB is excellent for these. The moment you start treating a JSONB document as a per row mutable object that changes on every request, you are fighting the engine.

The benchmark that exposes this gap is straightforward. Take a million row table or collection, each row holding a 4KB document with a view_count integer somewhere inside it. Increment the counter once per second per row across all rows. MongoDB may only need to modify the bytes associated with the changed field, avoiding the full document rewrite that JSONB incurs. Postgres rewrites 4KB of JSONB per document, generates 4KB of WAL per update, and starts producing dead tuples faster than autovacuum can clean them. The Postgres answer here is simple: do not store view_count in JSONB. Pull it into a regular bigint column. That fix is real and lasting, and it is also a tax on schemas that try to be JSON first.

Indexes: GIN, multikey, and what each can answer

Both engines let you index inside documents. The mechanisms are different, and the resulting indexes have different shapes.

PostgreSQL offers two index strategies for JSONB.

GIN indexes on the whole document. The default operator class supports containment (@>), key existence, and path queries. A more aggressive variant, jsonb_path_ops, supports only @> but produces a smaller, faster index. Both are inverted indexes that emit one entry per path through the document.

CREATE INDEX idx_events_data ON events USING GIN (data jsonb_path_ops);
SELECT * FROM events WHERE data @> '{"type": "signup"}';

B tree indexes on specific expressions. When you know the exact path you want to query, an expression B tree is dramatically smaller and faster.

CREATE INDEX idx_events_user_id ON events ((data->>'user_id'));
SELECT * FROM events WHERE data->>'user_id' = '12345';

MongoDB indexes work on field paths directly. The standard createIndex({user_id: 1, created_at: -1}) builds a B tree on a compound path. The syntax is different from Postgres, but the behavior is familiar.

Multikey indexes. When the indexed field is an array, MongoDB automatically creates one index entry per array element. The same B tree, traversed differently. A document with tags: ["postgres", "mongodb", "bson"] generates three index entries pointing at the same document, and any element match query can use the index. This is the killer feature for tags, references, and other array shaped data.

For fixed, known query shapes, Postgres ties or beats Mongo with expression B trees. For varied or array heavy data, Mongo's first class multikey support gives it more leverage with less ceremony.

One more thing Postgres has on Mongo here: partial indexes with arbitrary predicates. You can build an index that only covers the rows where some JSONB field has a specific value, or a date range, or whatever. Mongo has partial indexes too but the filter expressions you can use are way more limited, so anything more than a simple equality check usually has to live in the query side instead of the index.

Read paths and the cost of materialization

The end to end read path is where the two formats earn or lose their reputation.

A MongoDB find that hits an index and returns a single document does roughly the following: traverse the B tree to find the record id, fetch the page from WiredTiger, decompress the block, locate the BSON document inside the page, copy it into the response buffer, ship it over the wire. The document is already in BSON. If the driver supports it (most do), the bytes can travel from the storage page to the client with no parse on the server side. Field projection ($project in aggregation, or projection on find) walks the BSON in place and emits a trimmed version.

A PostgreSQL select that hits an index and returns a single row does roughly the following: traverse the B tree to find the heap tuple location, check the visibility map and the tuple's xmin/xmax to confirm the row is visible to this transaction, fetch the heap page, locate the tuple, follow any TOAST pointers to reassemble JSONB columns, materialize the row into the executor's tuple format, apply any projections, and emit. The visibility check is the MVCC tax. The TOAST chase is the wide column tax. The materialization is the format tax.

For point reads of small documents, both engines are fast and the differences are noise. For wide documents (tens of KB) or selective projections on a large document, BSON has a structural edge because the on disk format and the on wire format are the same, and projection is a walk. JSONB has to be unpacked and the projection produces new JSONB. The win is not huge in absolute terms, but it shows up on workloads that fan out reads.

Aggregations flip it though. Postgres has been working on its query planner for like 30 years. Parallel scans, hash joins, merge joins, a cost based optimizer that has seen basically every shape of analytical query a person can write. Mongo's aggregation pipeline has gotten way better in recent versions (SBE is faster, $lookup is actually usable now), but once you're doing real analytics with multiple joins and big group by aggregates, Postgres just wins. Not by a small margin either, you'll often see big multiples on the same workload.

When PostgreSQL JSONB is the right answer

Reach for JSONB when:

The bulk of your schema is relational and a few columns happen to be semi structured. Customer records with a metadata field. Products with a variable attributes blob. Orders with line items that have inconsistent shape across categories.
Reads dominate writes against the JSONB columns. Catalog data, configuration, audit payloads, settings.
You need joins. Postgres can join JSONB columns against regular columns against full text indexes against PostGIS geometries against time series partitions in one query. Mongo can do this through $lookup but it is not the same.
You need transactions across many rows. JSONB inherits Postgres's transaction model for free.
The team is already running Postgres and the operational cost of adding a second database is not justified.
You want strong typing in some columns and document flexibility in others, in the same table.

Workloads that fit this shape: SaaS application data, e commerce catalogs, CMS storage, configuration stores, audit logs that need to be queried by structured fields, anything where the analytical query layer is going to use SQL anyway.

When MongoDB BSON is the right answer

Reach for MongoDB when:

The unit of work is the document. Each request reads or writes one document, occasionally a few. Most operations do not span documents.
Documents are large, mutate frequently, and the mutations are field local. Telemetry events that get enriched over time. Game state. IoT device shadows. Anything where the same document gets touched many times and each touch is small.
The query patterns are varied and the schema is genuinely fluid. You do not know which fields users will query next month.
You need horizontal write scaling out of the box. Mongo's native sharding has gotten very good. Postgres has sharding solutions (Citus, partitioning) but they are bolted on rather than first class.
You need a document oriented secondary index pattern that Postgres expression indexes cannot model cleanly.
The team has Mongo expertise and the workload does not need SQL analytics.

Workloads that fit this shape: real time event streams with rich payloads, mobile and game backends, IoT device fleets, content management with deeply nested structures, anything where the data model is naturally a graph of nested objects and the queries are mostly key value style with occasional secondary lookups.

The practical takeaway

If you remember three things from this:

The format is the engine. BSON is what makes Mongo fast at field updates and fast at projection. JSONB is what makes Postgres flexible without giving up relational performance. The choice between them is not about JSON vs binary, it is about update behavior, index shape, and read path.
JSONB is a read optimized format. It pays for itself when you write once and read many. It punishes you when you treat a JSONB column as a mutable object that changes on every request. Pull hot mutable fields out into regular columns.
BSON is an update optimized format. It pays for itself when documents are touched often and the touches are local. It punishes you when documents grow unboundedly, when field names are long, and when the query pattern wants joins and aggregations.

Pick the engine whose architectural assumptions match your workload's access pattern. Everything else is a tax you will pay every day until you fix it.

Working with MongoDB documents?

Understanding BSON is useful, but seeing the structure of your collections makes the work much easier.

With VisuaLeaf, you can browse MongoDB documents, inspect schemas visually, build queries, create aggregation pipelines, and understand how your data is actually organized.

MongoDB Workspace for Queries, Schema, Charts, and Teams

VisuaLeaf — Mon, 06 Jul 2026 08:51:06 +0000

MongoDB work is rarely just one task.

You may start by browsing a collection, but soon you need to build a query, test an aggregation, check the schema, create a chart, inspect indexes, compare data, or explain the database to someone else.

That is why VisuaLeaf is built as a visual MongoDB workspace.

Instead of keeping queries, aggregations, schema diagrams, dashboards, performance checks, and screenshots in separate places, VisuaLeaf brings the main MongoDB workflows closer together in one interface.

It is made for developers and teams who want to work visually, but still keep access to the generated MongoDB code when they need it.

Manage MongoDB connections in one place

Most teams work with more than one MongoDB connection.

You may have a local database, an Atlas cluster, a staging environment, and production.

VisuaLeaf’s *Connection Manager* helps you organize and open your MongoDB connections from one workspace.

This is useful when you switch between projects, compare environments, or need quick access to the databases you use every day.

Instead of starting from zero every time, your MongoDB workspace starts with the connections you already work with.

Manage local, Atlas, staging, and production MongoDB connections from one place.

Browse MongoDB collections in different views

The first job of any MongoDB tool is simple: help you see the data clearly.

In VisuaLeaf, you can browse collections in different views, depending on what you need.

Use *Tree View* when the documents are nested, and you want to open fields step by step.

Use *Table View* when you want to scan many documents quickly.

Use *JSON or BSON View* when you need to inspect the raw document structure.

This is useful when you are debugging real data, checking nested fields, reviewing documents, or explaining a collection to someone else.

You can also insert, edit, and delete documents from the same workspace, so basic data work does not become slower than it needs to be.

Browse MongoDB collections in the view that fits the task.

Build MongoDB queries visually

Writing MongoDB queries manually is useful. But when a query has multiple filters, nested fields, sorting, projection, and limits, it is easy to make small mistakes.

VisuaLeaf’s *Visual Query Builder* helps you build the query step by step.

You choose the field, operator, and value. Then you add sorting, projection, and limit if you need them.

The important part is that you still see the generated MongoDB query.

So you are not locked into a visual interface. You can build visually, test the result, and copy or review the code whenever you need it.

This is helpful for juniors, onboarding, debugging filters, or showing a teammate why a query returns certain documents.

Build MongoDB queries visually and keep the generated code visible.

Test aggregation pipelines stage by stage

Aggregation pipelines can become hard to read fast.

One $match is fine. A $group is fine. But after $lookup, $unwind, $project, $sort, and more stages, it can be hard to know where the result changed.

VisuaLeaf’s *Aggregation Pipeline Builder* lets you build pipelines one stage at a time.

You can see the input, add a stage, check the output, and continue from there.

This makes the pipeline easier to debug because you do not have to wait until the final result to notice something is wrong.

It also makes aggregations easier to explain during teamwork, because each stage has a clear role.

You still get the generated aggregation code, so the visual builder helps you understand the pipeline instead of hiding it.

Build and debug MongoDB aggregations stage by stage.

Use AI Assistant when you need a faster starting point

Sometimes you know what you want from the data, but you do not want to start from zero.

In VisuaLeaf, you can use *AI Assistant* while working with the Visual Query Builder or the Aggregation Pipeline Builder.

It can help generate a first query or pipeline from your prompt. Then you can review the result, test it with your data, adjust it visually, and keep the generated MongoDB code visible.

AI Assistant gives you a faster starting point, but you still stay in control of the final result.

Use AI to generate a first aggregation pipeline, then review and edit each stage.

Understand NoSQL schemas with diagrams

MongoDB is flexible, but flexible does not mean structure does not exist.

The structure is still there. It is inside the documents.

You may have required fields, optional fields, nested objects, arrays, embedded documents, and references between collections.

VisuaLeaf’s *Schema Designer* helps you see that structure visually.

This is useful when you join a new project, prepare documentation, explain the database to another developer, or try to understand how collections are connected.

A schema diagram can make a MongoDB database easier to understand than reading documents one by one.

This is especially helpful for teams, because not everyone has the same database knowledge in their head.

Visual schema diagrams make flexible NoSQL data easier to understand.

Use JSON Schema Validation when you need to enforce structure

MongoDB is flexible by default, but some collections need stricter rules.

For example, you may want to require important fields, accept only specific data types, or make sure documents follow the same structure before they are inserted.

VisuaLeaf’s *JSON Schema Validation* helps you define MongoDB validation rules visually.

You can enforce structure where it matters, prevent bad data, and still see the generated JSON Schema validation code.

This is useful when a collection is used by a team, an app, or any workflow where inconsistent data can create problems later.

Create MongoDB validation rules visually and keep the generated JSON Schema.

Create charts and dashboards from MongoDB data

Some MongoDB data is easier to understand visually.

With VisuaLeaf’s *Chart &* *Dashboard Builder*, you can turn collection data into charts and group multiple views in one dashboard.

This is useful for payments by status, orders by month, users by plan, expenses by category, or any data you want to understand faster.

Charts and dashboards help you prepare demos, create quick internal reports, check product data, or explain results to people who do not want to read raw JSON documents.

You can keep the visual data close to the collections, queries, and aggregations you are already working with.

Create charts and dashboards from real MongoDB data.

Check query performance with Explain and Profiler

When a MongoDB query is slow, you need more than a guess.

You need to know if MongoDB is using an index, scanning too many documents, or doing a collection scan.

VisuaLeaf includes tools like *Explain Plan* and *Query Profiler* to help you understand what happens behind a query.

You can check execution details, scanned documents, returned documents, and index usage closer to the query itself.

This makes performance work easier because you do not have to separate query building from query debugging.

Check how MongoDB runs your query and find performance problems faster

Automate MongoDB tasks with Task Manager

Some MongoDB work does not need to be done manually every time.

With VisuaLeaf’s *Task Manager*, you can create and run tasks directly from the workspace.

This is useful for repeated actions like running scripts, exporting data, syncing workflows, or handling MongoDB operations that you do not want to rebuild from zero each time.

Instead of keeping these tasks in different places, you can manage them closer to the collections, queries, and tools you already use.

For teams, this makes repeated MongoDB work easier to organize, run, and review.

Use Task Manager to organize and run repeated MongoDB workflows from one place.

Compare collections across environments

Local, staging, and production data do not always match.

A document may be missing. A field may be different. A test collection may be outdated. And checking everything manually is slow.

VisuaLeaf’s *Collection Compare* helps you compare MongoDB collections and see the differences clearly.

You can inspect missing documents, modified documents, and differences between collections before deciding what to fix or sync.

This is useful for developers, QA work, migration checks, and teams working with multiple MongoDB environments.

Compare MongoDB collections across local, staging, and production environments

Use Mongo Shell when you need direct control

Visual tools are helpful, but sometimes the shell is still the fastest option.

VisuaLeaf includes a *Mongo Shell with autocomplete*, syntax highlighting, and visual results so that you can run commands directly inside the workspace.

This keeps the workflow flexible.

You can build visually when it saves time, or use the shell when a command gives you more direct control.

The result is still easy to read, because you are not just writing commands in a plain terminal. You can run MongoDB commands and inspect the output visually in the same place.

Run MongoDB commands with autocomplete, syntax highlighting, and visual results.

Query MongoDB with SQL Mode

Not every developer thinks in MongoDB syntax first.

Some teams also have developers who come from SQL databases, or people who simply find SQL easier for quick exploration.

VisuaLeaf includes *SQL Mode*, so you can work with MongoDB data using a SQL-style query workflow.

This can help when you want to explore collections faster, explain data to someone with a relational database background, or move between SQL and MongoDB work without changing tools.

Use SQL Mode when a SQL-style workflow makes MongoDB data easier to explore.

View files stored in GridFS

MongoDB is not always only documents.

Some projects also store files using GridFS.

VisuaLeaf includes a *GridFS Viewer*, so you can inspect files and file metadata from the same MongoDB workspace.

This is useful when your application stores images, documents, uploads, or other large files in MongoDB.

Instead of checking file data separately, you can keep it close to the collections and database structure you are already using.

View files and metadata stored in MongoDB GridFS.

Review users and roles with RBAC Dashboard

For teams, MongoDB access is not only about connecting to the database.

You also need to understand who has access, which roles exist, and what permissions are assigned.

VisuaLeaf’s *RBAC Dashboard* helps you review MongoDB users, roles, and permissions in a clearer way.

This is useful for team databases, shared environments, and projects where access control needs to be checked without digging through everything manually.

Review MongoDB users, roles, and permissions from the RBAC Dashboard.

Quick feature summary

Replace the long final list with this:

Work in a cleaner light theme

VisuaLeaf also includes a *light theme*.

This is useful when you create tutorials, record videos, take screenshots, share your screen, or explain MongoDB work during a team call.

Dark mode is still great for focused work.

But light mode can make query builders, schema diagrams, charts, dashboards, and collection compare screens easier to present.

For a visual MongoDB workspace, that matters.

Try VisuaLeaf Free

Build MongoDB queries, aggregation pipelines, NoSQL schema diagrams, charts, dashboards, collection comparisons, tasks, and performance workflows in one visual workspace.

Download the Free Community Edition and start with a 14-day Pro trial.

MongoDB Schema Design: Embedded vs Referenced with Examples

VisuaLeaf — Wed, 01 Jul 2026 09:59:24 +0000

When you design a MongoDB database, one of the first choices is this:

Should this data stay inside the same document, or should it live in another collection?

That is the difference between embedding and referencing.

Embedding means the data is stored inside the document.

Referencing means the data is stored in another collection and connected with an _id.

That’s the main difference.

Let’s use a simple database called streaming_platform_db.

It has collections like users, movies, series, episodes, payments, ratings, watch_history, and activity_logs.

The database works like a basic streaming platform.

A user can have a subscription, profiles, and devices. The same user can also make payments, watch content, rate movies, and create activity logs.

That makes this database a good example because it uses both embedded data and referenced data.

Visual Schema Design

In Visualeaf, I generated a schema diagram for the streaming_platform_db database.

This makes the structure easier to understand because I can see the collections and their relationships in one place.

VisuaLeaf schema diagram for streaming_platform_db, showing embedded fields and referenced collections.

For example, the users collection has fields like:

subscription
profiles
devices

These fields are stored inside each user document.

That means they are embedded.

But other collections, like payments, ratings, watch_history, and activity_logs, are connected to users with user_id.

That means they are referenced.

So the diagram shows the main idea very clearly:

Some data lives inside a document.

Some data lives in another collection and points back with an ID.

A Quick Example in Mongo Shell

To make this easier to see, here is a small example from the users collection.

In this document, subscription, profiles, and devices are stored inside the user document.

That means they are embedded.

db.users.insertOne({
  full_name: "Oliver Smith",
  email: "oliver.smith@streaming.test",
  country: "UK",
  city: "London",

  subscription: {
    plan: "standard",
    status: "active"
  },

  profiles: [
    {
      profile_name: "Oliver",
      type: "adult",
      preferences: {
        favorite_genres: ["Action", "Sci-Fi"],
        subtitles: ["en"]
      }
    },
    {
      profile_name: "Kids",
      type: "kids",
      kids_mode: true
    }
  ],

  devices: [
    {
      type: "laptop",
      os: "Windows 11"
    }
  ]
});

After creating this document in Mongo Shell, Visualeaf makes the embedded structure easier to see. The fields are inside the users document, not in separate collections.

Embedded data in the users collection. The subscription, profiles, preferences, and devices are stored inside the same user document.

Now compare that with referenced data.

Payments are not stored inside the user document. They live in a separate collection and point back to the user with user_id.

db.payments.insertOne({
  user_id: ObjectId("USER_ID_HERE"),
  amount: 12.99,
  currency: "EUR",
  status: "paid",
  paid_at: new Date()
});

Here, user_id connects the payment to the user.

That is a reference.

Visualeaf schema view showing the reference between users and payments through user_id.

One important thing to know: a MongoDB reference is not the same as a SQL foreign key.

In SQL, a foreign key can enforce the relationship between two tables.

In MongoDB, _user_id_is just a field that stores another document’s id`

MongoDB does not automatically check that the user exists.

So the difference from the main diagram is simple:

`
users.devices // embedded
users.profiles // embedded
users.subscription // embedded

payments.user_id // referenced
ratings.user_id // referenced
watch_history.user_id // referenced
activity_logs.user_id // referenced
`

Embed data when it belongs inside the document.

Reference data when it should stay in another collection.

Where embedding fits

Embedding is a good choice when your data is associated with one primary document.

Examples:

`
users
└── subscription
└── profiles
└── preferences
└── devices

If you open a user account, you will likely also want to see the subscription, profiles, and devices too.

So it makes sense to keep them together.

You do not need a separate collection for every small detail.

Simple rule: Embed data when it belongs to one parent and is usually read together.

Where Referencing Fits

Referencing is a good choice when the data can grow or needs to stay separate.

For example, payments should not be stored inside the user document.

A user can have many payments over time. One payment this month, another payment next month, and so on.

So it is cleaner to store payments in a separate collection.

`
payments
└── user_id

The user_id field points back to the user.

The same idea works for ratings, watch_history, and activity_logs.

`
ratings
└── user_id
└── content_id

watch_history
└── user_id
└── content_id

activity_logs
└── user_id
`

These records are related to the user, but they do not need to live inside the user document.

They can grow fast, so they are better as separate collections.

Simple rule:

Reference data when it can grow, repeat, or connect more than one collection.

When to Embed vs When to Reference

Here is a simple way to decide.

Conclusion

MongoDB schema design is about deciding where your data should live.

Some data makes more sense inside the same document.

Other data makes more sense in a separate collection, connected with an ID.

That is the difference between embedding and referencing.

A GUI tool like Visualeaf makes this easier to understand because you can see the database structure visually.

Instead of reading only raw JSON, you can see how collections connect, where data is nested, and how the schema is organized.

This makes it easier to read, explain, and improve your MongoDB database.

Try VisuaLeaf today!

Download Free

MongoDB find() Query Examples for Beginners - Filter, Sort, Limit

VisuaLeaf — Tue, 30 Jun 2026 19:05:26 +0000

When you use MongoDB, most of the time you are asking one simple thing:

*“Give me the documents that match this.”*

This is what find() does.

It searches through a collection and finds the documents that fit your filter.

Let’s take an example with the orders collection.

It could look like this:

{
  customer: "Oliver",
  status: "paid",
  total: 120,
  paymentMethod: "card",
  items: ["laptop", "mouse"]
}

Nothing complicated here.

It is just one order. Oliver paid $120 using her credit card for a laptop and a mouse.

Let’s now see how you can ask MongoDB about the data.

Before writing any query, it helps to quickly look at the collection itself.

In VisuaLeaf, the Tree View makes it easy to explore the orders collection and see what fields each document contains.

That way, before you even write find(), you already have a clear picture of the data you are working with.

Show All Documents

The simplest query is this:

db.orders.find({})

This query means:

*Return all orders for me.*

Since there is an empty {}, no rule was added.

There is nothing to filter in MongoDB, so it will return all data from the orders collection.

It is fine during testing, but not really in a live database environment.

Find Orders by Status

What if we wanted to look for paid orders only?

db.orders.find({ status: "paid" })

What that means is:

*Find the orders that have status equal to paid.*

MongoDB checks each document.

If the order has:

status: "paid"

Then it is selected.

Otherwise, if the status is "pending" or "cancelled", it is ignored.

This is the fundamental concept of MongoDB filtering.

If you run this query in the VisuaLeaf shell, you can immediately see the matching documents.

This is one of the easiest ways to understand what find() does: you write a simple filter, run it, and MongoDB returns only the documents that match it.

Find Orders with Two Conditions

And here’s an example request for orders that are paid and paid by card.

db.orders.find({
  status: "paid",
  paymentMethod: "card"
})

What does this mean?

*Show orders which have status "paid" and payment method "card".*

Both conditions must apply.

Which means the results won’t include all paid orders.

Only paid orders that are paid by card.

The easy way to remember this:

Two fields in the same filter = AND

Find Orders Greater Than a Number

Sometimes we do not need to match exact values.

We can find orders where the total is more than 120.

db.orders.find({
  total: { $gt: 120 }
})

$gt stands for *greater than*.

That means:

*Find orders where the value of total is greater than 120.*

Some important operators include:

$gt   greater than
$gte  greater than or equal
$lt   less than
$lte  less than or equal
$ne   not equal

For example:

db.orders.find({
  total: { $lt: 50 }
})

That means:

*Find orders where the value of total is less than 50.*

Find Orders with More Than One Accepted Value

Suppose we have two types of payment accepted: card and PayPal.

We can use $in.

db.orders.find({
  paymentMethod: { $in: ["card", "paypal"] }
})

It means that:

*Give me all orders that have payment method card or PayPal.*

The $in operator can be used when one property needs to be checked against multiple values.

Example:

db.orders.find({
  status: { $in: ["paid", "processing"] }
})

It means that:

**Give me all orders that are paid or in process.

Sort the Results

A filter determines which documents will be returned to you.

But ordering determines the order in which they appear.

For instance,

db.orders.find({ status: "paid" }).sort({ total: -1 })

Which means:

*Give me the paid orders, and start from those with the highest totals.*

As we can see, -1 means descending order.

Which means, higher numbers appear first.

If we used 1, lower numbers would appear first.

For instance,

db.orders.find({ status: "paid" }).sort({ total: 1 })

Which means:

**Give me the paid orders, and start from those with the lowest totals.

Limit the Results

Often, you do not need to see all results that match your search.

All you need is to see a few results.

db.orders.find({ status: "paid" }).limit(5)

What this means is:

*I want to see only 5 paid orders.*

You may also add sort and limit together.

db.orders.find({ status: "paid" })
  .sort({ total: -1 })
  .limit(5)

What this means is:

*I want to see the top 5 paid orders by total.*

Your search becomes very meaningful.

You no longer get all paid orders.

You get only the top 5.

Return Only Needed Fields

In general, when running find() command, MongoDB retrieves the whole document from the collection.

However, sometimes you need only some fields of the document.

db.orders.find(
  { status: "paid" },
  { customer: 1, total: 1, _id: 0 }
)

Here, the first block represents the filter criteria,

{ status: "paid" }

and the second one specifies the fields needed to be retrieved by MongoDB:

{ customer: 1, total: 1, _id: 0 }

If the field value is equal to 1, it will be included in the output.

_id: 0 indicates that you do not need the _id field in the output.

Thus, your output will look like this:

{
  customer: "Oliver",
  total: 120
}

One Query With All the Parts

Here we bring everything together.

db.orders.find(
  {
    status: "paid",
    total: { $gt: 120 },
    paymentMethod: { $in: ["card", "paypal"] }
  },
  {
    customer: 1,
    total: 1,
    paymentMethod: 1,
    _id: 0
  }
).sort({ total: -1 }).limit(5)

At first glance, it seems longer.

But here is how you read it normally:

*Show me orders that are paid, have a total of more than 120, and have a paymentMethod of card or PayPal. Return the customer, total, and paymentMethod. Sort by descending total and limit to five results.*

That is all there is to it.

The query is no magic.

It is just a question with some extra detail.

Why Does It Seem Like MongoDB Queries Are Difficult?

It seems like that because the queries use brackets within brackets.

The logic itself, however, is simple.

Firstly, choose the collection:

db.orders

Then ask to return the documents:

.find()

And then put the filter:

{ status: "paid" }

That is:

db.orders.find({ status: "paid" })

Just asks *to find the orders that have the status paid*.

Once you treat the MongoDB queries as regular questions, everything becomes easier.

Building MongoDB Queries Visually

Writing MongoDB queries by hand is important.

But when a query has more parts, it can be easier to build it step by step.

For example, our final query does a few things at once:

status equals paid
total greater than 120
paymentMethod is card or paypal
return only a few fields
sort by total
limit the results to 5

That is not hard, but it is easy to miss a bracket or forget one part.

In VisuaLeaf, you can build the same query visually.

You add the filters one by one, choose the fields you want to see, set the sort order, and limit the results.

The same MongoDB query built visually in VisuaLeaf, with filters, selected fields, sorting, and limit.

The nice part is that you can see the result while building the query.

So instead of writing the full query from scratch and hoping it works, you can build it slowly, check the output, and then use the generated MongoDB query when you need it.

This is especially helpful when you are still learning MongoDB, or when you open a collection after some time and do not remember all the field names.

Final Note

A MongoDB query is simply a question that you ask of your database.

This:

db.orders.find({ status: "paid" })

means:

*What orders are paid?*

This:

db.orders.find({ total: { $gt: 120 } })

translates to:

*What orders are greater than 120?*

Start small.

Add a condition at a time.

Check the output.

Only then do you add any sorting, limiting, or field projection.

That is the simplest way to understand find() queries in MongoDB.

Download for Free

Download VisuaLeaf

MongoDB Access Control - Users, Roles, and Permissions

VisuaLeaf — Fri, 12 Jun 2026 05:29:11 +0000

There are two major aspects when connecting to MongoDB.

One of them is identifying yourself.

The other one is defining what you are permitted to do.

Both aspects are different from each other.

A user could identify itself correctly by using its username and password, yet the user wouldn’t be able to perform any actions with databases, update any document within, add new users, or manage any roles.

All these permissions are provided through RBAC.

Role-Based Access Control, or RBAC, refers to the allocation of specific roles to users in MongoDB. Roles determine what actions can be performed on particular databases or collections.

In my case, I decided to use the streaming_platform_db database, whose collections include:

users
movies
reviews
payments
subscriptions

It is an appropriate choice as not all users would require the same access rights.

For instance, the app requires writing operations.

The data analyst may require reading operations.

The support agent requires viewing users, payments, and subscriptions.

Administrative rights should be reserved for admin tasks.

A quick overview of MongoDB users, roles, databases, and active sessions in VisuaLeaf.

Authentication vs. Authorization

Authentication provides an answer to the following question:

Is this really the person they claim to be?

Authorization provides the answer to the following question:

What can this person do?

In other words, even if support_agent succeeds in logging into MongoDB, it should prevent them from executing update, insert, and delete queries if their role is read.

That is how it should be.

The login was successful. The operation wasn’t.

This proves that the role works.

Sample Environment Configuration

I have configured some users in VisuaLeaf with various roles as follows:

data_analyst@streaming_platform_db   read@streaming_platform_db
streamflix_app@admin                 readWrite@streaming_platform_db
support_agent@admin                  supportViewer@admin, read@streaming_platform_db
admin@admin                          root@admin

A simple configuration, yet it includes most possible scenarios.

The admin user is used for administrative purposes.

The streamflix_app user is used for applications.

The data_analyst user is used for generating and reviewing reports.

The support_agent user is used for support activities that require data verification without making any changes.

MongoDB users and their assigned roles in VisuaLeaf.

Role Definition in MongoDB

The MongoDB role is defined through privileges.

The privilege means:

This operation is permitted on this database/resource.

The operation can be find, insert, update, or remove.

The resource can be a database or an exact collection.

Thus, the role is more than just its name; it is a combination of rules.

For instance,

read@streaming_platform_db

means that the user has the permission to read information from streaming_platform_db.

It doesn’t imply the user is granted access to read all the databases present on the server.

That’s because of the latter part - the database.

Built-In Roles You Will Use Often

MongoDB has numerous built-in default roles, but you don't have to start with all of them.

Most beginners will probably use the following ones first:

Here comes the common temptation to use the root role in every case, which will help avoid access issues.

It will work just fine at the early stage.

However, the problem is that, over time, it will become difficult to trace which user can make changes.

A proper solution is to grant each user only those permissions required for their work.

Creating an Admin User

The admin user normally exists in the admin database.

In the Mongo shell, it may be created like so:

use admin

db.createUser({
  user: "admin",
  pwd: passwordPrompt(),
  roles: [
    { role: "root", db: "admin" }
  ]
})

It gives you total administrative access.

Do not use it for anything except administrative purposes.

It is not needed by the application to simply save review data or manage subscriptions.

Creating an Application User

The application must be able to read and write the data stored in the application’s database.

For this purpose, we can rely on the readWrite permission.

use admin

db.createUser({
  user: "streamflix_app",
  pwd: passwordPrompt(),
  roles: [
    { role: "readWrite", db: "streaming_platform_db" }
  ]
})

This user will be able to manipulate the documents in the streaming_platform_db.

It will have the ability to create new users, save their reviews, update their subscriptions, and record their payments.

However, it will not be able to manage users and roles at the server level.

And this was the very idea behind the user creation process.

Creating an application user with read and write access to the streaming database.

Creating a Support Role with Limited Access

The application user needs readWrite access because the app has to save reviews, update subscriptions, and record payments.

A support user is different.

Support usually needs to check information, not change it.

For example, a support agent may need to answer questions like:

Does this user exist?
Was the payment created?
Is the subscription active?

Giving this user full database access would be too much.

A better option is to create a smaller custom role for support work. In this example, I use a role called supportViewer.

In VisuaLeaf, I can create this role from the Create New Role dialog. The role is created in the admin database, but the permission applies to streaming_platform_db.

Here, I selected two actions:

find
listCollections

This means the role can read documents and list the collections in the database.

In the Mongo shell, the same role would look like this:

use admin

db.createRole({
  role: "supportViewer",
  privileges: [
    {
      resource: { db: "streaming_platform_db", collection: "" },
      actions: ["find", "listCollections"]
    }
  ],
  roles: []
})

The empty collection name means the permission applies to all collections in streaming_platform_db.

The find action lets the user read documents.

The listCollections action lets the user see which collections exist.

It does not include:

insert
update
remove
dropCollection
createIndex
dropIndex
userAdmin
root

So this role can check data, but it does not have full admin power.

That is the point of a custom role: give enough access for the task, but not more than needed.

In the Roles tab, VisuaLeaf also shows custom roles next to the built-in MongoDB roles. In this example, supportViewer appears as a custom role and is assigned to support_agent.

Built-in and custom MongoDB roles shown in VisuaLeaf.

Checking a User’s Access

Once you’ve added users and roles, it is also good to verify what MongoDB actually saved.

To view details about the support user:

use admin

db.getUser("support_agent")

To display the user’s privileges:

use admin

db.getUser("support_agent", { showPrivileges: true })

Since this example also uses the supportViewer custom role, you can check that role too:

use admin

db.getRole("supportViewer", { showPrivileges: true })

This is useful when something seems off.

The user could have been created using the wrong authentication database.

The role may point to the wrong database.

Or the user may have the right role name, but not the privileges you expected.

In VisuaLeaf, you can review this information from the Users tab instead of checking everything only from the shell.

Connecting With a User

When you connect with a MongoDB user, make sure you use the right authentication database.

For example, if support_agent was created in admin, connect like this:

mongosh -u "support_agent" -p "yourPassword" --authenticationDatabase "admin"

Then switch to the app database:

use streaming_platform_db

A read query should work:

db.users.find()

But a write should fail:

db.users.insertOne({
  name: "Test User"
})

If the user only has read, that failure is expected.

It means MongoDB is blocking writes for that user.

Where VisuaLeaf Helps

Mongo shell commands are useful because they show exactly what MongoDB is doing.

But when you have several users and roles, it is easier to review them visually.

In VisuaLeaf, the RBAC Dashboard shows users, roles, databases, and active sessions in one place. You can quickly see which users exist, which roles they have, and whether they have read-only, read-write, or admin access.

This helps when you return to a project later and need to understand the access setup quickly.

A Simple Rule for MongoDB Permissions

Start with the smallest role that works.

Use read when someone only needs to view data.

Use readWrite when the application needs to change data.

Use dbAdmin or userAdmin for specific admin tasks.

Use root only when full control is really needed.

Do not give admin permissions just to avoid access errors. That shortcut usually creates problems later.

Final Setup

In this example, the setup looks like this:

admin           -> root
streamflix_app  -> readWrite
data_analyst    -> read
support_agent   -> supportViewer, read

Each user has a clear purpose.

The admin user handles administration.

The app user works with application data.

The analyst reads data for reports.

The support user can check support-related records without changing them.

This is the main idea behind RBAC in MongoDB.

Give users enough access to do their work, but not more than they need.

Learn more about our RBAC Dashboard feature here: RBAC Dashboard

If you want to download VisuaLeaf, you can do it from here: Download VisuaLeaf

Compare MongoDB Collections Between Local and Atlas

VisuaLeaf — Tue, 09 Jun 2026 08:48:13 +0000

When you work with MongoDB, your data does not always stay in one place.

You may have one database running locally, another one used for staging, and another one hosted in MongoDB Atlas.

At the beginning, they may look the same.

But after a few tests, imports, updates, or small manual changes, they can slowly become different.

And this is where the annoying question appears:

*Is my local collection still the same as the one in Atlas?*

In VisuaLeaf, Collection Compare helps you answer that without opening both collections side by side and checking documents one by one.

For this example, I compared a local payments collection with the same collection from a production cluster in MongoDB Atlas. In VisuaLeaf, I selected the local collection as the source and the Atlas collection as the target.

Here is the Atlas payments collection I used as the target for this comparison.

Why This Is Useful

This kind of comparison is useful because MongoDB projects usually have more than one environment.

You may test payments locally.

Someone else may update data in Atlas.

A staging database may have older documents.

A production collection may contain records that do not exist locally.

At some point, you need to know what is different.

Not in theory.

Not by guessing.

You need to actually see it.

In my example, the source collection is from local development, and the target collection is from MongoDB Atlas.

VisuaLeaf compares both collections and shows the result in a clear summary.

In this comparison, the local payments collection had 312 documents, while the Atlas collection had 300 documents.

Most of them were identical, but not all.

The result showed:

296 identical documents
1 modified document
3 documents missing in source
15 documents missing in target

This is already useful because you do not have to manually count or search for these differences.

You can immediately see where the collections do not match.

Use Filters When You Do Not Want to Compare Everything

Sometimes you do not need to compare the full collection.

For example, in a payments collection, I may not want to compare every failed, pending, or small test payment.

In this case, I can add a simple visual filter and compare only:

status = "completed"
amount > 1000

This keeps the comparison more focused.

Instead of checking the entire collection, VisuaLeaf compares only the payments that match these conditions in both the local database and MongoDB Atlas.

That makes the result easier to review, especially when the collection contains old data, test documents, or payments that are not relevant for the current check.

See What Exists Only in Atlas

One of the tabs shows documents that are missing in the source.

In this example, those are documents that exist in Atlas, but not in the local collection.

This can happen when production has new payments that were never copied locally.

It can also happen when someone inserted data directly in Atlas, or when the local database is simply behind.

The useful part is that VisuaLeaf does not only say “something is missing.”

It shows the document IDs and the fields, so you can inspect what is actually different.

See What Exists Only Locally

The opposite case is also common.

You may have documents locally that do not exist in Atlas.

In my example, VisuaLeaf found 15 documents missing in the target.

That means these documents exist in the local payments collection, but not in the Atlas collection.

This is a very common situation when you test locally.

You insert some data, run a few queries, maybe prepare a demo, and later you forget which documents were only local.

With Collection Compare, you can see those differences directly.

Check Modified Documents

Missing documents are easy to understand.

But modified documents are often more important.

A document may exist in both collections, but one field may have a different value.

In my example, one payment document was modified.

The document exists on both sides, but the amount field is different.

In the source, the amount is 1000.

In the target, the amount is 3000.

This kind of difference can easily create confusion.

Maybe a chart shows a different revenue total.

Maybe an aggregation result looks wrong.

Maybe a report does not match what you tested locally.

The query or aggregation may not be the problem.

The data may simply be different.

Generate a Sync Plan Before Changing Anything

After reviewing the differences, VisuaLeaf can also generate a sync plan.

This is important because you should not sync blindly, especially when you compare local data with MongoDB Atlas.

After the sync plan, VisuaLeaf also asks for confirmation before applying the change.

Here, I can still choose how the modified document should be synced. For example, I can replace the full document or merge only the changed fields.

So the sync is not applied immediately. I can review the change first, choose the strategy, and only then start the sync.

Share the Comparison With Your Team

Collection Compare is also useful when you work with other people.

Maybe one person changed the local data.

Maybe another person updated Atlas.

Maybe someone wants to review the differences before anything is synced.

Instead of explaining everything in a message, you can export the comparison and share it with the team.

VisuaLeaf also lets you protect the exported file with a password, which is useful when the comparison contains real data.

This makes the review easier because everyone can look at the same result.

They can see what is missing, what changed, and what should be checked before moving forward.

Conclusion

Collection Compare is useful when two MongoDB collections look similar, but you are not sure if they really match.

In this example, the local payments collection and the Atlas payments collection were not identical. Some payments existed only locally, some existed only in Atlas, and one payment had a different amount.

With VisuaLeaf, those differences are easier to see before syncing, debugging, or sharing the result with a teammate.

That is the main point of the feature: you do not have to guess what changed between two collections. You can compare them, review the differences, and decide what to do next.

To try this workflow, you can download VisuaLeaf here: https://visualeaf.com/download/

You can also explore the Collection Compare feature here: https://visualeaf.com/features/collection-compare/

NoSQLBooster Alternative - Visual MongoDB Shell Workflow

VisuaLeaf — Thu, 04 Jun 2026 18:00:00 +0000

If you use MongoDB and want a GUI tool to help you work faster, NoSQLBooster is often one of the tools you’ll hear about.

It has a strong reputation for a reason. It gives developers a shell-focused way to work with MongoDB and can handle queries, scripts, aggregations, SQL-style queries, and other database tasks from one place.

But maybe you want something different.

You still want the MongoDB Shell, but not as a separate place where you write commands and then struggle to understand the result.

You want to write a command, run it, inspect the data clearly, save useful scripts, and move into visual query building or aggregation work when it makes sense.

That’s where VisuaLeaf takes a different approach.

It keeps the MongoDB Shell within the workspace while providing visual output, autocomplete, saved scripts, query tools, and aggregation builders.

Why VisuaLeaf Can Be a NoSQLBooster Alternative

NoSQLBooster is a good choice if you want a classic MongoDB IDE built strongly around shell usage, scripting, SQL-style querying, monitoring, and debugging.

VisuaLeaf is better suited for users who want the shell but also want the workflow around it to feel easier to follow.

The difference is simple:

use the shell when writing commands is faster
use visual output when the result is harder to read
use saved scripts when the work repeats
use the visual query builder when filters become annoying to write manually
use the aggregation builder when pipelines become too long to understand at once

So the point is not only “VisuaLeaf has a shell.”

The point is that the shell is connected to the rest of the MongoDB workflow.

Run a Shell Query and Read the Result Immediately

The real difference is visible after you run a command.

For example, you can write a shell query like this:

db.payments.find({
  status: "paid",
  amount: { $gte: 1000 }
})

In a classic shell workflow, you usually continue by reading the output as raw documents.

In VisuaLeaf, the result appears directly below the command, in a visual table view.

So instead of scanning raw JSON, you can immediately see the matching payments, compare amounts, check the currency, and open nested fields like billing or items.

This makes the shell more practical for everyday work.

You still write the command yourself, but the result is easier to read and continue working with.

You can learn more here: https://visualeaf.com/blog/mongodb-shell-visual-output/

Write Commands Faster With Autocomplete

Autocomplete is useful because it helps you move faster while still writing commands yourself.

For example, when you start typing:

db.payments.

You can continue with methods like:

find()
aggregate()
insertOne()
updateOne()
deleteOne()

This helps when you switch between collections, methods, operators, and repeated commands.

You still control the query, but the tool helps you avoid small mistakes and write faster.

Read Commands More Clearly with Syntax Highlighting

When a query has only one condition, it is easy to read.

But once you add dates, operators, and selected fields, the command becomes harder to scan:

db.payments.find(
  {
    status: { $in: ["paid", "refunded"] },
    paidAt: { $gte: ISODate("2026-01-01T00:00:00Z") }
  },
  {
    amount: 1,
    currency: 1,
    method: 1,
    paidAt: 1
  }
)

This is where a clearer editor experience helps.

Fields, values, operators, dates, and brackets are easier to separate, so you can understand the command faster and change it without losing the structure.

Save Useful Scripts and Reuse Previous Queries

A lot of MongoDB work repeats itself.

Maybe you often check failed payments:

db.payments.find({
  status: "failed"
})

Maybe you can check payments from a specific period:


db.payments.find({
  createdAt: { $gte: ISODate("2026-01-01T00:00:00Z") }
})

Or maybe you test the same query with small changes.

These commands should not have to be rewritten every time.

In VisuaLeaf, you can save useful scripts in the Script Library and reopen them later when you need them again.

You can also use Query History to return to commands you already ran, rerun them, and adjust them without starting from zero.

That makes the shell much more practical for everyday work.

Create Queries Without Writing Code

Not every query needs to be written manually.

Sometimes the shell is faster.

Other times, especially with multiple filters or AND/OR logic, visual query building is easier.

VisuaLeaf lets you build queries visually and still see the generated query behind it.

So you can write directly in the shell when that is faster, or build visually when the query becomes harder to follow.

Build MongoDB queries faster with VisuaLeaf’s visual query builder

Create Aggregation Pipelines Step by Step

Aggregations are powerful, but they can quickly become hard to read.

A short pipeline is fine:

db.payments.aggregate([
  { $match: { status: "completed" } },
  { $group: { _id: "$method", totalAmount: { $sum: "$amount" } } },
  { $sort: { totalAmount: -1 } }
])

But once you add more stages, filters, groups, and transformations, the pipeline becomes harder to follow.

That is where a visual aggregation builder helps.

In VisuaLeaf, you can build the pipeline step by step and see the output for each stage. This makes it easier to understand what changed and where.

Build MongoDB aggregation pipelines step by step with live preview

For longer aggregations, a visual pipeline builder can make each stage easier to understand.

Less Switching Between Tools

This is one of the biggest reasons VisuaLeaf feels different.

You do not have to keep moving between a shell, a query builder, an aggregation editor, and another tool for visual results.

In VisuaLeaf, these workflows stay closer together.

You can use the MongoDB Shell, visual query builder, aggregation pipeline builder, and visual result views from one workspace.

Use the shell when the shell is fastest.

Use visual tools when the work becomes harder to follow.

NoSQLBooster vs VisuaLeaf

NoSQLBooster is a strong option for users who want a classic MongoDB IDE focused on shell scripting and developer-oriented workflows.

VisuaLeaf is built with a different perspective.

It keeps the shell available, but connects it with a more visual way of working with MongoDB.

Feature	NoSQLBooster	VisuaLeaf
MongoDB shell	Embedded mongosh engine	Full shell compatibility with visual output
Autocomplete	True IntelliSense	Context-aware autocomplete
Syntax highlighting	Editor assistance for writing code	Syntax highlighting in query and aggregation editors
Script history	More focused on shell-based work	Script management and history
Saved scripts	User-saved query scripts in “My Queries”	Save scripts to a library and organize by project
Visual query builder	Not highlighted as the main workflow	Visual query builder with real-time query preview
Aggregation pipeline builder	Aggregation is supported	Visual pipeline builder with stage preview and code mode
Visual result exploration	Results tab and data viewer	Tree, Table, BSON, and Explain views
Charts and dashboards	Not the main focus	Query- and aggregation-driven chart tools
Best for	Shell-heavy IDE workflow with SQL, monitoring, and debugging	Visual MongoDB Shell workflow with nearby builders and views

Conclusion

NoSQLBooster has a strong reputation for a reason.

It is a powerful MongoDB IDE, especially for users who enjoy shell-heavy workflows.

But if you want a different way to work with MongoDB Shell, VisuaLeaf is worth considering.

It keeps the shell available, but makes the workflow around it more visual.

You can write commands, use autocomplete, inspect results, save scripts, build queries, create aggregations, and continue working with MongoDB from one place.

If you want to try it yourself, explore the MongoDB Shell in VisuaLeaf and see how it fits into a more visual MongoDB workflow.

Download for Free

DEV Community: VisuaLeaf

How to Import JSON into MongoDB and Export to CSV with Data Masking

The workflow

The incoming JSON file

Why use a temporary collection?

Generate field mappings every time the JSON structure changes

Copy the batch into the main orders collection

Duplicate key errors are useful, but they still need a fix

Export the weekly report from the main collection

Mask customer data during export

What maskName(value) does

What hash(value) does

Schedule the workflow

What this workflow actually solves

Final result

How to Copy and Sync a Local MongoDB Collection to Atlas

What I used

Preparing the Atlas connection

Creating the sync job

Mapping the local collection to Atlas

Choosing Full sync

Reviewing and launching the job

Verifying the initial copy in Atlas

Test 1: Inserting a new local document

Test 2: Updating the local document

Test 3: Deleting the local document

When this workflow is useful

How this differs from other Atlas migration methods

What I would still verify before using it in production

Final takeaway

Want to try it?

References

7 MongoDB Query Mistakes That Return the Wrong Results

1. Forgetting the Curly Braces

2. Treating $or Like a Regular Object

3. Querying Nested Fields Like They Are Flat

4. Typing the Same Field Twice

5. Treating Dates Like Plain Text

6. Expecting Text Search to Work Automatically

7. Reading $or Logic Backwards

One More Thing to Do before Using Your Query

DBeaver Alternative for MongoDB Queries, Aggregations, and Visual Workflows

Why MongoDB Users May Want a Different Tool

Build MongoDB Queries Visually

Build Aggregation Pipelines Step by Step

Read MongoDB Documents More Clearly

See the MongoDB Schema

Turn Query Results Into Charts

Mongo Shell for Developers

DBeaver vs VisuaLeaf for MongoDB Users

Final Thoughts

MongoDB vs PostgreSQL: The Arguments Everyone Gets Wrong

"PostgreSQL JSONB is basically MongoDB"

"MongoDB is schemaless"

"MongoDB loses data"

"MongoDB is only for lazy devs"

"Postgres is always better"

Why JSONB vs BSON Benchmarks Are Kinda Misleading

Durability Isn't a Mongo Weakness Anymore

Where Mongo Actually Wins

Documents that get mutated a lot

Deeply nested data

Query patterns you can't predict yet

Horizontal write scaling

Document-centric workloads

Big documents that change a lot

Where Postgres Still Wins

Complex joins

Referential integrity

Reporting / analytics

Heavily relational data

Multi-row transactions

A Java vs Python Way of Thinking About It

Different Tools, Different Assumptions

A Quick Note on Where This Is Coming From

PostgreSQL JSONB vs MongoDB BSON: The Real Architectural Tradeoffs

Why the format matters more than the API

BSON: a binary echo of MongoDB's runtime

JSONB: a parse tree frozen on disk

Binary blobs and where the type systems leak

2. Treating `$or` Like a Regular Object

7. Reading `$or` Logic Backwards

Use AI Assistant when you need a faster starting point