DEV Community: VisuaLeaf

What changed in MongoDB 9.0, and how can it help in everyday database work? Practical examples in VisuaLeaf show the new behavior and compare results with MongoDB 8.2.5.

VisuaLeaf — Wed, 14 Oct 2026 17:43:06 +0000

Roxana-Maria Haidiner

Oct 14

What's New in MongoDB 9.0: Query Settings, Validation, and Resource Limits

#mongodb #nosql #database #softwaredevelopment

10 min read

How to Open a SQLite Database: Query and Explore Your Data

VisuaLeaf — Wed, 14 Oct 2026 17:36:15 +0000

You have a SQLite file and want to see the information inside it. To open a SQLite database, select the file in software that can read SQLite, such as VisuaLeaf. You can then browse the tables and use SQL to find the information you need.

SQL is the language you use to tell a database what you want. A query is one of those requests. It might ask for ten inspection records, the name of a technician, or the number of checks that failed.

This guide uses an example inspection database. You’ll open the file, browse its tables, join related records, read JSON values, export results to Excel, and create a chart. If you follow along with your own database, replace the example table and column names with yours.

First, understand what is inside the file

SQLite stores data in a database file. You don't need to set up a separate database server to open it.

Inside the file, the data is organised into *tables*. A table looks a little like a spreadsheet: it has rows and columns.

The inspections table’s columns on the left and five inspection records on the right.

The information is split across several tables:

sites holds details about the places being inspected,
technicians holds details about the people doing the inspections,
inspection_items holds the results of individual checks.

An inspection can therefore have one row describing the visit and several other rows describing its checklist items.

Open your SQLite database in VisuaLeaf

SQLite files often end in .db, .sqlite, or .sqlite3.

In VisuaLeaf:

Create a connection and choose SQLite.
Select your existing database file.
Connect, then expand main and *Tables* in the sidebar.
Open a table to see its records.

You select a file instead of entering a server address, port, or database username. If your database is already connected, go straight to its tables.

main is SQLite's name for the primary database opened by that connection. You don't need to create another database with that name.

Connecting to the local field_inspections.sqlite database in VisuaLeaf.

If you don’t have a SQLite database yet, click *New DB* in the connection form to create one. It starts empty, so you can add your own tables and data. The examples below use our existing inspection database.

Read a few inspections with SQL

Open inspections in the data view to browse its rows. You can also choose exactly which columns to display using the SQL Editor:

SELECT id, status, risk_score
FROM inspections
ORDER BY id
LIMIT 10;

Read this query one line at a time:

SELECT id, status, risk_score chooses the three columns to show.
FROM inspections tells SQLite which table to read.
ORDER BY id sorts the records by their identifier, from smallest to largest.
LIMIT 10 asks for at most ten rows.

This query reads data. It doesn't change the records.

Reading ten inspection records, ordered by ID, with their statuses and risk scores.

The id column is the inspection's *primary key*: the value that identifies that row. Keep it in your results so you can find the same inspection again.

Look at the values before writing a filter. A column called status doesn't tell you which words the application stores there. Check the records rather than guessing whether a status is called complete, completed, or something else.

What do the column types mean?

Open Table Management for sites. It shows how each column is defined.

The sites table in VisuaLeaf, showing each column’s data type, whether it allows missing values (NULL), and its default value.

The screenshot includes three common SQLite types:

Data type	What it stores	Example columns
`INTEGER`	Whole numbers, such as 1, 2, or 3	`id`
`TEXT`	Text, such as names and cities	`name`, `city`
`REAL`	Numbers with decimals, such as 44.43	`latitude`, `longitude`

The active column has a *default* of 1. That means SQLite supplies 1 when a new row leaves this column out of the insert.

A default alone also allows someone to enter another value. To restrict active to 0 and 1, the table would need a *constraint*, which is a rule that data must follow. For example, CHECK (active IN (0, 1)) checks that the value is one of those two numbers. A separate NOT NULL rule rejects a missing value.

Click *Show DDL* to see the SQL that defines the sites table. DDL means Data Definition Language. This definition shows the column types and rules, such as primary keys, foreign keys, NOT NULL, and default values.

You can also inspect the table's *indexes*. An index is a lookup structure, a little like the index at the back of a book. It can help SQLite find certain values without reading every row. Having an index on a column does not automatically connect it to another table.

SQLite is flexible with data types. In a regular table, a column marked INTEGER may still accept text. The declared type tells you what the column is intended to store, but it does not always enforce that type.

Understand foreign keys and join related tables

The inspections table stores site_id and technician_id to identify where each inspection took place and who performed it. The site and technician details live in their own tables.

A *primary key* identifies a specific row. For example, sites.id identifies each site.

A *foreign key* is a rule that connects a value in one table to a matching key in another. Here, inspections.site_id refers to sites.id.

If an inspection has site_id = 7, it belongs to the site whose id is 7. You can look up that site’s name and city in sites, without copying those details into every inspection row. Several inspections can have the same site_id because you can inspect the same site more than once.

The same idea applies to technician_id: it refers to the technician’s id in technicians.

The ER diagram shows these connections as lines between the tables.

Foreign keys connect each inspection to its site and technician. The diagram shows these relationships and the available rules for handling deletions.

A *join* uses those matching values to bring information from different tables into one result:

SELECT
    inspections.id,
    sites.name AS site,
    technicians.full_name AS technician,
    inspections.risk_score
FROM inspections
LEFT JOIN sites
    ON inspections.site_id = sites.id
LEFT JOIN technicians
    ON inspections.technician_id = technicians.id
ORDER BY inspections.id
LIMIT 10;

A name such as sites.name means “the name column in the sites table.” Writing the table name first makes it clear which table we mean.

The query starts with inspections, matches each one to its site, and then matches it to its technician. The result puts the inspection ID, both names, and the risk score together.

LEFT JOIN keeps the inspection in the result even if a matching site or technician is missing. SQLite shows NULL for the missing information. NULL means no value. A normal inner JOIN would leave out inspections without a match.

A null name alone doesn't prove a record is missing: the related row could exist but have no name. Check the matching IDs before deciding what is wrong.

Joining three SQLite tables to show each inspection’s site, technician, and risk score.

You can also create this query visually with VisuaLeaf’s Query Builder, without writing SQL. Select the tables, connect their matching columns, and choose which fields to include in the result.

Joining tables visually in VisuaLeaf’s Query Builder, filtering for risk scores above 2, and sorting inspections by ID.

Is SQLite checking the relationships?

SQLite can have foreign keys defined while their enforcement is turned off. To check the current connection’s setting, run:

PRAGMA foreign_keys;

A result of 1 means checking is on; 0 means it is off. To enable it, run this before making changes, outside an active transaction:

PRAGMA foreign_keys = ON;

This setting applies to the current connection. It helps prevent new invalid references, but it does not fix existing ones.

Query JSON data in SQLite

One database column can hold several related details as JSON. In our inspections table, device_info stores the device platform, app version, battery percentage, and whether the inspection was recorded offline.

