MongoDB Documentation, Release 3.0.4 11.1.8 Does MongoDB require a lot of RAM? 11.1.9 How do I configure the cache size for MMAPv1? 11.1.10 Does MongoDB require a separate caching layer for application-level caching? 11.1.11 Does MongoDB handle caching? 11.1.12 Are writes written to disk immediately, or lazily? 11.1. FAQ: MongoDB Fundamentals 745 Not necessarily. It’s certainly possible to run MongoDB on a machine with a small amount of free RAM. MongoDB automatically uses all free memory on the machine as its cache. System resource monitors show that MongoDB uses a lot of memory, but its usage is dynamic. If another process suddenly needs half the server’s RAM, MongoDB will yield cached memory to the other process. Technically, the operating system’s virtual memory subsystem manages MongoDB’s memory. This means that Mon- goDB will use as much free memory as it can, swapping to disk as needed. Deployments with enough memory to fit the application’s working data set in RAM will achieve the best performance. FAQ: MongoDB Diagnostics (page 779) for answers to additional questions about MongoDB and Memory use. MongoDB has no configurable cache for MMAPv1 storage engine. MongoDB uses all free memory on the system automatically by way of memory-mapped files. Operating systems use the same approach with their file system caches. For the WiredTiger storage engine, you can specify the maximum size of the cache that WiredTiger will use for all data. See storage.wiredTiger.engineConfig.cacheSizeGB and --wiredTigerCacheSizeGB . No. In MongoDB, a document’s representation in the database is similar to its representation in application memory. This means the database already stores the usable form of data, making the data usable in both the persistent store and in the application cache. This eliminates the need for a separate caching layer in the application. This differs from relational databases, where caching data is more expensive. Relational databases must transform data into object representations that applications can read and must store the transformed data in a separate cache: if these transformation from data to application objects require joins, this process increases the overhead related to using the database which increases the importance of the caching layer. Yes. MongoDB keeps all of the most recently used data in RAM. If you have created indexes for your queries and your working data set fits in RAM, MongoDB serves all queries from memory. MongoDB does not implement a query cache: MongoDB serves all queries directly from the indexes and/or data files. Writes are physically written to the journal (page 308) within 100 milliseconds, by default. At that point, the write is “durable” in the sense that after a pull-plug-from-wall event, the data will still be recoverable after a hard restart. See commitIntervalMs for more information on the journal commit window. While the journal commit is nearly instant, MongoDB writes to the data files lazily. MongoDB may wait to write data to the data files for as much as one minute by default. This does not affect durability, as the journal has enough information to ensure crash recovery. To change the interval for writing to the data files, see syncPeriodSecs . See also: