When to Use (and Not to Use) MongoDB

DZone 's Guide to

When to Use (and Not to Use) MongoDB

If you've been considering a jump to NoSQL, here's an overview of MongoDB and how it can help you and your work.

· Database Zone ·
Free Resource

MongoDB is an object-oriented, simple, dynamic, and scalable NoSQL database. It is based on the NoSQL document store model. The data objects are stored as separate documents inside a collection — instead of storing the data into the columns and rows of a traditional relational database. The motivation of the MongoDB language is to implement a data store that provides high performance, high availability, and automatic scaling. MongoDB is extremely simple to install and implement. MongoDB uses JSON or BSON documents to store data. General distributions for MongoDB support Windows, Linux, Mac OS X, and Solaris.

Terminology and Concepts

If you're not familiar with MongoDB, here's a quick translation cheat sheet to get you familiar with the terminology.

SQL Server MongoDB
Database Database
Table Collection
Index Index
Row Document
Column Field
Joining Linking & Embedding
Partition Sharding (Range Partition)
Replication ReplSet

Making the Choice

Of course, your choice of database is always a decision based on pros and cons.


  • Document oriented
  • High performance
  • High availability — Replication
  • High scalability – Sharding
  • Dynamic — No rigid schema.
  • Flexible – field addition/deletion have less or no impact on the application
  • Heterogeneous Data
  • No Joins
  • Distributed
  • Data Representation in JSON or BSON
  • Geospatial support
  • Easy Integration with BigData Hadoop
  • Document-based query language that’s nearly as powerful as SQL
  • Cloud distributions such as AWS, Microsoft, RedHat,dotCloud and SoftLayer etc:-. In fact, MongoDB is built for the cloud. Its native scale-out architecture, enabled by ‘sharding,’ aligns well with the horizontal scaling and agility afforded by cloud computing.


  • A downside of NoSQL is that most solutions are not as strongly ACID-compliant (Atomic, Consistency, Isolation, Durability) as the more well-established RDBMS systems.
  • Complex transaction
  • No function or stored procedure exists where you can bind the logic


Good For:

  • E-commerce product catalog.
  • Blogs and content management.
  • Real-time analytics and high-speed logging, caching, and high scalability.
  • Configuration management.
  • Maintaining location-based data — Geospatial data.
  • Mobile and social networking sites.
  • Evolving data requirements.
  • Loosely coupled objectives — the design may change by over time.

Not so Good For:

  • Highly transactional systems or where the data model is designed up front.
  • Tightly coupled systems

And there you have it! Now, you've got a quick and easy overview of how MongoDB works, some use cases where it can shine, and how it relates to SQL technology.

If you enjoyed this article and want to learn more about MongoDB, check out this collection of tutorials and articles on all things MongoDB.

database ,document database ,mongodb ,nosql

Opinions expressed by DZone contributors are their own.

{{ parent.title || parent.header.title}}

{{ parent.tldr }}

{{ parent.urlSource.name }}