Start by viewing the original values:

SELECT id, device_info
FROM inspections
LIMIT 3;

You can see the result on the left of the screenshot. Each device_info cell contains named values, such as "platform":"android". Here, platform is the name and android is its value.

To display the platform separately, use json_extract():

SELECT
    i.id AS inspection_id,
    s.name AS site,
    json_extract(i.device_info, '$.platform') AS platform,
    json_extract(i.device_info, '$.app_version') AS app_version,
    json_extract(i.device_info, '$.battery_percent') AS battery,
    i.risk_score
FROM inspections AS i
JOIN sites AS s ON s.id = i.site_id
WHERE json_extract(i.device_info, '$.offline') = 1
ORDER BY i.risk_score DESC
LIMIT 12;

Read that expression in three parts:

device_info is the column containing the JSON.
'$.platform' tells SQLite to find the value named platform inside it.
AS platform names the result column.

This creates a column in your query results. It does not add a new column to the database or change the stored JSON.

The longer query on the right extracts the platform, app version, and battery percentage. It also adds the site name using a join.

Its WHERE condition keeps inspections where offline is true. SQLite returns that JSON value as 1. Finally, ORDER BY ... DESC puts the highest risk scores first, and LIMIT 12 returns at most twelve rows.

Original device JSON on the left; extracted details for offline inspections on the right.

Export SQLite query results to Excel

Once your query returns the information you need, you can export it to an Excel workbook. This lets you share the results with someone who doesn’t use a database tool.

Open the export form for your query, then:

Set *Source Type* to *Query*.
Select your SQLite connection and the main database.
Check the SQL in the *Query* field.
Set *Target Type* to *Excel Workbook*.
Choose a file location and name, such as inspections.xlsx.
Click *Export Now*.

For our JSON query, the exported columns contain the inspection ID, site, platform, app version, battery percentage, and risk score.

The export follows your query’s filters and limits. If you keep LIMIT 12, it exports at most twelve rows. Remove that limit if you want all matching inspections.

The Excel file contains a copy of the query results. Editing it does not update your SQLite database.

Exporting SQLite query results to an Excel workbook.

Count and chart failed checks by category

Use GROUP BY to group failed checklist items by category, then COUNT(*) to count them:

SELECT
    issue_category,
    COUNT(*) AS failed_checks
FROM inspection_items
WHERE result = 'fail'
GROUP BY issue_category
ORDER BY failed_checks DESC
LIMIT 8;

The query returns up to eight categories with the most failed checks.

In VisuaLeaf’s Chart Builder, choose *Pie, set *Category** to issue_category, and *Value* to failed_checks. Each slice shows that category’s share of the failed checks returned by the query.

These totals count checklist items, not inspections. One inspection can contain several failed items. Remove LIMIT 8 if you want to include every category with failed checks.

Each slice shows a category’s share of the failed checks included in the chart.

Conclusion

Start by opening your SQLite file and checking its tables and columns. Then use a small SELECT query to read a few records before adding filters, joins, or calculations.

Once the results contain what you need, you can export them to Excel or turn them into a chart. Check your filters and row limits first—they determine which data appears in the final result.

[Boost]

VisuaLeaf — Fri, 18 Sep 2026 08:52:14 +0000

Roxana-Maria Haidiner

Sep 18

MongoDB Sharding: Manage a Sharded Cluster Visually

#mongodb #database #software #softwaredevelopment

5 min read

Learn how to use DuckDB for local analysis: open a database, query CSV and Parquet files, inspect relationships, edit data, and create charts.

VisuaLeaf — Thu, 03 Sep 2026 07:21:04 +0000

Roxana-Maria Haidiner

Sep 3

How to Use DuckDB for Local Data Analysis

#duckdb #sql #database #softwaredevelopment

8 min read

mongodump Tasks Automate and Schedule MongoDB Backups

VisuaLeaf — Mon, 31 Aug 2026 11:00:28 +0000

Running a MongoDB backup once is not difficult. With MongoDB Database Tools installed, the complete PowerShell command can be as short as this:

& "C:\Program Files\MongoDB\Tools\100\bin\mongodump.exe" `
  --uri="mongodb://127.0.0.1:27017" `
  --db="gui_test_db" `
  --gzip `
  --out="C:\MongoDBBackups\gui_test_db"

This example uses an unauthenticated local MongoDB deployment. Authenticated or remote deployments also require the appropriate credentials, authentication database, TLS settings, and connection options.

mongodump is MongoDB's command-line utility for creating a binary export of a database or collection. The problem is rarely the first run. It is repeating the same backup every day or week, keeping the settings consistent, using a fresh destination, and checking whether the operation actually completed.

That is where a saved task becomes useful. In VisuaLeaf, the same binary dump can be configured once, run manually when needed, scheduled, and checked later from its execution history.

Save the Same mongodump as a VisuaLeaf Task

Open *Task Manager*, create a new job, and choose the binary dump/restore operation. Select *Export to Dump* for the operation.

The full gui_test_db database saved as a reusable mongodump task in VisuaLeaf.

The task should have a name that still makes sense when you return to it later. I used:

Full Database mongodump – 4.6 GB (Gzip)

This is more useful than a generic name such as Backup or New Job. It tells me the scope, approximate source size, and whether compression is enabled.

For the source, I selected the complete gui_test_db database running locally on port 27017. Its uncompressed data size was approximately 4.6 GB, spread across four collections:

dataset_30000
large_collection_4GB
large_docs_10mb
medium_docs_1mb

The source panel displayed the database statistics before the job ran. This gave me a quick check that I had selected the full database before creating several gigabytes of output.

Back Up a Database or One Collection

The correct scope depends on why you need the backup.

Choose a *collection dump* when you only need one dataset, want to move a collection between environments, or need a smaller restore unit. Choose a *database dump* when the job should include all collections and their metadata.

Be deliberate here. A successful task using the wrong source is still the wrong backup.

Choose the Output Folder and Enable Gzip

I saved the VisuaLeaf output in its own folder and enabled *Compress with Gzip*. A separate folder for every run keeps completed backups distinct and prevents CLI files, task files, or partial attempts from being mixed.

The job summary also showed *auto threads* and *no timeout*. Auto threads leaves the worker configuration to VisuaLeaf. The gear icon opens the advanced settings if the task needs a specific thread limit or timeout. I left both settings at their defaults for this workflow.

A full gui_test_db backup configured as a binary dump task in VisuaLeaf.

After choosing the source and destination, save the job. The connection, database, folder, compression, and operation settings remain attached to the task, so the next backup does not require rebuilding the command.

Schedule and Monitor the MongoDB Backup

You can still start a saved job manually, but scheduling is the main reason to turn this workflow into a task. VisuaLeaf's Task Manager documentation lists one-time, hourly, daily, weekly, monthly, and custom cron schedules.

Choose the frequency based on how much recent data the application could afford to lose. A weekly backup is easy to manage, but it may be inadequate for a database that changes throughout the day.

