I have been reading documentation and watching screencasts specific to Mongo DB over the past few days and I am at a loss for when a solution like this would be better than a typical pg or mysql environment.
Specifically, my question is under what circumstance (w/ use case would be nice) would you want to go the nosql route?
Thanks!
Many disparate writers. Especially when the writers can get segmented due to disconnections in the network, and will later need to resync data that has been written to on both sides of the bifurcation. This breaks ACID, and while you can solve the problem with explicit business logic, you're now in NoSQL territory. This is very common in military situations, but any system in which everyone is a prolific writer is going to have some write-contention lock on an ACID system.
Fluid schemas. Changing a schema in a traditional DB is an expensive operation that often requires some sort of server downtime or other complicated processes. With most NoSQL systems it's trivial. So if you've got data from a lot of disparate sources to merge and/or have situations where you may want to start tracking new information at a later date, NoSQL systems will be a lot easier to deal with. Merging two data sources so they can be charted with each other is a good example I can think of.
Low-bandwidth replication. Once you've broken ACID you can have readers and writers on leaf nodes of a network graph with partial data which don't need full replicas of the database. My own company's product, the Army's Command Post of the Future uses this.
Data interoperability. Most NoSQL databases allow you to introspect the data without knowing the schema ahead of time, allowing connections between disparate systems to happen easier.
Massive scaling. This is the one that is most-often debated, and most often abused by NoSQL proponents. If this is the only reason you're choosing NoSQL, start with MySQL instead and scale later.
Use Case
We use MongoDB for a large scale extremely transient data structure.
It in effect works as a job tracker / manager with many work units being processed every second.
The work unit has no defined schema (different units are invented somewhat frequently) yet we need to have the ability to query for specific fields or properties without iterating over the entire DB.
So to recap:
highly transient, highly available (can't afford to block for a query) with a work load of approximately 600QPS for a single "commodity" machine running in the cloud.
Fact of the matter is it is extremely difficult to do the same on a SQL machine while still maintaining the same costs.
Other popular use cases for MongoDB (also for us) are statistic collection, it is extremely efficient at incrementing specific properties inside documents, much more so then most RDBMS systems.
Again, it's not that it is impossible to do so in MySQL it's just more expensive and takes more time (more skill) which for a small company or a fast development environment means it can't be done.
Some REST APIs return JSON data (for example, many of the open government data APIs). If you want to dump the REST data to a local data store (in case you need to run analysis, etc), ingesting a JSON object with MongoDB is trivial. No need to define a table schema. Even better, if the JSON object changes over time (e.g. the REST API returns additional fields) you can still ingest the data in one step. Try that with a relational database!