Table of Contents
MongoDB disk and memory requirements
08. September 2026
Table of Contents
Note
Starting with Feature Release 20, MongoDB is no longer included in the FotoWeb installer and must be installed separately.
Fotoware recommends running the latest available version of MongoDB to ensure you receive the latest security patches and improvements.
Each release of Fotoware On-premises is tested and validated with the latest MongoDB version available at the time of release. While newer MongoDB versions may not yet have been explicitly validated for that release, customers are encouraged to keep MongoDB up to date and follow MongoDB's recommended upgrade path.
Disk requirements
The amount of disk space required by MongoDB depends entirely on the number of assets in the system. If the number of assets is stable, or if there is a steady influx/deletion rate in the archive that keeps the number of assets constant, the instance will not grow.
Each asset remains in MongoDB for approximately 10 days after deletion. Accordingly, the approximate formula for calculating the number of assets can be expressed as follows:
N = i * (t + 10) + p
p: The number of assets permanently in the system.
t: The maximum number of days an asset is kept in the system after ingestion.
i: The number of assets ingested per day (24 hours).
N: The total number of assets in the system at any given time.
Each asset requires approximately 10 KB of space. The formula to calculate the disk space required for assets in MongoDB is:
Disk space (Megabytes) = N * 0,01
(N is the total number of assets, as explained above)
Disk performance is important
For best performance, store MongoDB data on a fast, local SSD. You cannot store MongoDB data on a network drive.
All indexed files are pushed to MongoDB
When an Index Manager is configured to push data to a FotoWeb server's MongoDB instance, all the indexed content from that Index Manager server is pushed to MongoDB, even if only some of the indexes are used as archives in FotoWeb. For example, FotoWeb may host only a few archives from the Index Manager server while Fotostation uses other indexes. In this case, data from all indexes is pushed to the MongoDB server.
MongoDB cleanup routine
MongoDB does not free up disk space when data is deleted. However, already allocated disk space can be reused by new data. MongoDB admin commands can be used to shrink and defragment the database files. However, FotoWeb does not automatically run such commands on MongoDB.
FotoWeb uses MongoDB's "small files" option to ensure that disk space is allocated in small chunks rather than in huge blocks that grow exponentially. Older versions of FotoWeb did not do this, so older installations may have large MongoDB data files that are mostly unused.
Note
MongoDB is not a cache - it is a database. Valuable data, such as albums, CMS exports, and users and groups, is stored in MongoDB.
MongoDB is NOT a cache; it is a database. Valuable data (albums, CMS exports, and users and groups) is stored in MongoDB.
Deleting database files causes data loss that can only be restored from a backup.
Storing the MongoDB database files in an alternative location
The location of the MongoDB data files is not configurable per se. However, you can create a file system junction point to place the folder elsewhere.
Memory requirements
MongoDB requires approximately 1 GB of RAM per 100.000 assets. If the system has to start swapping memory to disk, this will have a severely negative impact on performance and should be avoided.
Page File requirements
Feature 16 and earlier only
This information applies to Feature Release 16 and earlier.
Also, it's important to follow the MongoDB outlined requirements for Page File size. The following information is copied from the MongoDB production notes:
Configure the page file such that the minimum and maximum page file sizes are equal and at least 32 GB. Use a multiple of this size if, during peak usage, you expect concurrent writes to many databases or collections. However, the page file size does not need to exceed the database's maximum size.
A large page file is needed because Windows requires sufficient space to accommodate all regions of memory mapped as writable during peak usage, regardless of whether writes actually occur.
The page file is not used for database storage and will not receive writes during normal MongoDB operations. As such, the page file will not affect performance, but it must exist and be large enough to meet Windows’ commit rules during peak database activity.
NOTE: Dynamic page file sizing is too slow to accommodate the rapidly fluctuating commit charge of an active MongoDB deployment. This can result in transient overcommitment situations that may lead to abrupt server shutdown with a VirtualProtect error 1455.