Skip to content

NoSQL Studio

A practical guide to Data Explorer’s NoSQL workspace: selecting collections, writing MQL, reading results, using AI, and keeping mutating operations under control.

Collection-first

Before you pick a collection, the workspace stays in dashboard mode. Once a collection is selected, the toolbar, editor, schema tools, and result panel all pivot around that collection.

Visible guardrails

The NoSQL workspace surfaces connection safety rules such as read-only mode, execution-disabled connections, result limits, and `truncated` state when aggregate or find results are capped.

AI understands the active collection

The NoSQL AI box is more than chat. It uses the active collection, current database, and recent prompt context to generate MQL you can apply directly in the editor.

How the workspace is organized

NoSQL Studio is split into three clear layers: collection navigation on the left, the main working surface in the center, and AI assistance on the right. Once you pick a collection, the center surface lets you move between JSON tree, auto-flatten grid, schema analysis, and the aggregation builder.

Indexed collection search

The sidebar has a search box backed by the synced search index, letting you jump straight to the right database/collection even on clusters with hundreds of collections.

Before a collection is selected

The workspace stays on the NoSQL dashboard so you can confirm the connection, health state, and starting point before drilling into real data.

After a collection is selected

The center header switches to `db.<collection>`, view-mode buttons appear, the editor is targeted at that collection, and the result panel reflects the latest execution.

Editor and results are decoupled

You can edit MQL without immediately losing the previous result. The result panel can be shown or hidden independently when you want more room to write.

AI sits in-context

The AI panel runs alongside the NoSQL editor, so the common workflow is: describe your intent in natural language, receive MQL, apply it to the editor, and then run or refine it.

What MQL looks like in this app

Data Explorer does not force you into long shell scripts. For MongoDB and the current NoSQL lanes, the editor prefers a JSON payload with an `action`, a `collection`, and the relevant operation body. That lets the UI distinguish read operations from mutations and decide when stronger guardrails are needed.
Read example

# Fetch the 20 most recent documents by createdAt

{

"action": "find",

"collection": "orders",

"filter": { "status": "paid" },

"sort": { "createdAt": -1 },

"limit": 20

}

# Multi-stage aggregation pipeline

{

"action": "aggregate",

"collection": "orders",

"pipeline": [

{ "$match": { "status": "paid" } },

{ "$group": { "_id": "$country", "total": { "$sum": 1 } } },

{ "$sort": { "total": -1 } }

],

"limit": 500

}

Actions such as `insertOne`, `updateOne`, `updateMany`, `deleteOne`, and `deleteMany` are mutations. The app should not treat them like harmless `find` operations. Use them on the right connection, review filters carefully, and prefer a safe environment first.

For `aggregate`, the backend applies the limit on the cursor before calling `toArray()`. Responses include `appliedLimit`, `limitSource`, and `truncated`, so capped results are surfaced clearly instead of looking like the full collection.

Guardrails and execution rules

Execution disabled

If a connection has query execution disabled, the UI still lets you inspect docs, prepare payloads, or use AI, but execution is intentionally blocked.

Read-only mode

In read-only mode, the app prioritizes non-mutating actions such as `find` and `aggregate`. This is ideal for production browsing, auditing, or reviewing a live dataset safely.

The result panel is more than an output box

The result panel also shows summary labels, returned document counts, capped-result badges, suggestions about reading the result in grid/tree mode, and compact feedback for mutations. You do not have to guess whether the last run did what you intended.

Use the right lens for the result

Tree (JSON)

Best when you need the real BSON/JSON shape, especially for nested objects, arrays, or uneven documents. This is the right view for debugging schema shape and raw data.

Auto-Flatten Grid

Best when you want to scan many documents as columns, compare fields side by side, or review patterns quickly. It does not replace the JSON tree, but it is much faster for broad scanning.

Schema Analysis and Aggregation Builder

When the goal shifts from reading documents to understanding fields or building pipelines, move into Schema Analysis or the Aggregation Builder. Those views take you from raw data to structured insight without forcing everything into one editor box.

Practical tip: start with a small `find` or `aggregate` to understand the data shape before writing mutations. On large collections, add `$match`, `$project`, or `limit` early so the pipeline stays narrow before moving into schema analysis or the aggregation builder.

If writing MQL is the bottleneck, use the NoSQL AI box as a smart draft tool: describe your intent in plain language, receive a payload, apply it to the editor, and then manually refine sensitive fields before running it.

Ready to explore data?

Join the community on GitHub to contribute to the smartest local database IDE.

Launch App