- Document Store or Relational Table Store
- Transactional or Non-Transactional
The second one is actually tied to the first in this case. Transactional only matters if you are going to be updating multiple target records at a time. In a Relational Table Store this is almost certainly going to be the case, but in a Document Store you can architect it so that the single document you are storing contains everything so you don't need to do multiple-record updates.
The third, secret requirement actually narrowed the field even more. This is the fact that I must be able to use the store during unit testing - if it's not tested it doesn't work! - which removed a lot of the NoSQL field from play. For Relational Table Stores - i.e. SQL databases - I can use HSQL or Derby during unit testing for a representation of the final database, and likely PostgreSQL as the real production store. For a Document Store, MongoDB has a library somebody wrote to allow you to run an embedded version, which is perfect for unit testing. The library actually downloads, unpacks and runs MongoDB of the appropriate version for you to use, and tidies up afterwards.
I've actually chosen to go with MongoDB for this, in part because I've not yet successfully written a project with it (and I'm a glutton for punishment) and in part because I think the Document Store is actually going to be a good fit. It means, for example, I can store entire character details - their equipment, skills, stats, etc - as a single Document and not as details spread across many different tables. We shall see how it goes.