Use a dated destination for recurring runs and decide how many older backups to keep. Otherwise, the task may work perfectly while the backup drive quietly runs out of space.

The full database dump is scheduled to run every day at 6:00 AM.

After a run, *Execution History* provides a detailed dump summary. In my test, it recorded:

Total duration, collections, documents, and database size.
The thread used for each collection.
Document count and size per collection.
Individual collection duration and processing speed.

The completed dump included four collections, 30,449 documents, and 4.72 GB of source data.

*Performance note:* On the same Windows machine, with Gzip enabled and the same 4.72 GB database, the VisuaLeaf task completed in 4 minutes 40 seconds. The equivalent direct mongodump CLI run took 6 minutes 12 seconds, so VisuaLeaf finished about 25% faster in this test. Results may vary depending on the hardware, storage, data, and task settings.

The equivalent direct mongodump CLI run completed in 6 minutes and 12 seconds and produced 3.1 GB of compressed output.

Before treating the exported files as a valid backup, check that the execution status is *Completed*. A cancelled or failed run may still leave partial files in the destination.

What Files Does the Backup Create?

A compressed directory dump creates one .bson.gz data file and one .metadata.json.gz file for each collection. The VisuaLeaf output for gui_test_db contained:

dataset_30000.bson.gz
dataset_30000.metadata.json.gz
large_collection_4GB.bson.gz
large_collection_4GB.metadata.json.gz
large_docs_10mb.bson.gz
large_docs_10mb.metadata.json.gz
medium_docs_1mb.bson.gz
medium_docs_1mb.metadata.json.gz

The BSON files contain the documents. The metadata files contain collection options and index definitions used during restoration. MongoDB describes this directory structure in its official [mongodump](https://www.mongodb.com/docs/database-tools/mongodump/) documentation.

The 4.6 GB test database produced approximately 3.18 GB of compressed output in VisuaLeaf. That result is specific to this data. A similarly sized database containing images, encrypted values, or already compressed content may shrink much less.

The compressed gui_test_db backup contains eight BSON and metadata files totaling 3.18 GB.

Can You Run mongodump in MongoDB Compass?

No. MongoDB Compass can export an individual collection as JSON or CSV, but MongoDB explicitly says Compass is not a backup tool. It does not create a full binary database dump containing compressed BSON files and collection metadata. For that, MongoDB directs users to its separate Database Tools. See the official Compass import and export documentation.

MongoDB Compass exports collection data as JSON or CSV; it does not create a binary database backup.

This is an important difference between exporting data and creating a backup. JSON can preserve MongoDB types when the correct Extended JSON format is used, while CSV can lose type information. Neither Compass export is the same workflow as a BSON database dump intended for mongorestore.

Restore the BSON Backup in VisuaLeaf

Creating compressed BSON files is only half of a backup test. You also need to confirm that MongoDB can restore them.

To avoid changing the original gui_test_db database, I created a separate VisuaLeaf restore job. Under *Source Configuration, I selected *Restore (BSON)** and chose the folder containing the .bson.gz and .metadata.json.gz files.

For the target, I selected the same MongoDB connection and entered a new database name: gui_test_db_restore. Because that database did not exist, VisuaLeaf indicated that it would create it when the restore job ran.

VisuaLeaf restore job configured to import a compressed BSON dump into a new MongoDB database.

This operation uses the binary dump-and-restore workflow. It reads the BSON data and collection metadata without converting the documents to JSON or CSV.

When restoring to a different deployment, check version compatibility first. MongoDB requires the source and destination to use the same major version or feature compatibility version. See the official mongodump behavior documentation.

After the job finishes, check the restored database rather than relying only on the Completed status. The restore took 7 minutes and 34 seconds and recreated all four collections with 30,449 documents:

Four collections.
30,449 documents in total.
30,000 documents in dataset_30000.
292 documents in large_collection_4GB.
57 documents in large_docs_10mb.
100 documents in medium_docs_1mb.
The expected collection indexes and options.

VisuaLeaf restored all four collections and 30,449 documents from the compressed BSON dump.

The document counts matched the source, confirming that the BSON files could be restored successfully. A production restore test should also verify indexes, collection options, and several real application queries.

Do not restore a test dump over the only copy of your original database. Use a new database name or a separate development environment.

A backup is not verified until the restore finishes successfully and the restored data matches the source.

If mongodump Does Not Run on Windows

Two small Windows problems appeared during this test.

If PowerShell says that mongodump is not recognized, MongoDB Database Tools may be installed without its bin directory being added to PATH. Using the complete path to mongodump.exe, as shown in the opening command, avoids that problem.

A connection error can also mean that the command is using the wrong host or port. One attempt used localhost:27019, while the current MongoDB instance was listening on 27017. Check the connection used by VisuaLeaf or MongoDB Compass before retrying.

Cancelling a dump may leave partial files in the destination. Delete those incomplete files or use a new output folder before starting another backup.

MongoDB Backup Limitations to Plan For

A mongodump backup still needs consistency planning, safe storage, and restore testing.

Limitation	Why it matters	What to do
Writes continue during the dump	A database-scoped dump may not represent one exact point in time.	`--oplog` cannot be combined with this `--db` command; it requires a full replica-set member dump. Use another backup method when exact point-in-time consistency is required.
Collection names differ only by capitalization	Directory dumps may conflict on case-insensitive Windows and macOS file systems.	Avoid ambiguous collection names or use archive output with the CLI.
The backup stays on the MongoDB machine	Disk failure, device loss, or ransomware could affect the database and backup together.	Keep another copy on separate or off-machine storage.
The backup is never restored	A Completed status and BSON files do not prove that the backup is usable.	Restore into a separate database and verify document counts, indexes, and collection options.
Old backups are never removed	Scheduled dumps can eventually fill the destination disk.	Define a retention policy and monitor available storage space.

MongoDB positions mongodump and mongorestore mainly for smaller deployments; larger or business-critical systems may require a different backup strategy.

Conclusion

A reliable MongoDB backup workflow does not end when files appear in a folder. It ends when those files can be restored, and the resulting database has been verified.

The command line remains useful for one-off dumps and scripts. In VisuaLeaf, you can save both export and restore jobs, schedule repeated backups, and review their status, duration, history, and logs. You still need off-machine copies, retention rules, consistency planning, and restore tests, but the recurring steps are easier to manage from one place.

PostgreSQL JSONB: Query, Update, and Index JSON Data

VisuaLeaf — Tue, 18 Aug 2026 11:20:25 +0000

JSONB allows you to store JSON data within a PostgreSQL table row. It is suitable when certain columns remain unchanged, while the remaining columns may vary across rows.

Let us take the support tickets table, where the status, priority, and the date a ticket was created cannot change. However, the client name, environment, tags, and even error details may be optional and have different formats. That is why the optional content may be stored in the JSONB field

This storage process is easy enough. However, you need answers to questions such as how to find a nested value, update a single field, or create an effective index for your database engine.

This article explores how to achieve that goal using a support_tickets table and the corresponding details column.

PostgreSQL JSONB operations used in this guide

We’ll use each of these against the same support_tickets.details column, so you can see how querying, updating, and indexing work together.

Create the support tickets table

CREATE TABLE support_tickets (
    ticket_id  BIGINT GENERATED ALWAYS AS IDENTITY PRIMARY KEY,
    status     TEXT NOT NULL,
    priority   TEXT NOT NULL,
    created_at TIMESTAMPTZ NOT NULL DEFAULT NOW(),
    details    JSONB NOT NULL
        CHECK (jsonb_typeof(details) = 'object')
);

I kept status, priority, and created_at outside JSONB because they have stable types and are useful for filtering and sorting. The less predictable ticket context goes into details.

Here is one record used in the test:

INSERT INTO support_tickets (status, priority, details)
VALUES (
    'open',
    'high',
    '{
      "customer": {
        "name": "Trevor Lisbon",
        "plan": "Professional"
      },
      "environment": {
        "browser": "Chrome",
        "os": "Windows 11",
        "appVersion": "4.8.2"
      },
      "tags": ["sync", "postgresql"],
      "error": {
        "code": "SYNC_TIMEOUT",
        "retryable": true
      }
    }'::jsonb
);

