I've used it once, for an app that holds data which was not a good fit for a traditional relational database. The app in question essentially involved collectin

I've used it once, for an app that holds data which was not a good fit for a traditional relational database. The app in question essentially involved collecting data in a web app and then using that data to fill out hundreds of PDF forms. It gets really complicated as the data has to be potentially formatted (say a phone number might need to be split 555-555-5555 on one form but one number per square on another), concatenated (name might need to join first, last mi), as well as data about what page and x/y coordinates things go on for each form. Initial attempts in SQL were painful. The only real way to do it was a key value table, but that gets painful when it comes to formatting for web presence (notably, each document has sections with a group of fields, plus some fields may need to be grouped together such as a series of checkboxes, or parts of a name). So at that point we're looking at writing up XML files to describe the presentation of these 200 forms from a key/value table to the web app. At that point I realized this was doable, but going to be a mess. Enter mongo. Mongo essentially let's us store a dynamic schema of documents. For each form we can stick it all in a single document, as a series of embedded models, with all metadata and values needed in one go. We also get nice revision control within that using mongoid. We can now fetch all the data for a form, as well as save all the data for the form, in one VERY fast atomic operation (we're talking 100-800 field definitions for each form). Having never used mongo, it only took me a few days to implement this complete with handling for all field types and performance was fantastic. Mongo also made it quite easy to populate our data since we're essentially just storing a tree of key and values. We wrote up a tool that loads up the PDF's and let's us draw boxes on top of the fields and set up the metadata, then export that to a YAML file for each form. The YAML is then stored in a tradiational SQL database and is used to create a new form in the system by simply converting it to a nested hash and having mongoid save it. Slick. I'm getting a bit wordy here, but I think it's a great real world example of the type of problem mongo is a good fit for. I wouldn't personally use mongo for something that a relational database is a good fit for, but for something like this it allows you to solve the problem quicker and with significantly less code to maintain (really, the CRUD code for forms is no more than with SQL and probably less since it's only one operation on a document, and my pdf form generator is < 200 lines of ruby).