MongoDB Cost Optimization
Cut your MongoDB bill from inside the cluster. OhChimp finds unused indexes, fragmented collections, and TTL gaps, and plans a fix with rollback steps.
What OhChimp optimizes for MongoDB
Some of the cost levers OhChimp checks for MongoDB. Each one becomes a reviewable plan you approve before anything changes.
Drop unused indexes
Indexes that never serve a read still cost disk and slow every write. OhChimp runs $indexStats across your collections to find indexes with zero accesses since the last server restart, skips the _id index, and drafts the drop so you stop paying to maintain dead weight.
Compact fragmented collections
When a collection's storage size runs more than double its data size, fragmentation is eating disk you still pay for. OhChimp reads collStats to find collections over 10MB with a storage-to-data ratio above 2x, estimates the reclaimable bytes as storage minus data size, and plans the compaction.
Audit TTL coverage on your collections
Event logs, sessions, and metrics with no expiry grow without bound and quietly inflate storage. OhChimp inspects each collection's indexes for an expireAfterSeconds setting and reports which collections carry a TTL policy and how big they are, so you can see where old documents are never expiring.
Right-size RAM from the cache hit ratio
A low WiredTiger cache hit ratio means the cluster is hitting disk constantly, which usually signals too little RAM for the working set. OhChimp reads the cache stats from serverStatus, computes the hit ratio, and flags it with a recommendation to increase cacheSizeGB when the ratio runs low.
Archive oversized databases and collections
Old databases and giant collections are often candidates for archiving or compression that nobody has revisited. OhChimp ranks your databases and collections by size using listDatabases and collStats so the biggest storage line items become a deliberate decision instead of a default.
Route reads to idle secondaries
If your replica set has healthy secondaries serving no traffic, your primary may be sized larger than it needs to be. OhChimp audits the connection's read preference and counts live secondaries, then flags where shifting read-heavy load to secondaries lets you downsize the primary.
Worked example
For example, say OhChimp probes your cluster and finds several indexes with zero accesses since the last restart, an events collection whose storage size is three times its data size, and a large sessions collection that carries no TTL policy.
It drafts the index drops, a compaction plan for the fragmented collection, and surfaces the missing TTL coverage, each with a confidence score and rollback steps. You press apply. OhChimp cannot yet measure what a single MongoDB plan saves, so it does not mark one VERIFIED. The saving stays an estimate, and when the 30 days of monitoring end the result reads "Inconclusive."
MongoDB cost optimization FAQ
How does OhChimp connect to MongoDB?
With a database user that has the clusterMonitor role plus read access. OhChimp verifies the connection with serverStatus and listDatabases, then runs probe queries against catalog and statistics views (collStats, $indexStats, serverStatus). It uses readPreference secondaryPreferred so those queries land on a secondary where one exists and your primary stays clear.
Does OhChimp need write access or see my data?
No. OhChimp uses a read-only user and reads metadata and storage statistics through probe queries. It samples a small batch of documents per collection to map field names and types for schema waste, and it never stores your application documents, secrets, or workload contents.
What MongoDB costs can OhChimp actually reduce?
The main ones are unused indexes wasting disk and write throughput, fragmented collections that compaction can reclaim, TTL coverage gaps on growing collections, a cache hit ratio that shows the cluster is mis-sized, oversized databases ripe for archiving, and idle secondaries that let you downsize the primary.
Who applies the changes, and can they be rolled back?
You do. Each fix is a reviewable plan with a confidence score, a risk level, and rollback steps. Nothing changes until you click apply, and OhChimp applies the matching code and infrastructure changes together.
How are the savings verified, and how is it priced?
Today MongoDB savings stay estimates. OhChimp cannot yet measure what a single MongoDB plan saves, so it does not mark one VERIFIED, and when the 30 days of monitoring end the result reads "Inconclusive." The only savings OhChimp measures today come from lowering the CPU and memory requests of a Kubernetes Deployment, StatefulSet, or DaemonSet. Pricing is flat monthly, OhChimp never takes a cut of your savings, and paid plans carry a year-one ROI guarantee that lets you request a refund of your first 12 months of subscription fees if the verified savings on your Costs tab fall short of them. Estimated savings do not count.
Related integrations
Teams running MongoDB usually run these too. OhChimp finds the waste in each and drafts every fix as a plan you approve.
Redis
Keyspace, TTLs, eviction, and memory
MySQL
Unused indexes, slow queries, instance sizing
Elasticsearch
Index sizing, shard count, retention