The CHECK constraint confirms that details contains a JSON object. It does not guarantee that customer.plan exists or that tags is always an array. JSONB validates the JSON format, not your complete application schema.

PostgreSQL table with regular columns and nested JSONB data displayed in VisuaLeaf.

Query nested JSONB values

PostgreSQL provides two operators that look similar but return different data types:

Use -> when you want an object or array to remain JSONB.

Use ->> when you need a scalar value for an ordinary SQL comparison.

This query returns the complete customer object and extracts the plan as text:

SELECT
    ticket_id,
    details -> 'customer' AS customer,
    details -> 'customer' ->> 'plan' AS plan
FROM support_tickets
WHERE ticket_id <= 4
ORDER BY ticket_id;

Expanding the customer JSONB object while plan is returned as text.

A common mistake is to use -> for the final value:

WHERE details -> 'customer' -> 'plan' = 'Professional'

The left side is JSONB, while Professional is being treated as a SQL string. PostgreSQL may return:

invalid input syntax for type json
Token "Professional" is invalid.

The clearer fix is:

WHERE details -> 'customer' ->> 'plan' = 'Professional'

To filter by a nested value, use ->> for the final part of the path:

SELECT
    ticket_id,
    status,
    details -> 'customer' ->> 'name' AS customer_name
FROM support_tickets
WHERE details -> 'error' ->> 'code' = 'SYNC_TIMEOUT';

Filtering tickets by a nested JSONB error code and returning the customer name as text.

If a row has no error object, PostgreSQL returns SQL NULL for that expression. It does not fail.

Search inside a JSONB array

You can search the tags array with the ? operator:

SELECT ticket_id, status, details -> 'tags' AS tags
FROM support_tickets
WHERE details -> 'tags' ? 'postgresql';

This assumes that tags contains an array of strings. If some rows store "tags": "postgresql" instead, the data is valid JSONB but has the wrong shape for this query.

Match part of a document with `@>`

The containment operator checks whether one JSONB value contains another:

SELECT ticket_id, status, details -> 'error' AS error
FROM support_tickets
WHERE details @> '{
  "error": {
    "code": "SYNC_TIMEOUT"
  }
}'::jsonb;

Using @> to find tickets containing the SYNC_TIMEOUT error object.

The structure must match the document. This does not work:

WHERE details @> '{"code": "SYNC_TIMEOUT"}'::jsonb

code is nested under error; it is not a top-level key. This matters when you add a GIN index, because containment queries can use that index directly.

Update a nested value with `jsonb_set`

Ticket 1 was reproduced in version 4.8.4. Instead of replacing the entire details document, I updated only environment.appVersion:

UPDATE support_tickets
SET details = jsonb_set(
    details,
    '{environment,appVersion}',
    to_jsonb('4.8.4'::text),
    false
)
WHERE ticket_id = 1
RETURNING
    ticket_id,
    details -> 'environment' AS environment;

The result shows appVersion as 4.8.4, while browser and os remain unchanged.

Updating environment.appVersion while preserving the other JSONB fields.

The final false means the key must already exist. The ::text cast is also important; without it, PostgreSQL may not know which type to convert:

could not determine polymorphic type because input has type unknown

When the parent object is missing

jsonb_set can create the final key, but not a missing parent object. Ticket 3 has no error object, so updating error.firstSeenAt would run without an error but change nothing.

This version creates the parent when needed:

UPDATE support_tickets
SET details = jsonb_set(
    details,
    '{error}',
    COALESCE(details -> 'error', '{}'::jsonb)
        || jsonb_build_object(
            'firstSeenAt',
            '2026-08-03T11:05:00Z'
        ),
    true
)
WHERE ticket_id = 3
RETURNING details -> 'error' AS error;

RETURNING lets you confirm that the field was actually added.

Creating the missing error object.

Add a GIN index for containment searches

For the indexing test, I added 40,000 generated tickets. The table contained 40,004 rows in total, while the original four remained available for the earlier examples.

Because the query uses @> against details, I created a containment-focused GIN index:

CREATE INDEX idx_support_tickets_details_gin
ON support_tickets
USING GIN (details jsonb_path_ops);

ANALYZE support_tickets;

jsonb_path_ops works well for containment searches, but it does not support every JSONB operator. For example, it cannot support the ? operator used in the tags query.

I then opened the same query in VisuaLeaf’s Explain view:

SELECT ticket_id
FROM support_tickets
WHERE details @> '{
  "error": {
    "code": "SYNC_TIMEOUT"
  }
}'::jsonb;

PostgreSQL found 402 matching tickets and used idx_support_tickets_details_gin through a Bitmap Index Scan.

The JSONB query uses the GIN index instead of scanning the full table.

The index worked for this query and dataset. PostgreSQL may still choose a sequential scan for a small table or when many rows match.

When to use JSONB

JSONB is useful for flexible data, but stable fields usually belong in regular columns.

In this example, environment and error fit inside JSONB. Fields such as status, priority, and created_at are better as regular columns.

I ran these examples in VisuaLeaf, using its SQL editor, nested JSONB table view, and visual query plan to inspect the results.

References

MongoDB Schema Design: Build or Reverse Engineer Visually

VisuaLeaf — Thu, 06 Aug 2026 11:45:16 +0000

MongoDB collections can become difficult to understand once they contain nested objects, arrays, references, and documents with slightly different structures.

Looking at one JSON document at a time shows you the data, but not the complete model. It is harder to see how collections connect, which fields use inconsistent BSON types, or whether a value is embedded or referenced elsewhere.

The opposite problem happens when the database does not exist yet. You may know which collections and fields you need, but reviewing the design across separate JSON files or application models is not easy.

