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).

A lot of people like it because it makes development faster. It's like the scripting language of databases: you can get stuff out the door really fast (with the obvious power/responsibility caveats).

It's schema-less, and as the data format is a binary form of JSON, you can store arbitrary, even nested data structures directly. Indexes can be put on fields deep within the structure.

This saves a lot of time you'd normally spent defining schemas, and is very flexible. It didn't completely replace SQL for me, but it's a good fit for the heterogeneous free-form data generally encountered on the web.

I use it for offline operations since we only have a single overloaded MS SQL database server. So i sync the data to my local mongo instance creating documents with only the fields that i need. And i have scripts written to do analytics and partition the data to reveal patterns and generate reports and so on.

It's very fast and the flexible schema makes the code much more flexible and easy to write. And did i mention it was fast?

You should definitely give it a try and consider using it for such systems.

My only issue with it is that i am running it on a 32-bit system and so i'm limited to 2GB a database.

If you are in the NYC area, you should check out the MongoDB track at PgEast next week to find out ;) https://www.postgresqlconference.org/

If you are working with location data, Mongo has built in geospatial indexing built in since 1.4 (earlier in the unstable builds) - http://www.mongodb.org/display/DOCS/Geospatial+Indexing which has been a big draw for a number of people I know using it (it looks like 1.8 brings spherical distances to the stable branch which makes the geo lookups a lot more useful if you need accurate distances and not just near by lookups).

My experience has been that many applications (web apps in particular) use a relational database to break up documents into an SQL schema so they can be indexed, then assemble them again when needed. Mongo really ratchets down the friction on that operation. Instead of spending time building a schema and writing lots and lots of insert and update statements, you just build a JSON object and send it over.

some of the sweet spots where it _might_ be better in than postgres are:

- horizontal scalability

- flexible datastructures

- map/reduce

For me the sweet spot is its flexibility.

I work a lot on data aggregation, where I can create a bunch of tables each day, then maintain them etc. For me it's almost a dream really :)

As well they are adding features such as geonear that makes it appealing for other uses (which I have, too).

It is good at web scale.