Use Cases

The goal of MongoDB is to be a fairly general purpose tool that can be used for a variety of applications. Common uses include online/operational tasks and applications, as well as select business intelligence / analytics use cases.

The Production Deployments page provides hundreds of examples of real world use cases; see also the use case docs in the MongoDB Manual.

Why do people use MongoDB?

Two reasons: easy scale-out, and coding velocity ("agility").

The original catalyst for the NoSQL space is the growth of "big data" and the need for scalable databases to store that data. However, a secondary but often equally important factor in MongoDB adoption is increased software development "agility."

MongoDB developers report big productivity gains writing their apps, and often use Mongo regardless of whether or not scaling out is required. While there are MongoDB systems that exceed one million operations per second, MongoDB is also used for many apps that easily run on a single server.

MongoDB makes app development faster because it

1. eliminates object-relational-mapping work and the so-called "impedance mismatch". (Mongo uses JSON, which maps well to object-style data.)
2. allows dynamic schemas ("schemaless" operation), which is synergistic with agile software development methodologies, which themselves hugely speed project completion.
3. makes it much much easier for the developer to store and manipulate complex data and polymorphic data.
4. reduces the amount of work required to scale out the application and increase system speed.

When should you consider using MongoDB?

• You find yourself coding around database performance issues – for example adding lots of caching.
• You are storing data in flat files.
• You are batch processing yet you need real-time.
• You are doing agile development, for example, Scrum. (MongoDB's flexible schema enables iterative development.)
• Your data is complex to model in a relational db. For example a complex derivative security might be hard to store in a traditional format. Electronic health records is another example. If you were considering using an XML store, that's a strong sign to consider MongoDB and its use of JSON/BSON.
• Your project is very late, and it is database intensive.
• You have been forced to use expensive SANs, proprietary servers, or proprietary networks for your existing database solution.
• You are deploying to a public or private cloud.

When should you use something else?

The following problem domains are not a good match for MongoDB.

• Problems requiring SQL. MongoDB supports ad hoc queries and has its own query language, but does not support SQL. This is likely a show stopper for many legacy apps until they are due for a refresh.
• Systems with a heavy emphasis on complex transactions such as banking systems and accounting. These systems typically require multi-object transactions, which MongoDB doesn't support. It's worth noting that, unlike many "NoSQL" solutions, MongoDB does support atomic operations on single documents.  As documents can be rich entities, for many use cases, this is sufficient – for example many users have built e-commerce systems using MongoDB.
• Traditional Non-Realtime Data Warehousing (sometimes). Traditional relational data warehouses and variants (columnar relational) are well suited for certain business intelligence problems – especially if you need SQL for your client tool (e.g. MicroStrategy). Exceptions where MongoDB is good are:
  • cases where the analytics are realtime
  • cases where the data very complicated to model in relational
  • when the data volume is huge
  • when the source data is already in a mongo database

The new aggregation framework (vv2.2+) improves MongoDB's reporting capabilities, as well as availability of a Hadoop adapter. MongoDB support is being added to more client analytic tools as time passes (e.g., Jaspersoft and Pentaho now have MongoDB support).

If you had to pick one thing you wouldn't use it for, what's the first thing that comes to mind?

A double-entry bookkeeping accounting system is probably the perfect anti-example.

• The intrinsically tabular application data maps well to relational data models
• The application requires very complex transactions at times
• The application requires a good amount of reporting. Relational and SQL are quite good at reporting
• The volume of data is probably relatively small

That said, one Fortune 500 company uses MongoDB as a base for a complex application that reconciles billions of dollars in revenues – so don't project too far off the above example.

Do big companies use MongoDB?

Yes. Quite a bit actually, including some companies with over $100B in annual revenues.

How may databases should my organization standardize on? Is one-size-fits-all over?

Historically there is already some diversity: most large enterprises use an RDBMS for OLTP (e.g., Oracle), a data warehouse technology (e.g., Neteeza), and some niche tools for special problems (e.g. a time series db).

Today we are seeing organizations add one more db tool to their toolbox: a NoSQL database.

We are also seeing some organizations (for example, one very large UK media company) adopt a Mongo First policy. That is to say, MongoDB is their default for building new applications. They use other tools, but by default, MongoDB. This is a good example that MongoDB is fairly general purpose. Note the word "application": they might at times use other things for pure reporting. Other companies are beginning to do this too; obviously these organizations have already done a few projects with MongoDB and are quite comfortable with it at this point.

Oh, and if you are a startup, just use MongoDB. :-)

Common Use Cases: Articles and Videos

Note: You'll find more on the production deployments page and the 10gen videos page.

• Blog post: on why flexible schemas are useful
• Analytics / BI
  • Analytics talks
  • Blog post: real-time dashboarding
• Archiving blog post
• Blog post : structured event logging
• Content Management Presentations Systems - as a document-oriented (JSON) database, MongoDB's flexible schemas are a good fit for this.
• E-Commerce
  • Blog post : E-Commerce
  • E-Commerce user talks
• Finance user talks
• Gaming user talks
• Gaming Presentations. High performance small read/writes are a good fit for MongoDB; also for certain games geospatial indexes can be helpful.
• Government user talks
• Media user talks
• Mobile example - FourSquare talk video. Specifically, the server-side infrastructure of mobile systems.. Geospatial key here.
• Web infrastructure presentations MongoDB is very good at real-time inserts, updates, and queries. Scalability and replication are provided which are necessary functions for large web sites' real-time data stores.

Follow @mongodb

Upcoming MongoDB Conferences

• Tokyo - Dec 12