VisuaLeaf’s Visual Schema supports both directions:

Generate a diagram from an existing MongoDB database.
Design a new schema from an empty diagram.
Keep the schema virtual or materialize it into real collections.

I tested both workflows using a travel-planning database containing collections such as travelers, places, flights, accommodations, restaurants, activities, carRentals, and vacationPlans.

VisuaLeaf generates a visual MongoDB schema showing collections, fields, BSON types, and relationships in the TravelPlannerDemo database.

Although this guide focuses on MongoDB, VisuaLeaf’s Visual Schema can also be used with SQL databases. If you’re deciding which database model fits your project or want to compare their structures, read MongoDB vs PostgreSQL: What’s the Difference?.

Reverse engineer an existing MongoDB database

If your database already contains data, you can generate a Visual Schema from its collections.

Connect to MongoDB, open *Visual Schema*, and select the database you want to analyze. VisuaLeaf reads the existing documents and creates a diagram containing:

collections and fields;
detected BSON types;
embedded objects;
arrays and their nested fields;
detected relationships between collections.

In my TravelPlannerDemo database, the generated diagram included the main travel collections and their nested structures.

For example, vacationPlans contains simple fields such as title, status, and createdAt, but it also includes more complex structures:

budget and dates as embedded objects;
itinerary, checklist, and documents as arrays;
destinationIds and travelerIds as arrays of references;
ownerTravelerId and selectedAccommodationId as individual references.

Instead of opening several documents to understand how these fields fit together, I could inspect the structure in one diagram.

This is particularly useful when you are working with a database you did not design, or when the structure has changed, but its documentation has not.

Review the detected structure

Here’s the trap most of us fall into: reverse-engineering a database shows what’s currently stored, not what was actually intended.

MongoDB allows documents in the same collection to have different fields and BSON types. For example, most documents might store a date correctly:

{
  createdAt: ISODate("2026-07-18T09:30:00Z")
}

while an older import stores it as a string:

{
  createdAt: "2026-07-18"
}

These values may look similar in a table, but one has the BSON type date and the other has the type string.

The same problem can occur with identifiers. A field such as ownerTravelerId may contain an ObjectId in most documents but a string in others. That difference matters when you try to connect it to travelers._id.

The generated schema represents the data VisuaLeaf analyzed. Rare fields may also be absent if they do not appear in the sampled documents. Review unusual records and any fields with multiple detected types before using the diagram as your final model.

Review and add relationships

MongoDB does not store relationships as enforced foreign keys. It stores the reference value, but the meaning of that value often needs to be confirmed.

In the travel database, relationships can connect fields such as:

vacationPlans.ownerTravelerId → travelers._id
vacationPlans.travelerIds[] → travelers._id
vacationPlans.destinationIds[] → places._id
vacationPlans.selectedAccommodationId → accommodations._id

Other collections use similar connections:

accommodations.placeId → places._id
restaurants.placeId → places._id
activities.placeId → places._id
flights.passengers.travelerId → travelers._id

Check both ends before accepting or adding a relationship. An ObjectId does not match a string containing the same characters.

For example, these two values use different BSON types:

ObjectId("66af9138ad73c91224345c10")

"66af9138ad73c91224345c10"

The diagram can document a relationship, but it does not make MongoDB enforce it. Your application can still insert an ownerTravelerId that does not exist in travelers.

The generated diagram may also need some visual cleanup. In a database with many related collections, lines can overlap and detected connections may not represent the relationship you intended. Reposition the collections and review each relationship rather than accepting every connection without checking.

A closer look at nested fields, BSON types, arrays, and relationships between `_vacationPlans___,__ _places___, and__ _accommodations`_ in VisuaLeaf.

Modify the generated schema

A reverse-engineered schema does not have to remain a read-only picture of the current database.

You can use it as a starting point and then:

add or remove fields;
correct BSON types;
define embedded objects and arrays;
add missing relationships;
remove incorrect relationships;
reorganize the diagram.

In this example, I added a new optional travelStyle field to vacationPlans. I also manually connected destinationIds to places._id to represent the reference between the two collections.

The same collection contains embedded data as well. The budget object belongs to one vacation plan, so storing it inside the document keeps the related values together. destinationIds, however, contains references to documents stored in the places collection.

vacationPlans
├── budget
│   ├── currency
│   ├── estimatedTotal
│   └── paidSoFar
├── dates
├── itinerary[]
├── ownerTravelerId
├── travelerIds[]
└── destinationIds[]

This shows both modeling approaches in the same collection: embedded data for information owned by the vacation plan and references for information stored elsewhere and reused.

Changing the virtual schema does not automatically migrate existing documents. If you rename a field, change its type, or move it into an embedded object, the records already stored in MongoDB remain unchanged.

The diagram describes the proposed model. Data migration remains a separate operation.

Design a new MongoDB schema from scratch

You can also use Visual Schema before the database exists.

Start with an empty diagram and add the collections you need. You can then define their fields, BSON types, embedded structures, arrays, and relationships.

For this example, I created a small tour-booking schema with two collections:

Collection	Example fields
`departures`	`_id`, `packageId`, `startDate`, `capacity`, `meetingPoint`, `status`
`reservations`	`_id`, `departureId`, `bookingReference`, `leadGuest`, `totalAmount`, `paymentStatus`, `createdAt`

The leadGuest field is an embedded object containing fields such as fullName and email. The relationship connects:

reservations.departureId → departures._id

This represents a one-to-many relationship: one departure can have multiple reservations.

Defining the schema visually makes several problems easier to notice:

references pointing to the wrong field;
incorrect BSON types;
fields that should be grouped inside an embedded object;
missing or unnecessary relationships;
inconsistent field names between collections.

After completing the design, save the schema and bind it to the MongoDB connection where you want to create the collections. The diagram remains a virtual model until you materialize it.

Keep the schema virtual or materialize it

The diagram can remain virtual if you only need it for documentation, planning, or discussing changes with your team.

Nothing is created in MongoDB until you choose to materialize it.

When the design is ready, save it and bind it to the MongoDB connection and target database. You can then click *Materialize* to review the collections and generated validators before applying the schema.

This allows both workflows:

Existing MongoDB database → Visual Schema

and:

Visual Schema → MongoDB database

You can therefore reverse engineer an existing database such as TravelPlannerDemo, modify its virtual schema, and materialize the result into a separate test database.

You can also begin with an empty diagram, as I did with TourBookingSchema, and create a new database from that design.

Choose whether to attach validators

Materializing a schema does not require you to enforce every field and BSON type.

The materialization screen lets you review the JSON Schema generated for each collection. You can then decide whether MongoDB should use it as a $jsonSchema validator.

If you want to create the collections without enforcing the schema, leave *Attach validator* disabled.

These are separate decisions:

The visual schema describes the intended structure.
Materialization creates the collections in MongoDB.
The generated JSON Schema describes the field and type rules.
The attached validator makes MongoDB enforce those rules during writes.

