Introduction
A step-by-step guide to help you open, run, and read the Sizing Advisor — the read-only capacity & sizing assessment built into NoSqlStudio. Follow from Step 1 to the end, in order. Each step tells you what to do and what you will see.
How to read this manual
Each step has:
- Do — the exact action (open a menu, click a button, read a panel).
- See — what should happen on screen. This is your “pass / fail”.
- Why — extra context, only when it helps (skip it if you're in a hurry).
Before you start
Concept
What the Sizing Advisor is
The Sizing Advisor is a read-only capacity & sizing assessment. A single sweep reads admin commands (like serverStatus, dbStats, $collStats and replSetGetStatus) to build a Snapshot, then turns it into a Health Score, prioritized findings, a per-database breakdown, and a cloud sizing recommendation with a cost forecast. It never writes anything to your database.
Heads-up
Safe to run in production
Because it only reads, the assessment is safe to run against a live production cluster. It reads from a secondary when it can, so it won't even warm the primary's cache. It does need an active connection.
You will need:
- 1An active connection to a database — MongoDB, Atlas, Cosmos DB for MongoDB (vCore or RU), or Amazon DocumentDB.
- 2Ideally a user with the clusterMonitor role, so admin commands like
serverStatus/replSetGetStatussucceed; with a narrower user the assessment still runs and just marks itself partial. - 3Nothing to set up in the database — the Sizing Advisor creates no collections and runs no test data.
Estimated time for the full walkthrough: ~15 minutes.
Open and run an assessment
Open the Sizing Advisor, run a single read-only sweep, and land on the result.
Connect to a deployment
Connect NoSqlStudio to the deployment you want to assess — a MongoDB server or replica set, an Atlas cluster, a Cosmos DB for MongoDB instance, or an Amazon DocumentDB cluster.
The connection opens and appears in the sidebar. The Sizing Advisor needs this active connection to read from.
Open the Sizing Advisor
Open it from the menu AI & Advisors → Sizing Advisor, or use the keyboard shortcut Ctrl+Alt+Shift+I. You can also open it from the Home screen card.
A new tab opens with the Sizing Advisor screen: a left rail (with Alvo / Target, Coleta / Collection, Sections and a Health Score card) and an empty content area waiting for a scan.
The Advisor is an advisor, so it lives under AI & Advisors, next to the Performance Advisor — not in the live monitoring tools.
Check the target and collection options
In the left rail, confirm the Connection picker shows the right deployment and look at the engine chip below it (for example ◆ MongoDB 8.0 · 3-node RS). Under Collection, leave the three checkboxes on: All databases, Per-collection stats, and Workload (opcounters).
The engine chip reflects the engine and topology the Advisor detected. The three collection options are checked by default.
Concept
Turning Per-collection stats off makes the sweep faster on huge deployments — it then relies on database-level totals only and skips the per-collection $collStats loop.
Run the assessment
Click the ▶ Run assessment button at the top of the rail.
A progress bar advances as the single read-only sweep collects a Snapshot — the admin/server block, replication, then a loop over your databases and collections. When it finishes, the result renders: gauges, recommendation cards, the per-database table, and the cloud card.
This is the core of the tool — one deliberate, read-only sweep produces an immutable, fingerprinted Snapshot that everything else is derived from. ✅
Read the Health Score
The Health Score is the one-glance verdict; understand its number and its band.
Find the Health Score
Look at the Health Score card at the bottom of the left rail.
A big number from 0 to 100 with a subtitle like 2 criticals · 3 warnings. The number is colored: green when healthy, amber when fair, red when at-risk or critical.
Read the band
Map the score to its band.
- 85–100 — healthy: no urgent action.
- 70–84 — fair: some warnings worth scheduling.
- 50–69 — at-risk: criticals are accumulating.
- below 50 — critical: act now.
Concept
The score is explainable
The score is deterministic — it starts at 100 and every point lost maps to a named finding. The same deployment state always produces the same score, so you can compare runs over time. The criticals and warnings counts in the subtitle come straight from those findings.
Walk the findings
The recommendation cards are the heart of the report — ordered by impact, each with a severity, the evidence, and a fix.
Read the header gauges
Above the recommendations, scan the gauge strip.
A row of gauges with big mono numbers: Data (logical), On disk (with the compression ratio), Indexes, RAM, vCPU, WT cache (used / configured), Oplog window, and Connections. Each gauge's subtitle is colored — green for ok, amber for a warning, red for a critical signal (for example data ≫ RAM).
The gauges are the raw facts the findings are built from — logical vs on-disk size, how much of the working set fits in cache, the oplog history, connection churn.
Read a recommendation card
Look at the Recommendations section. Read the first card, top to bottom.
Each card has a colored left bar and a severity chip (critical / warning / ok), an icon, a title, a sentence of evidence with the real numbers, and a → fix line with the concrete remediation. Cards are sorted by impact, so the most important one is first.
Storage & disk-fill
Find any storage findings — for example a low compression ratio, or a disk-fill forecast warning.
Storage findings compare logical data to on-disk size and, when there is enough history, project when the disk fills. A healthy compression ratio (around 2.3×) reads as ok.
Working-set vs RAM
Find the working set finding — it compares your hot data against RAM and the WiredTiger cache.
When the data dwarfs RAM (for example 881 GB of data against 31 GB of RAM), it fires critical: queries outside the hot set go to disk. The fix suggests adding RAM so the working set fits, archiving cold collections, or sharding.
Concept
What “working set” means
The working set is the slice of your data that is actively read and written — the hot part. For good performance it should fit in RAM (specifically in the WiredTiger cache, which is about half of RAM). You don't need RAM equal to all your data, just to the hot set.
Index health
Find the indexing findings — index bloat, over-indexed collections, unused or duplicate indexes.
Index findings flag a database whose index size is large relative to its data (for example 41.5 GB of index for 87.9 GB of data), or a collection carrying too many indexes. The fix points you to the Performance Advisor to drop the unused ones.
Security posture & oplog window
Find the security finding (TLS / auth posture) and the oplog window finding.
The security finding flags weak TLS, key-file cluster auth, or disabled authorization. The oplog finding reports the replication window in hours/days — a comfortable window (for example 7.8 days) reads as ok; a shrinking window approaching a day fires a warning.
Heads-up
Some metrics degrade on managed engines
On Cosmos DB for MongoDB or DocumentDB, commands like replSetGetStatus, hostInfo, or the WiredTiger cache stats may be unavailable. Those gauges show — instead of a fake 0, and the rules that need them skip with an info note rather than firing a false critical.
Per-database and cloud sizing
Two panels sit below the cards: where your space goes, and what to provision in the cloud.
Read the per-database table
Look at the Data per database panel.
One row per database, sorted by size: Data, Disk, a data · idx sizebar (cyan = data, amber = index), Coll and Idx counts, and a Flag (for example large, few collections, archivable, idx NN GB, empty, or ok). The sizebar makes index-heavy databases jump out at a glance.
Read the Cloud sizing card
Look at the Cloud sizing card next to the table.
A recommended tier (for example M60), its spec (RAM · vCPU · disk), an estimated monthly cost, and a breakdown: data on disk, + headroom, RAM (working set), growth, and reaches 80% of disk in ~N months. Below it, alternatives (a cheaper tier or a sharded option) with their trade-offs.
The Advisor maps your requirements to Atlas, Cosmos vCore, and generic VM tiers, picking the cheapest that fits your RAM, vCPU, disk, and IOPS — so you neither under- nor over-provision.
About the prices
Heads-up
Reference prices, not a quote
The cost figures come from a dated, versioned reference price book (on-demand, list, single-region). They are for right-sizing guidance — always confirm with the provider's own calculator before committing, since prices vary by region and contract.
Export and audit
Turn the assessment into a shareable artifact and anchor it to your audit trail.
Export the report
At the bottom, use the export bar. Click PDF report, Printable HTML, or JSON (raw snapshot).
PDF and HTML produce the full blueprint report — cover stats, findings, host & memory, per-database, workload & replication, config & security, and cloud sizing. JSON saves the raw, deterministic snapshot, which you can re-import later to compare over time.
Attach to the audit log
Click Attach to audit.
The report's sha256 hash is recorded in the local audit timeline (and, when licensed, anchored to the immutable backend chain). A toast confirms it with the short hash.
Concept
The snapshot's stable sha256 fingerprint is the anchor key, so re-attaching the same snapshot is idempotent and audit entries for the same deployment line up across time.
Snapshots and growth over time
Every run is saved; re-scan later to see how the deployment grew.
Find your saved snapshots
Open the Saved snapshots list (each assessment you run is kept here, encrypted at rest with its sha256 fingerprint).
A list of past snapshots, each with its timestamp, label, and Health Score. You can open any past one to review it exactly as it was captured.
Re-scan and compare over time
Run the assessment again later (a day or more after the first), then compare the new snapshot against an earlier one.
A temporal diff shows per-database and per-metric deltas — for example grew X% in 30 days — and the cloud card now projects a dated disk-fill ETA from the trend.
Heads-up
Growth needs at least 2 snapshots
With a single snapshot there is no trend to plot, so the cloud card shows “collect ≥ 2 snapshots for a growth projection.” The forecast gets a dated ETA once you have two snapshots at least a day apart, and gets more confident with four or more.
Cleanup (when you're done)
Concept
There is nothing to undo in the database
The Sizing Advisor is read-only — it wrote nothing to your database, so there is nothing to drop or revert. The only thing to manage is the locally saved snapshots.
If you want, open the Saved snapshots list and delete any old snapshots you no longer need.
The selected snapshots are removed from local storage. The deployment itself is untouched.
Summary of what you validated
| Stage | Feature |
|---|---|
| 1 | Open the Sizing Advisor and run a read-only assessment |
| 2 | Read the Health Score (0–100) and its band |
| 3 | Walk the findings: storage, working-set vs RAM, indexes, security, oplog |
| 4 | Read the per-database table and the cloud sizing recommendation |
| 5 | Export the report (PDF / HTML / JSON) and attach it to the audit log |
| 6 | Save snapshots and compare growth over time |