When the useful working set and index pages exceed available cache/filesystem memory, query latency becomes more dependent on storage.
Growing application databases and larger active indexes.Configuration matérielle requise pour MongoDB : RAM, AVX, WiredTiger et stockage
Découvrez les exigences de MongoDB en matière d’AVX, de RAM, de cache WiredTiger, de XFS et de SSD, puis choisissez le matériel ZimaOS adapté à l’auto-hébergement de MongoDB.
MongoDB requirements at a glance
MongoDB does not publish one universal RAM minimum, but current self-managed releases have a real CPU compatibility gate: MongoDB 5.0+ requires AVX on x86-64. WiredTiger then sizes its internal cache to the larger of 50% of (RAM minus 1 GB) or 256 MB by default, leaving the rest of memory for the OS filesystem cache and other database work.
- CPU
- MongoDB 5.0+ on x86-64 requires AVX. Current Zima Intel N150, Core i3-1215U and Core i5-1235U processors support AVX2, so they clear that instruction-set gate.
- RAM
- No universal host minimum. Working set, indexes, aggregation/sort workload and concurrency determine useful RAM.
- WiredTiger cache
- Default cache is max(50% × (RAM - 1 GB), 256 MB). MongoDB intentionally leaves substantial RAM outside WiredTiger for the OS filesystem cache and other memory consumers.
- Filesystem
- MongoDB strongly recommends XFS for WiredTiger data-bearing nodes on Linux to avoid performance issues seen with EXT4 in some workloads.
- Storage
- Database and index I/O benefits from low-latency SSD/NVMe. Dataset size alone does not tell you whether the active working set and indexes fit memory.
- Best Zima starting point
- ZimaBoard 2 832 is suitable for small development/self-hosted databases. ZimaBoard 2 1664 or ZimaCube 2 Pro gives more useful memory and storage headroom for larger working sets and app stacks.
From official requirements to the right setup
MongoDB sizing starts with CPU compatibility, then active working set and indexes.
-
Official requirements
Verify AVX support first. MongoDB 5.0+ requires AVX on x86-64; an older CPU can fail before RAM or storage sizing matters.
-
Confirm your needs
Estimate the active working set and index footprint rather than total collection size. Hot documents/index pages benefit from RAM, while cold data can remain on disk.
-
Leave room to grow
Understand WiredTiger's memory split. The default internal cache uses roughly half of RAM after reserving 1 GB, while the OS also caches compressed data files and MongoDB needs memory for queries, connections and other operations.
-
Run it on ZimaOS
Install MongoDB from ZimaOS, run representative reads/writes/aggregations and monitor cache pressure, page faults, disk latency and index behavior before resizing memory or storage.
Check every playback client
- AVX-capable x86-64 CPU
- Working-set size
- Index size
- Concurrent reads/writes
- Aggregation/sort workload
- WiredTiger cache behavior
- XFS/EXT4 filesystem choice
- SSD/NVMe database storage
Official minimum requirements
MongoDB's production documentation defines CPU microarchitecture requirements and cache behavior rather than a simple host-RAM floor.
AVX is a hard compatibility gate for MongoDB 5.0+ x86-64. RAM should be chosen to keep the important working set/indexes responsive while leaving space for both WiredTiger and the OS filesystem cache.
| Requirement | Official minimum | What this supports |
|---|---|---|
| x86-64 CPU | AVX required for MongoDB 5.0+ | A real instruction-set requirement; old non-AVX x86 hosts are not supported. |
| Host RAM | No universal numerical minimum | Working set, indexes and query workload define useful memory. |
| WiredTiger default cache | max(50% × (RAM - 1 GB), 256 MB) | Current MongoDB cache formula. |
| Linux filesystem | XFS strongly recommended for WiredTiger | MongoDB warns of performance issues that may occur with EXT4. |
| Docker | Official MongoDB Community image available | MongoDB documents self-managed Community deployment in Docker. |
| GPU | Not required for MongoDB Server | Database execution is CPU/RAM/storage bound unless a separate application workload uses a GPU. |
When to upgrade your hardware
Upgrade MongoDB when the hot working set/indexes stop fitting or storage becomes the bottleneck.
WiredTiger cache pressure causes frequent disk reads
A shared Docker host runs out of memory despite MongoDB behaving normally
Indexes and write workload make disk latency visible
WiredTiger intentionally claims a substantial cache and the OS uses filesystem cache too. Container/app memory limits may need explicit planning instead of assuming MongoDB will stay tiny.
ZimaOS hosts running MongoDB beside Node/Python apps and other services.More RAM helps caching, but index builds, checkpoints and writes still need responsive persistent storage. MongoDB also strongly recommends XFS for WiredTiger production nodes.
Write-heavy or indexed production-like workloads.Plan hardware growth with confidence
Scale MongoDB with more RAM and faster storage only after understanding WiredTiger's memory model.
Leave memory for the OS page cache
MongoDB explicitly uses memory beyond WiredTiger's internal cache through the filesystem cache. Setting the WiredTiger cache too large can starve the rest of the host.
16 GB Zima tiers provide more room for both MongoDB cache and co-hosted apps.Use XFS and SSD/NVMe for data-bearing workloads
MongoDB strongly recommends XFS with WiredTiger; SSD/NVMe lowers random/index/checkpoint latency compared with slower disks.
Put active DB files on SSD/NVMe, using HDDs primarily for backup/archive where appropriate.Control cache explicitly on memory-limited/shared containers
MongoDB supports explicit WiredTiger cache limits. Container memory ceilings can otherwise make the host/cache assumptions misleading.
Reserve memory for application containers and the OS before assigning the database cache.Treat replica sets/sharding as architecture, not a bigger-box shortcut
Availability and horizontal scale require multiple MongoDB nodes and additional storage/network/operational resources.
A single more powerful Zima server does not provide replica-set failure-domain redundancy.Can it run on ZimaOS?
ZimaOS currently lists MongoDB and a legacy MongoDB 4 package; current deployments should prefer supported MongoDB releases rather than the older EOL generation.
Install the current MongoDB app from ZimaOS
Use the current MongoDB App Store entry for new deployments rather than MongoDB 4, whose upstream generation is end-of-life.
Open MongoDB in the ZimaOS App StoreConfirm AVX and filesystem behavior
MongoDB 5.0+ requires AVX on x86-64; current Zima N150/i3/i5 CPUs support AVX2, while active database storage should follow MongoDB's filesystem guidance.
Read MongoDB production notesUse the official MongoDB Community container guidance
MongoDB documents an official Community image and persistent self-managed Docker workflow.
Read MongoDB Community Docker installationChoose Zima hardware for MongoDB
MongoDB benefits from RAM that holds active indexes/data and from low-latency persistent storage. All current Zima CPU options clear MongoDB's AVX instruction-set gate.
Is this a small app/development MongoDB or a larger working-set database?
Small self-hosted app or development DB
8 GB and AVX2-capable N150 hardware is sufficient for many light databases.
- Small MongoDB deploymentZimaBoard 2 832
- Larger working set / more appsZimaBoard 2 1664
Larger DB/application server
Use more CPU/storage headroom and 16 GB RAM for larger active indexes and concurrent application workloads.
- Larger MongoDB/self-hosting platformZimaCube 2 Pro
No fixed collection size, requests-per-second or user-count guarantee is implied. Working set, index design, queries, aggregation, writes, replication and storage latency dominate results.
| Zima hardware | Best for | Example workload | Core configuration | Recommended boundary | Next step |
|---|---|---|---|---|---|
| ZimaBoard 2 832 | Small MongoDB databases, development and light self-hosted apps. | AVX2-compatible MongoDB with modest active datasets and indexes. |
|
8 GB is shared with ZimaOS/apps; larger working sets or heavy aggregation can make disk/cache pressure visible. | Get Now |
| ZimaBoard 2 1664 | MongoDB plus a larger app stack or working set. | More cache/filesystem headroom and more co-hosted services. |
|
The 4-core N150 can become the next limit for CPU-heavy aggregation/concurrency even when RAM remains available. | Get Now |
| ZimaCube 2 Pro | A larger all-in-one MongoDB and application server. | 16 GB RAM, stronger CPU and SSD/multi-drive expansion for database/app workloads. |
|
Use SSD/NVMe for active MongoDB data; HDD capacity alone is not a substitute for low-latency database storage. | Get Now |
What the Press Says
Highlights from trusted reviewers worldwide.
“ZimaCube 2: Not just another NAS, tested with 25TB storage, local AI agents, 4K transcoding, and real homelab workflows.”Read full review
“The ZimaBoard 2 is a compact x86 server board that can be turned into a mini NAS, home server, media box, or self-hosting hub.”Read full review
“ZimaCube 2: A modern, high-performance NAS with plenty of room to grow—built for users who want more than basic storage.”Read full review
“Coverage focused on ZimaCube 2's open hardware foundation, no monthly fee, and self-hosting flexibility.”Read full review
Loved by the Community
Stories and reviews from people who build with Zima every day.
★★★★★
Zima Blade Little yet Powerful
Maybe I am not digital natives but I live with PCs since 12 years old in 1984 when IBM PC clone come to my home. Many years have passed and many operating system I've tried. For me Zima blade and CasaOS was a quantum leap for home PC enthusiast and server lab machine to make me stay curious and relevant for this era.
★★★★★
Very good!!
I use ZimaCube Pro as 5th Proxmox cluster node. It runs several VMs and containers, including a VM with GPU passthrough to run a self-hosted LLM. A specific LXC container runs a Samba server for NAS capabilities using four of six RAID 6 SATA HDDs with ZFS.
★★★★★
Great innovation for mini server!
It is very useful and makes a powerful mini server for many purposes, including university and college students in engineering and electronics. Thank you so much for making this server.
★★★★★
Avaliação ZimaBoard 2
Construí um servidor de uso pessoal. O desempenho está muito bom e funciona perfeitamente onde quer que eu esteja. A surpresa é não dependermos de grandes estruturas para termos nosso próprio servidor de dados. Como iniciante, estou gostando bastante do ZimaOS, pois ele é simples e eficiente.
Frequently asked questions
FAQ topics follow query fan-out around AVX, WiredTiger memory, 4/8/16 GB hosts, filesystem choice and container memory. Reddit highlights the common 'MongoDB uses all my RAM' confusion, while MongoDB docs provide the actual cache formula.
Does MongoDB require AVX?
Yes for MongoDB 5.0 and newer on x86-64. This is a hard CPU instruction-set requirement. Current Zima Intel N150, Core i3-1215U and Core i5-1235U processors support AVX2.
How much RAM does MongoDB need?
There is no universal minimum for useful production performance. MongoDB sizes WiredTiger cache from available RAM, while working set, indexes and query workload determine whether 4, 8 or 16 GB is comfortable.
Why does MongoDB use about half of my RAM?
WiredTiger's default internal cache is the larger of 50% of (RAM minus 1 GB) or 256 MB. MongoDB also expects the OS filesystem cache to use additional free RAM, so high memory utilization can be intentional.
Does the whole MongoDB database need to fit in RAM?
No. The important goal is keeping the active working set and frequently used index pages in memory. Cold data can remain on disk, although slow storage becomes more visible when the active set exceeds cache.
Is 4 GB RAM enough for MongoDB?
It can be enough for small development or light self-hosted datasets. Under the current WiredTiger formula a 4 GB host gets about 1.5 GB internal cache by default, with the rest serving the OS and other operations.
Why does MongoDB recommend XFS over EXT4?
MongoDB's current production notes strongly recommend XFS for WiredTiger data-bearing nodes because performance issues can occur with EXT4 in some workloads.
Should I set a Docker memory limit for MongoDB?
You can, but then size WiredTiger cache and application headroom with that limit in mind. Container memory ceilings can make default cache assumptions misleading if the database shares a host with many apps.
Can ZimaBoard 2 832 run current MongoDB?
Yes for many small databases. The Intel N150 supports AVX2 and the 8 GB host provides useful cache headroom; move active database files to reliable SSD/SATA storage as the dataset grows.
What sources and further reading informed this MongoDB hardware guide?
MongoDB Production Notes define the AVX and filesystem requirements. WiredTiger and storage FAQ pages define the current cache formula and memory model. Intel processor specifications were used to verify current Zima CPUs support AVX2. Reddit was used for query fan-out around apparent memory growth, not as an official requirement.
