For this particular application a NoSQL family database like MongoDB is probably OK becuase most DB accesses will be file reads by ID or mod lookup by ID. Big sequential scans of the mods list would be better suited to a SQL derivitive for a number of database implementation reasons. I would caution you to steer clear of MongoDB itself however. Mongo is a primarily in-memory store, which is awesome for reads and writes since Mongo escapes a memory to filesystem synchronization on write most of the time. However this introduces obvious issues with data reliability. If your "real" datastore is a RAM cache that may or may not get synchronized to disk, what happens if the server looses power? Kiss your data goodby... Furthermore despite having a sharding system setting up sharding with Mongo is a total pain in my experience, limiting Mongo to applications for which a single monolithic server will suffice. I contend that while MongoDB may serve as a sufficient datastore for getting this project started, it is a poor choice in the long run and other datastores, especially RethinkDB offer the same features list with much stronger consistency gurantees and frankly a better management system. Just my $0.02.