Automatic MongoDB index management — with a hand brake.
Indexterity watches index usage, proposes drops and creates with confidence scores, and applies them through a pipeline that hides, observes, then drops, and can always back out. Read-only until you say otherwise.
Invite-only during early access. Already have an account? Sign in.
- PROPOSED
- APPROVED
- hidden
- observed
- dropped
- undo anytime
What Indexterity does for your indexes
Read-only by default
Connect a cluster and Indexterity analyzes forever without touching it. Writes happen only after an owner flips the cluster live — and even then, indexes only, never your documents.
A safety pipeline, not a script
A drop is hidden first, observed, then put through a regression gate and a pre-flight before it happens. Anything that slows reads is un-hidden, remembered, and cooled down. Undo rebuilds a dropped index from its recorded spec.
Confidence scores
Every recommendation carries a 0–100 score from usage history, redundancy, size and scan frequency. Set an auto-approve threshold, or approve by hand — past regressions cut the score hard either way.
Workload-aware index creation
Recurring query shapes from $queryStats or the profiler become compound indexes in Equality, Sort, Range order with correct sort directions, partial indexes for constant filters, and TTL advisories for manual age-based cleanups. Queries that sort in memory count too, not just collection scans.
Proof, not promises
Freed bytes and their $/month, index-count deltas, and per-collection read/write latency charts — before and after. New indexes are watched too: if writes regress, the build rolls back automatically.
Built for teams
Organizations with owner/member roles, email invites, an immutable audit trail of every executed operation, engine alerts by email and a weekly digest of what read-only clusters would have done.
How it works
- 1
Connect read-only
Paste a connection string. Indexterity first reports exactly which privileges it has, and offers to create its own least-privilege user. Credentials are envelope-encrypted at rest.
- 2
Collect & score
Index usage, sizes, latency and query shapes on a schedule — every recommendation arrives scored and explained in plain language.
- 3
Approve — or set a threshold
Click approve, or let a score threshold promote confident recommendations. The observe gates still stand between any recommendation and a drop.
- 4
Watch the ROI
Latency trends, freed storage and dollars saved accumulate on the dashboard, attributed per index, with undo one click away.
Request access
Clusters start read-only. Your documents are never read, and never touched.
Frequently asked questions
- How do I get access?
- Indexterity is invite-only during early access: ask for an invite and you get a link by email. If you self-host it, the first account you create bootstraps the install and can invite the rest of your team — sign-up mode is a configuration switch, not a hosted-only feature.
- Does Indexterity read my data?
- No. It connects as a least-privilege user whose role grants index management and statistics only — there is no find privilege on your collections, so the server itself refuses any attempt to read documents. Index usage, sizes and latency all come from $indexStats and $collStats, which never expose document contents.
- How does it decide a MongoDB index is unused?
- From $indexStats operation counters, summed across every replica-set member and shard, over at least three snapshots. An index with no operations in any snapshot is flat-zero; one that used to be busy and then went quiet is treated as periodic-dead. Indexes that are still used periodically are never proposed for removal.
- What happens if dropping an index hurts performance?
- A drop is never the first action. The index is hidden first — instant and reversible — and the collection's read latency is baselined. If average read latency rises past the baseline during the observe window, the index is un-hidden automatically, the recommendation is rejected, and the index enters a cooldown so it is not proposed again. Even after a real drop, undo rebuilds it from the spec recorded at drop time.
- How long does an index stay hidden before it is dropped?
- Thirty days by default, and the window adapts to the index itself — set by whichever question is still open. Will anything want this again? That runs at the cadence of the workload, so usage with long gaps (a monthly report, a weekly batch) extends the window to cover a full cycle. Did hiding it hurt? That runs at the rate the index is queried, so one still serving traffic when it is hidden answers within days and is watched for a week rather than a month. An index proven idle across a much longer history is shortened too: the history already was the observation. The window chosen for each drop, and why, is recorded in the audit trail.
- Does it work with Atlas, self-hosted MongoDB and sharded clusters?
- Yes. Sharded clusters are handled explicitly: statistics are summed across shards, and shard-key backing indexes are protected from removal. On Atlas, user management belongs to Atlas, so you create the scoped role there and connect with its string; self-hosted and community deployments can have Indexterity create the user for you.
- Which MongoDB privileges does it need?
- listDatabases, listCollections, listIndexes, indexStats and collStats to analyze; createIndex, dropIndex and collMod to apply changes; optionally system.profile or $queryStats for workload analysis, and serverStatus for the health probe. serverStatus is the one that reads beyond index metadata — it also exposes connection counts and storage-engine internals — so it is optional and a cluster without it works fine. Before storing anything, Indexterity checks the connection string and tells you exactly which of these are missing and what each one enables.
- Can it create missing indexes, not just drop unused ones?
- Yes. Recurring collection scans become index recommendations in Equality, Sort, Range order with correct sort directions, folded together when one index can serve several shapes. So do queries that find their documents through an index and then sort them in memory — invisible to any scan test, and the failure mode that ends in an error rather than slowness. A shape must recur before it counts, so a heavy query someone runs once by hand never leaves an index behind.