A field is mandatory only if it is included in the schema’s required array. Otherwise, its BSON type is checked only when the field is present.

This distinction matters when your application still writes inconsistent data.

Suppose the generated schema expects:

{
  createdAt: {
    bsonType: "date"
  }
}

If the application sends this instead:

{
  createdAt: "2026-08-03"
}

MongoDB will reject the write when the validator is attached. A document validation failure commonly returns MongoDB error code 121.

The solution is not necessarily to remove validation. First check what your application actually sends. You may need to fix the value before inserting it or adjust the schema if both types are intentionally supported.

Review the materialization plan

Before clicking *Apply to Database*, check:

the selected connection and database;
which collections will be created;
which collections already exist;
collection and field names;
BSON types;
embedded objects and arrays;
relationships in the visual diagram;
generated JSON Schemas;
which collections have the *Attach validator* enabled.

For the first test, use a new database instead of applying the model directly to an existing one.

For example:

TourBookingDemo

This makes the result easier to inspect and avoids mixing the materialized collections with the original TravelPlannerDemo data.

If you materialize changes against a database that already contains records, changing reservations.departureId from String to ObjectId in the diagram will not convert the stored values. Data migration remains a separate operation.

It also does not create enforced foreign keys. The relationship between reservations.departureId and departures._id remains part of the model, but your application must maintain valid references.

Verify the result

After applying the materialization plan, open the target database and confirm that the departures and reservations collections were created.

If you enabled *Attach validator*, inspect the validation settings and test them with:

one valid document that should be accepted;
one invalid document that should be rejected.

If you left the option disabled, the collections should still exist, but MongoDB will continue accepting documents with different structures.

Also remember that a validator does not replace indexes. Fields used for lookups and filtering may still need indexes, such as:

db.reservations.createIndex({
  departureId: 1,
  createdAt: 1
})

db.departures.createIndex({
  startDate: 1,
  status: 1
})

Validators control document structure. Indexes support query performance and can enforce uniqueness when created with the unique option.

Relationships explain how collections connect, but MongoDB does not enforce them as foreign keys.

One schema, two directions

Visual Schema is useful when you inherit an existing MongoDB database and need to understand its structure. It is also useful before you create the first collection.

In my travel-planning example, I could generate a diagram containing travelers, places, flights, accommodations, activities, vacationPlans, and the other related collections. I could inspect nested structures such as budget and itinerary, review the references, and correct the model where necessary.

The same workspace also supports the opposite workflow. You can start with an empty diagram, design the collections visually, and then decide whether to keep the model virtual or materialize it into MongoDB.

When you materialize it, attaching the generated JSON Schema validators remains optional.

*Want to turn your MongoDB database into a diagram—or your diagram into a database?*

Download VisuaLeaf and generate a schema from your existing MongoDB database, or design a new one from scratch.

Which MongoDB Client Handles Large Collections Best: VisuaLeaf vs Compass vs Studio 3T

VisuaLeaf — Tue, 04 Aug 2026 07:56:19 +0000

A MongoDB client can feel fast with a few hundred documents and become frustrating as soon as the result grows.

The database is not always the problem. MongoDB may finish the query while the desktop client is still fetching batches, converting BSON values, and building thousands of rows or JSON blocks.

I tested VisuaLeaf, MongoDB Compass, and Studio 3T with the same collection of 50,844 documents. Then I tested three related workflows: comparing collections, automating repeated work, and investigating an unindexed query.

Test setup

I ran all three applications on the same HP laptop with 16 GB of RAM and Windows 11 Pro. Each application was updated to the latest version available when I ran the test. All three connected to the same MongoDB database through the same internet connection and opened the same largeCollection. The collection contained nested objects and arrays, not only flat fields.

For the first test, I opened the collection without a filter, projection, or custom limit:

db.largeCollection.find({})

Here is what happened:

Test 1: What the large-result test actually shows

The three clients made different choices.

VisuaLeaf allowed one continuous result. That is useful when you need to scroll through a large set, select many documents, inspect distant rows, or export the current result without moving through pages.

VisuaLeaf loaded 50,000 documents in one result in 13.481 seconds.

Compass limited the amount of data visible at once. This protects the interface from an unexpectedly large query and works well when you only need to inspect a sample, edit one document, or confirm a filter. The tradeoff is that browsing the whole collection requires hundreds of pages.

MongoDB Compass displayed the collection in pages of up to 100 documents.

Studio 3T did not finish this particular operation before I stopped it. That does not prove that every version, display mode, or computer will behave the same way. It does mean that an unrestricted result was not practical in this setup.

Studio 3T became unresponsive while attempting to load 50,000 documents.

If a client struggles, reduce both the number of documents and the number of fields:

db.largeCollection.find(
  {},
  {
    _id: 1,
    company: 1,
    registered: 1
  }
).limit(1000)

This is usually the better daily workflow. A large result may be useful for inspection or export, but it still consumes database resources, network bandwidth, memory, and rendering time.

Test 2: Comparing two MongoDB collections

For this test, I used two controlled collections in the QA_Edit database: orders_compare_source and orders_compare_target.

Both collections started with 1,000 identical documents. I then modified 100 documents, removed 50, and added 50 in the target collection. I matched the documents by _id.

VisuaLeaf and Studio 3T both found 850 identical documents, 100 modified documents, 50 missing from the source, and 50 missing from the target.

A useful comparison must answer three questions:

Which documents exist on only one side?
Which fields changed inside matching documents?
What will be inserted, updated, or deleted during synchronization?

VisuaLeaf

VisuaLeaf has a dedicated Collection Compare workflow for schema and data differences. It keeps the comparison next to the document, query, and data-operation tools.

The important setup choice is the matching field. _id works only if both collections preserve the same values. If an import regenerated them, use a stable key such as customerId, orderId, or externalId.

VisuaLeaf found 850 identical, 100 modified, and 50 documents missing from each collection.

Studio 3T

Studio 3T provides the most detailed comparison controls of the three. Its Data Compare & Sync supports collections on different databases or servers, document- and field-level differences, result export, and synchronization in either direction.

Bi-directional synchronization is useful, but it increases the cost of a wrong choice. Decide which collection is the source of truth before applying changes.

Studio 3T returned the same differences using _id as the matching field.

MongoDB Compass

Compass does not provide the same dedicated collection-diff workflow. You can still build part of the comparison with an aggregation.

For example, this pipeline finds source documents without a matching _id in the target:

db.orders_compare_source.aggregate([
  {
    $lookup: {
      from: "orders_compare_target",
      localField: "_id",
      foreignField: "_id",
      as: "target"
    }
  },
  {
    $match: {
      target: {
        $eq: []
      }
    }
  },
  {
  $count: "missingInTarget"
  }
  }
])

This finds missing matches, not every field-level change. It also assumes both collections are in the same database. Comparing data on different servers requires a script, a temporary copy, or another tool.

Compass used an aggregation pipeline to find 50 source documents missing from the target.

