Browse documentation
MongoG GuideVerified with mongodb 7.5.0

Use MongoG Administration Tools

Inspect indexes and explain plans, run bounded global searches, observe change streams, and manage GridFS files from MongoG’s administration workspace.

Open Administration with context

MongoG’s Administration workspace groups operational tools around a selected connection, database, and optional collection. Open it from the Explorer context menu so the namespace is explicit before any operation runs.

The workspace contains dedicated views for Indexes, Explain, Global Search, Change Streams, and GridFS. These views use typed requests to the connection runtime; they do not assemble and evaluate hidden query-editor scripts.

Use a read-only profile for investigation whenever possible. Index and GridFS mutations are disabled and rejected for read-only profiles, while MongoDB server roles remain the final authorization boundary.

Inspect and manage indexes

The Indexes view shows key patterns and relevant options including unique, sparse, hidden, TTL, and partial-filter configuration. Review existing coverage before adding another index; overlapping indexes increase storage and make every write maintain more structures.

When creating an index, start from a specific query shape:

db.collection("orders").find({
  customerId: "customer-42",
  status: "paid",
}).sort({ placedAt: -1 });

A candidate compound index is { customerId: 1, status: 1, placedAt: -1 }. Give important indexes stable names so migrations and operational discussions do not depend on generated names.

Dropping an index is a write operation. Confirm the application no longer needs its query coverage or uniqueness rule. MongoG does not offer deletion of the mandatory _id_ index.

Explain a query without writing a script

The Explain view accepts a filter, sort, projection, and driver explain verbosity. Use:

  • queryPlanner to inspect the selected and rejected plans without execution statistics.
  • executionStats to run the winning plan and compare returned documents, examined documents, and examined keys.
  • allPlansExecution for additional candidate-plan execution detail when deeper diagnosis is necessary.

Look beyond the presence of IXSCAN. A plan that examines hundreds of thousands of keys to return a handful of documents may still need a better index or filter. A blocking sort can indicate that the index order does not satisfy the requested sort.

Explain can execute real work. Use a representative but safe filter and avoid assuming that a diagnostic request is free on a busy production deployment.

Global Search looks for text across a bounded sample of collections and documents by examining Canonical Extended JSON. It reports how many collections and documents were scanned, caps returned matches, and marks truncated results.

This is an investigation tool, not a claim of exhaustive database search. A missing result can mean the configured scan bounds were reached. Use it to discover likely namespaces or field shapes, then switch to a precise indexed query.

Do not use Global Search as an application search engine. For product search, design explicit fields and indexes, or use the search capabilities appropriate to the deployment.

Observe change streams

Change Streams can watch a collection or database and filter events with an Extended JSON aggregation pipeline. They require a replica set or sharded cluster; a standalone mongod cannot provide change streams.

Useful filters include:

[
  {
    "$match": {
      "operationType": { "$in": ["insert", "update", "replace"] }
    }
  }
]

Choose a full-document mode deliberately. updateLookup asks MongoDB to fetch the current full document for eligible update events, which adds work and may reflect a state newer than the exact update moment.

MongoG keeps the stream in the connection runtime behind an opaque handle and polls bounded event batches. Stop the stream when finished. It is also closed during tab cleanup, disconnect, idle expiry, or runtime shutdown. After a hard query cancellation restarts a connection runtime, create a new stream rather than assuming an old handle survived.

Manage GridFS files

GridFS stores files across files and chunks collections through a GridFSBucket. Use it when files exceed the normal BSON document limit or when streaming database-backed files matches the system design.

MongoG can list file metadata, upload with a native file picker, download to a native save location, and delete files. File bytes stream between the local file and the driver runtime; they are not copied through renderer messages as one large value.

Before deleting a GridFS file, confirm the bucket, filename, identifier, and application references. GridFS deletion is permanent from the database’s perspective and is not a desktop trash operation.

GridFS is not automatically the best home for every asset. Object storage can be a better fit for public delivery, CDN integration, lifecycle policies, or very large media workloads. Choose based on application architecture rather than convenience in the admin interface.

Use the query editor for reproducibility

The Administration views are effective for focused inspection. Use the query editor when a diagnostic or migration must be code-reviewed, repeated across environments, or stored with a deployment change.

For example, keep an index migration as explicit driver code:

await db.collection("orders").createIndex(
  { customerId: 1, status: 1, placedAt: -1 },
  { name: "customer_status_recent" },
);

The best workflow often begins visually, confirms the exact operation, and ends with a reviewed script in the application’s migration process.

Operational checklist

Before an administration action:

  1. Confirm the connection, database, and collection displayed by MongoG.
  2. Verify whether the profile and server user are read-only or writable.
  3. Estimate the amount of data the operation may examine or change.
  4. Prefer a representative staging run for index and migration work.
  5. Capture the before state and define the verification query.
  6. Use application backups and change procedures for production mutations.

After the action, refresh the relevant view and verify the server state rather than relying only on a success notification.

Common mistakes

  • Treating sampled Global Search as exhaustive.
  • Creating an index because its fields look useful without testing a real query shape.
  • Looking only for IXSCAN while ignoring examined-to-returned ratios.
  • Starting a change stream on a standalone server or leaving it open indefinitely.
  • Assuming updateLookup is the exact document snapshot at the original event time.
  • Deleting a GridFS file without confirming its bucket and application references.
  • Using a writable administrator profile for routine browsing.

Continue learning

Deepen the database concepts with indexes and explain plans, aggregation pipelines, and cursor lifecycle. Official references cover change streams and GridFS.