# Self-managed mongot on Community Edition: hardware and labour TCO > Source-anchored research for Self-managed mongot on Community Edition: hardware and labour TCO. Run status: COMPLETED. Parent: [Platform Consolidation TCO (Atlas Search/Vector Search vs Separate Search or Vector DB)](https://llms-explorer.com/tree/platform-consolidation-tco-atlas-search-vector-search-vs-separate-search-or-vector-db/) · 5 facets · 21 facts · page: https://llms-explorer.com/tree/self-managed-mongot-on-community-edition-hardware-and-labour-tco/ ## How it works - On Community Edition, the operator installs, configures and operates mongot and supplies its hosts; co-located and dedicated architectures are both available. TCO must therefore include search compute, storage and operational work even when application queries use MongoDB's integrated interface. (high confidence) — [source](https://www.mongodb.com/docs/search/deployment/deployment-options.md) - The Kubernetes FAQ treats mongot indexes as rebuildable derived data: back up mongod and include index reconstruction time in recovery objectives. The direct-deployment troubleshooting guide also requires capacity for replacement index generations. Recoverability therefore carries rebuild time and resource costs even when separate index backups are unnecessary. (medium confidence) — [source](https://www.mongodb.com/docs/kubernetes/current/fts-vs/faq.md) ## Measurements and reference values - MongoDB sizing examples are starting configurations, not measured capacity guarantees: small Low-CPU/vector nodes have 8–16 GB RAM, 50–100 GB storage and 1–2 CPU cores; small High-CPU/full-text nodes have 4–8 GB RAM, 100–200 GB storage and 2–4 cores. Workload measurement and iterative sizing remain necessary. (low confidence) (verified as of 2026-10-14) — [source](https://www.mongodb.com/docs/search/self-managed/current/resource-planning-sizing/quick-start.md) - mongot needs memory for both JVM heap and the operating-system filesystem cache. MongoDB suggests roughly half of dedicated-host RAM for heap, generally staying near or below 30 GB to preserve compressed pointers; assigning most RAM to heap can starve the cache and increase disk access. (low confidence) (verified as of 2026-10-14) — [source](https://www.mongodb.com/docs/search/self-managed/current/resource-planning-sizing/hardware.md) - The hardware guide gives approximately 10 QPS per CPU core as a baseline dependent on query complexity and mappings; the quickstart describes two small nodes with four total cores as roughly 40 QPS. These are related MongoDB planning estimates, not independent benchmarks or a production SLA. (medium confidence) (verified as of 2026-10-14) — [source](https://www.mongodb.com/docs/search/self-managed/current/resource-planning-sizing/hardware.md) - Disk pressure can preserve successful queries while stopping index freshness: documented protection pauses replication around 90% disk utilization and resumes below about 85%. Alert on disk and replication state, because query availability alone does not demonstrate current results. (high confidence) (verified as of 2026-10-14) — [source](https://www.mongodb.com/docs/search/self-managed/current/resource-planning-sizing/hardware.md) ## Problems, failure modes and limitations - Percona specifies 4 GB RAM as a mongot minimum and recommends SSDs, while warning that production collections, vector dimensions and traffic can need substantially more. MongoDB likewise treats sizing as iterative. Budgeting only the startup minimum is not a defensible production hardware estimate. (medium confidence) (verified as of 2026-10-29) — [source](https://docs.percona.com/percona-search-for-mongodb/vector-search-compatibility.html) - A public Marmelab self-managed Docker demo evaluates search on 8,779 documents and reports query timings, but supplies no all-in hardware or labour comparison. Such a small functional demo cannot establish production TCO or a general break-even against Atlas. (low confidence) — [source](https://github.com/marmelab/mongot) ## Comparisons and alternatives - MongoDB recommends generally doubling mongot disk allowance for index rebuilds. Its more specific no-downtime rebuild guidance asks for free space equal to 125% of the old index size, so that operation needs approximately 2.25 times the old index footprint in total. Cost models should preserve that distinction rather than treating the rounded doubling rule as an exact guarantee. (medium confidence) (verified as of 2026-10-14) — [source](https://www.mongodb.com/docs/search/self-managed/current/resource-planning-sizing/hardware.md) - MongoDB documents read-only search indexes at 90% storage utilization and resumption of synchronization below 85%. A September 2026 Community deployment account reports an accepted index staying PENDING with PauseInitialSyncException under disk pressure. The report is anecdotal and AI-assisted; it illustrates troubleshooting work rather than independently establishing exact thresholds. (medium confidence) (verified as of 2026-09-30) — [source](https://www.mongodb.com/docs/search/self-managed/current/resource-planning-sizing/hardware.md) - MongoDB offers co-located and dedicated self-managed architectures. Co-location shares host resources; dedicated search hosts allow resource isolation but add separately provisioned capacity. Model both architectures rather than assuming every Community deployment requires separate search machines. (high confidence) — [source](https://www.mongodb.com/docs/search/deployment/deployment-options.md) - Configuration changes, upgrades and credential or certificate rotations can require mongot restarts. In the documented Kubernetes topology, multiple mongot replicas behind a load balancer, plus multiple Envoy replicas, allow queries to continue through rolling restarts. Budget redundancy and maintenance work rather than extrapolating availability from a one-instance demo. (high confidence) (verified as of 2026-10-14) — [source](https://docs.percona.com/percona-search-for-mongodb/limitations.html) ## Facts and statements - Horizontal mongot scaling also increases load on the source replica set: MongoDB documents a change stream per search/vector index per mongot. Percona documents binding each instance to one replica set or shard. Capacity planning must include database-side replication work as well as additional search hosts. (medium confidence) — [source](https://www.mongodb.com/docs/search/self-managed/current/resource-planning-sizing/hardware.md) - Self-managed operational work includes a monitoring stack, alert definitions, log/FTDC retention and restart planning. Percona documents no built-in metrics UI, startup-only configuration and credential loading, and restart requirements for upgrades or rotations; the independent mongot-doctor repository supplies tooling for indexing lag, OOM events, index health and configuration drift. (medium confidence) (verified as of 2026-10-29) — [source](https://docs.percona.com/percona-search-for-mongodb/limitations.html) - Analytiq Hub reports that its Kubernetes deployment required bringing up the replica set before enabling search to avoid mongot crash loops. It also reports per-node scheduling constraints and EBS storage-class/CSI provisioning failures. These are concrete deployment labour categories, not a measured recurring staff-hours estimate. (low confidence) (verified as of 2026-03-08) — [source](https://analytiqhub.com/tech/kubernetes/devops/mongodb/self-hosted-mongodb-kubernetes-atlas-search/) - Self-managed Community Search requires the operator to provision infrastructure and install, configure, and operate mongot alongside mongod. Consolidation of the query interface therefore does not eliminate the search service or its operating costs. The latter is a TCO inference from the documented deployment responsibilities. (high confidence) — [source](https://www.mongodb.com/docs/search/deployment/deployment-options.md) - Budget memory for both JVM heap and the operating-system filesystem cache. Raising heap without preserving cache headroom can harm search performance; container memory limits must also accommodate memory outside the heap. Provisioning solely from the configured Xmx understates the memory budget. (high confidence) — [source](https://www.mongodb.com/docs/search/self-managed/current/resource-planning-sizing/hardware.md) - Adding mongot replicas has a database-side cost: every search or vector index creates a change stream per mongot. Horizontal search scaling can increase source replica-set replication load, so the TCO model must include any resulting mongod capacity increase. (low confidence) — [source](https://www.mongodb.com/docs/search/self-managed/current/resource-planning-sizing/hardware.md) - Percona documents that operators must supply a monitoring stack, alerts, FTDC retention and log retention. The independent mongot-doctor project implements heap, disk, oplog-window, index and log diagnostics, illustrating concrete monitoring tasks. Neither source measures person-hours or proves a staffing reduction. (medium confidence) (verified as of 2026-10-29) — [source](https://docs.percona.com/percona-search-for-mongodb/limitations.html) - Marmelab demonstrates self-managed full-text, vector and hybrid functionality using two Docker containers and a corpus of 8,779 documents with 384-dimensional embeddings. This independently demonstrates a small deployment pattern; it does not establish production hardware requirements, availability or labour TCO. (low confidence) (verified as of 2026-10-30) — [source](https://github.com/marmelab/mongot) - A defensible comparison should price incremental mongot compute, RAM, storage and I/O, search redundancy and network infrastructure, source-database replication overhead, monitoring, upgrades, security maintenance and recovery work. This is an analytical cost model inferred from operational requirements, not a measured claim that Community Search is cheaper or more expensive than Atlas. (medium confidence) — [source](https://www.mongodb.com/docs/search/self-managed/current/resource-planning-sizing/hardware.md)