Test 3: Automating Daily Orders

Large collections make small mistakes more expensive.

For this test, I used a daily orders JSON file.

In Studio 3T, I imported the file into a daily_orders collection. Studio 3T can also save and schedule tasks, so it works well when you want to repeat imports, exports, or other database jobs.

JSON import task: import a file into a collection

In VisuaLeaf, I used Task Manager to connect more than one step:

Import Daily Orders JSON → Add Orders to Main Collection → Export Sales Report

VisuaLeaf lets you connect tasks into a workflow, not just run one import.

The useful part is that tasks can have parent tasks. So the next task runs after the previous one is completed.

This is helpful when the work is not just “import this file.” In a real workflow, you may need to import data, map fields, move it into the main collection, mask sensitive data, and export a report after that.

For example, field mapping matters because orderedAt should be mapped to createdAt as a MongoDB Date, and values like email or phone numbers may need data masking before export.

So for me, Studio 3T is strong for saving and scheduling database tasks. VisuaLeaf is easier when I want to see a connected workflow in one place and control the order of the steps.

Compass is different. It is great for interactive work, but recurring workflows usually need something outside the desktop app, like a script, cron, Windows Task Scheduler, CI, or an Atlas service.

Test 4: Checking the Query Before Blaming the Client

The first test measured how each tool handled a large result on screen.

This test is different. Here, I wanted to check the work MongoDB was doing before the data even reached the client.

I started with a query that had no supporting index:

db.largeCollection.find({
  company: "ZENSOR"
})

The important part was the explain plan.

I checked:

scan stage in the winning plan: COLLSCAN or IXSCAN
totalDocsExamined
totalKeysExamined
nReturned
execution time

When the query uses COLLSCAN, MongoDB has to scan the collection to find matching documents. That means the slow part is not always the GUI. Sometimes the database is simply doing too much work.

A COLLSCAN is not automatically a problem. But in this case, scanning 50,844 documents to return only 51 showed that the query could benefit from an index.

VisuaLeaf detected a COLLSCAN, examining 50,844 documents to return 51.

Studio 3T reported a collection scan across 50,844 documents for 51 results.

Compass used a COLLSCAN, examining all 50,844 documents to find 51 matches.

After that, I created an index:

db.largeCollection.createIndex({
  company: 1
})

Then I ran the same explain operation again.

A lower execution time is useful, but the stronger evidence is that the winning plan now contains an IXSCAN. In this test, totalDocsExamined dropped from 50,844 to 51, matching the 51 returned documents.

VisuaLeaf’s Query Profiler is useful here because it brings slow queries, execution plans, index usage, scanned documents, returned documents, and optimization hints into one place.

After adding the company_1 index, VisuaLeaf examined 51 documents and 51 index keys.

Studio 3T has the deepest performance tools in this comparison, with Query Profiler, Visual Explain, and Index Manager.

With the company_1 index, Studio 3T used an index scan and examined 51 documents.

Compass also has Explain Plan, which works well when you already know which query you want to inspect.

After indexing company, Compass changed to IXSCAN and examined only 51 documents.

For this test, the main point was simple: before blaming the client, check if MongoDB is scanning too much data.

Which client fits which workflow?

If you mainly need to…	Best fit	Why
Open and work with a large continuous result	VisuaLeaf	It loaded 50,000 documents in 13.481 seconds and remained usable
Compare two collections visually	VisuaLeaf	It clearly separated identical, modified, and missing documents
Automate multi-step data workflows	VisuaLeaf	Import, copy, export, and scheduling can be managed in one workflow
Find inefficient queries in the same workspace	VisuaLeaf	Query Profiler combines plans, index usage, scanned documents, and optimization hints
Browse documents in small pages with a free official client	MongoDB Compass	Pagination keeps browsing controlled and predictable
Access advanced synchronization and administration controls	Studio 3T	It provides more granular diff, sync, and performance options

There is no single client for every MongoDB job. Compass is a good option for controlled, paginated browsing, while Studio 3T offers advanced administration and synchronization controls. But for everyday work with large results, collection comparisons, automated tasks, and query analysis, VisuaLeaf provides the most complete workflow in one place.

Choose the client around the operation that costs you time, not the longest feature list.

How to Copy and Sync a MongoDB Collection to PostgreSQL

VisuaLeaf — Tue, 28 Jul 2026 07:46:26 +0000

I tested a MongoDB-to-PostgreSQL sync with a visits collection.

At first, I thought the hard part would be the sync itself. It was not. The harder part was making PostgreSQL understand the MongoDB document shape.

MongoDB lets one document contain strings, dates, nested objects, arrays, and an _id. PostgreSQL wants fixed columns, clear data types, and a primary key.

So before running the sync, I had to decide what the PostgreSQL table should look like.

For this test, I used VisuaLeaf Mongo Sync.

I used it because I wanted to set up the workflow visually: source collection, target PostgreSQL table, field mapping, and sync status. I still had to create the PostgreSQL table and check the mapping carefully, but I did not have to write a custom sync script.

Source Collection

The source was:

database_compare_demo.visits

Each MongoDB document had simple fields like:

_id
visitId
status
visitDate
visitReason

It also had nested fields:

patient
doctor
symptoms
prescriptions
invoice
labResults
visitDetails
vitals
clinic

MongoDB visits collection with nested patient, doctor, lab results, and vitals data.

This is where the mapping matters. If you try to force every nested MongoDB field into separate SQL columns too early, the setup gets messy fast.

For this test, I used a PostgreSQL landing table.

PostgreSQL Table

I created one table:

CREATE TABLE public.mongo_visits_sync (
    mongo_id TEXT PRIMARY KEY,
    "visit_id" TEXT,
    status TEXT,
    "visit_date" TIMESTAMPTZ,
    "visit_reason" TEXT,

    patient JSONB,
    doctor JSONB,
    symptoms JSONB,
    prescriptions JSONB,
    invoice JSONB,
    "lab_results" JSONB,
    "visit_details" JSONB,
    vitals JSONB,
    clinic JSONB
);

I kept the simple fields as normal columns.

I stored the nested MongoDB objects and arrays as JSONB.

This was easier to test, and it kept the original document structure instead of flattening everything too early.

Why `mongo_id` Is Important

The PostgreSQL table needs a primary key.

In this setup, MongoDB _id maps to PostgreSQL mongo_id.

_id -> mongo_id

Without this, the sync cannot safely update existing rows.

One error I hit was:

SQL target has no key columns — cannot upsert idempotently

That means PostgreSQL did not have a usable key for the sync job.

The fix was to create mongo_id as the primary key and map MongoDB _id to it.

Field Mapping and Data Types

In VisuaLeaf, the mapping shows the MongoDB fields with simple source types like String, Object, and Array.

That matters because not every MongoDB field should become a normal text column in PostgreSQL.

Creating a new transformation mapping before generating the MongoDB to PostgreSQL fields.

For this test, I used this logic:

Field mapping from MongoDB fields to PostgreSQL columns, including objects and arrays.

The simple string fields went into normal PostgreSQL text columns.

The objects and arrays went into JSONB columns.

This was the important part. If I mapped an object or array into a normal text column, the sync would either fail or store the data in a way that is harder to query later.

For example:

patient is an object, so I mapped it to a JSONB column.

symptoms is an array, so I also mapped it to JSONB.

The main key was:

_id -> mongo_id

That gave PostgreSQL a stable primary key for updates and deletes during sync.

The Error I Had With Column Names

At first, my PostgreSQL table used names like:

lab_results
visit_details
visit_reason

But the sync tried to insert into:

labResults
visitDetails
visitReason

So PostgreSQL returned this error:

ERROR: column "labResults" of relation "mongo_visits_sync" does not exist

The sync failed because the MongoDB field labResults did not match the PostgreSQL column lab_results.

The problem was not PostgreSQL. The problem was the mismatch between the mapping and the real column names.

You can fix this in two ways:

Keep snake_case in PostgreSQL and map each field manually.
Use quoted camelCase column names in PostgreSQL.

Sync Setup

The source MongoDB database was a replica set.

That matters because continuous sync uses MongoDB change streams. Change streams work with replica sets and sharded clusters, not standalone MongoDB.

The setup was:

Mapping the MongoDB visits collection to the PostgreSQL target table.

I used Full sync because I wanted the first copy and the later changes.

Final review before saving the MongoDB to PostgreSQL sync job.

Checking the Initial Copy

After running the sync, I checked the row count:

SELECT COUNT(*) AS synced_rows
FROM public.mongo_visits_sync;

Then I checked a few fields:

SELECT
    "visit_id",
    status,
    "visit_date",
    patient ->> 'fullName' AS patient_name,
    doctor ->> 'fullName' AS doctor_name
FROM public.mongo_visits_sync;

Synced MongoDB visit documents shown in the PostgreSQL target table.

This confirmed that normal fields were copied into columns, and nested values were still queryable from JSONB.

Testing Insert, Update, and Delete

The first copy is not enough to prove the sync works.

So I tested changes from MongoDB too.

Live sync monitor showing inserts, updates, deletes, and connection status.

For the update test, I used:

db.visits.updateOne(
  { visitId: "VIS-SYNC-TEST" },
  {
    $set: {
      status: "completed",
      "visitDetails.notes": "Updated after initial sync"
    }
  }
);

Then I checked PostgreSQL:

SELECT
    "visit_id",
    status,
    "visit_details" ->> 'notes' AS notes
FROM public.mongo_visits_sync
WHERE "visit_id" = 'VIS-SYNC-TEST';

The updated status and note appeared in PostgreSQL.

I also tested insert and delete. The new document appeared in PostgreSQL, and the deleted document was removed from the table.

What I Would Watch For

The sync works, but the setup is not automatic magic.

You still need to be careful with:

primary keys
field mapping
camelCase vs snake_case column names
nested objects
arrays
JSONB fields
unmapped MongoDB fields

For a first version, one PostgreSQL landing table is usually easier than trying to normalize everything.

After the data is synced, you can decide if some fields should move into separate SQL tables later.

Conclusion

This kind of sync is useful when MongoDB is where the app data lives, but PostgreSQL is better for reporting, SQL queries, dashboards, or sharing data with teams that work mostly in relational databases.

The goal is not only to copy the collection once. The useful part is keeping PostgreSQL updated when documents are inserted, updated, or deleted in MongoDB.

For this test, the cleanest setup was to store simple fields as normal PostgreSQL columns and keep nested objects and arrays as JSONB.

Once the primary key, column names, data types, and field mapping were correct, VisuaLeaf Mongo Sync could handle the copy and the later changes without writing a custom sync script.

Want to Sync MongoDB to Atlas Instead?

If you want to copy a local MongoDB collection to Atlas and keep it in sync, I covered the full process in this detailed guide: How to Copy a Local MongoDB Collection to Atlas—and Keep It in Sync.

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.

DEV Community: VisuaLeaf

What changed in MongoDB 9.0, and how can it help in everyday database work? Practical examples in VisuaLeaf show the new behavior and compare results with MongoDB 8.2.5.

What's New in MongoDB 9.0: Query Settings, Validation, and Resource Limits

How to Open a SQLite Database: Query and Explore Your Data

First, understand what is inside the file

Open your SQLite database in VisuaLeaf

Read a few inspections with SQL

What do the column types mean?

Understand foreign keys and join related tables

Is SQLite checking the relationships?

Query JSON data in SQLite

Export SQLite query results to Excel

Count and chart failed checks by category

Conclusion

[Boost]

MongoDB Sharding: Manage a Sharded Cluster Visually

Learn how to use DuckDB for local analysis: open a database, query CSV and Parquet files, inspect relationships, edit data, and create charts.

How to Use DuckDB for Local Data Analysis

mongodump Tasks Automate and Schedule MongoDB Backups

Save the Same mongodump as a VisuaLeaf Task

Back Up a Database or One Collection

Choose the Output Folder and Enable Gzip

Schedule and Monitor the MongoDB Backup

What Files Does the Backup Create?

Can You Run mongodump in MongoDB Compass?

Restore the BSON Backup in VisuaLeaf

If mongodump Does Not Run on Windows

MongoDB Backup Limitations to Plan For

Conclusion

PostgreSQL JSONB: Query, Update, and Index JSON Data

PostgreSQL JSONB operations used in this guide

Create the support tickets table

Query nested JSONB values

Match part of a document with @>

Update a nested value with jsonb_set

When the parent object is missing

Add a GIN index for containment searches

When to use JSONB

References

MongoDB Schema Design: Build or Reverse Engineer Visually

Reverse engineer an existing MongoDB database

Review the detected structure

Review and add relationships

Modify the generated schema

Design a new MongoDB schema from scratch

Keep the schema virtual or materialize it

Choose whether to attach validators

Review the materialization plan

Verify the result

One schema, two directions

Which MongoDB Client Handles Large Collections Best: VisuaLeaf vs Compass vs Studio 3T

Test setup

Test 1: What the large-result test actually shows

Test 2: Comparing two MongoDB collections

VisuaLeaf

Studio 3T

MongoDB Compass

Test 3: Automating Daily Orders

Test 4: Checking the Query Before Blaming the Client

Which client fits which workflow?

How to Copy and Sync a MongoDB Collection to PostgreSQL

Source Collection

PostgreSQL Table

Why mongo_id Is Important

Field Mapping and Data Types

The Error I Had With Column Names

Sync Setup

Checking the Initial Copy

Testing Insert, Update, and Delete

What I Would Watch For

Conclusion

Want to Sync MongoDB to Atlas Instead?

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

Match part of a document with `@>`

Update a nested value with `jsonb_set`

Why `mongo_id` Is Important

2. Treating `$or` Like a Regular Object

7. Reading `$or` Logic Backwards