FAQ

MongoDB is open-source. What does MongoDB, Inc. sell?

We are the MongoDB experts. Over 1,000 organizations rely on our commercial products, including startups and 30 of the Fortune 100. We offer software and services to make your life easier:

MongoDB Enterprise Advanced is the best way to run MongoDB in your data center. It’s a finely-tuned package of advanced software, support, certifications, and other services designed for the way you do business.

MongoDB Management Service (MMS) is the easiest way to run MongoDB in the cloud. It makes MongoDB the system you worry about the least and like managing the most.

Production Support helps keep your system up and running and gives you peace of mind. MongoDB engineers help you with production issues or any aspect of your project.

Development Support helps you get up and running quickly. It gives you a complete package of software and services for the early stages of your project.

MongoDB Consulting packages get you to production faster, help you tune performance in production, help you scale, and free you up to focus on your next release.

MongoDB Training helps you become a MongoDB expert, from design to operating mission-critical systems at scale. Whether you’re a developer, DBA or architect, we can make you better at MongoDB.

Contact us to learn more.

Can I get a commercial license for MongoDB?

Yes, you can get a commercial license for MongoDB with the purchase of MongoDB Enterprise.

Why is MongoDB useful?

MongoDB helps you:

  • Create Applications Never Before Possible. MongoDB lets you build apps you could never build before. It can manage data of any structure, no matter how often it changes or it where it comes from, while providing all the features needed to build powerful apps.

  • Build Faster. You move faster with MongoDB because dynamic schemas let you iterate. You spend less time on the database, and more time on the app.

  • Spend Less Money. More productive teams, plus commodity hardware make your projects cost 10% what they would with a relational database.

Learn more about why organizations use MongoDB and what they achieve in one of our white papers:

When should I use MongoDB?

MongoDB is typically used as the primary data store for operational applications with real-time requirements (i.e., low-latency, high availability). MongoDB is generally a good fit for 60%-80% of the applications you may be building today. MongoDB is easy to operate and scale in ways that are hard if not impossible with relational databases.

MongoDB excels in many use cases where relational databases aren’t a good fit, like applications with unstructured, semi-structured and polymorphic data, as well as applications with large scalability requirements or multi-data center deployments.

MongoDB may not be a good fit for some applications. For example, applications that require complex transactions (e.g., a double-entry bookkeeping system) and scan-oriented applications that access large subsets of the data most of the time may not be a good fit for MongoDB. MongoDB is not a drop-in replacement for legacy applications built around the relational data model and SQL.

Some common use cases include mobile apps, product catalogs, real-time personalization, content management and applications delivering a single view across multiple systems. Learn more about common use cases.

How is data stored in MongoDB?

Data in MongoDB is stored in BSON documents – JSON-style data structures. Documents contain one or more fields, and each field contains a value of a specific data type, including arrays, binary data and sub-documents. Documents that tend to share a similar structure are organized as collections.

It may be helpful to think of documents as analogous to rows in a relational database, fields as similar to columns, and collections as similar to tables.

Learn more in the MongoDB Architecture Guide.

Does MongoDB support ACID transactions?

Yes, but in a limited sense. MongoDB supports ACID transactions at the document level; today MongoDB does not support multi-document transactions. For many but not all applications, this is sufficient because data for a record tends to be managed as a single document. Like most databases, MongoDB uses write-ahead logging to an on-disk journal to guarantee write operation durability and to provide crash resiliency.

The distributed nature of MongoDB necessitates additional consideration beyond ACID regarding consistency and availability. MongoDB automatically maintains replica sets, multiple copies of data that are distributed across servers, racks and data centers for high availability (see How does MongoDB ensure high availability?) MongoDB is strongly consistent: all reads and writes are applied to the primary member by default. (See How does MongoDB ensure consistency?) Write operations are automatically applied to all replica set members. You can configure each write to return after success on the primary, on multiple set members, a majority of set members, or all members. Reads can be applied to the primary member, to secondary members if the primary is unavailable, to specific members exclusively (for workload isolation), or to the nearest secondary based on ping distance. You can configure your reads and writes to achieve the consistency and availability required for your application.

Learn more in the MongoDB Architecture Guide.

Is MongoDB an alternative to Hadoop?

MongoDB and Hadoop are complementary. MongoDB powers operational big data applications, and Hadoop powers analytical big data applications.

MongoDB powers real-time applications that demand high performance for read and write operations. Latency for these applications typically ranges from sub-millisecond to tens of milliseconds, and availability must be high in order to meet SLAs for modern application performance.

Hadoop workloads, by contrast, typically involve reading and writing large volumes of data per operation. Jobs typically aggregate and process large volumes of data in batch, with latency measured in minutes and hours.

Learn more about MongoDB and Hadoop.

Is MongoDB Management Service (MMS) a cloud-based service or on-premise software?

You can get MMS via both deployment models – as a cloud-based service and as on-premise software. The cloud-based service includes a free tier and pay-as-you-go offerings. You can use it for MongoDB deployments that run in the cloud or in your own data centers. Get started with MMS in the cloud.

MMS On-Prem is included with MongoDB Enterprise. You can run it privately, behind your firewalls and on your own infrastructure. To get started with MMS On-Prem, contact us.

Does MongoDB scale?

Tons of organizations – tens of thousands of them – use MongoDB to build high-performance systems at scale, including over 30 of the world's 100 largest organizations and many of the world's most successful and innovative web companies.

These MongoDB users typically scale their deployments by distributing data, reads, and writes across groups of commodity servers to address increasing data volume and throughput requirements. They scale their MongoDB clusters from a single server to over 1,000 nodes, more than 100 billion documents and petabytes of data. Learn more about companies – like Yandex, Foursquare and McAfee – running MongoDB at scale.

Many of these companies also use the MongoDB Management Service (MMS) to help manage and automate these large clusters.

To learn about best practices and considerations for running MongoDB at scale, read our white paper on MongoDB Performance Best Practices.

How does MongoDB ensure high availability?

MongoDB automatically maintains replica sets, multiple copies of data that are distributed across servers, racks and data centers. Replica sets help prevent database downtime using native replication and automatic failover.

A replica set consists of multiple replica set members. At any given time one member acts as the primary member, and the other members act as secondary members. If the primary member fails for any reason (e.g., hardware failure), one of the secondary members is automatically elected to primary and begins to process all reads and writes.

Learn more in the MongoDB Architecture Guide.

How does MongoDB ensure consistency?

MongoDB is consistent by default: reads and writes are issued to the primary member of a replica set. Applications can optionally read from secondary replicas, where data is eventually consistent by default. Reads from secondaries can be useful in scenarios where it is acceptable for data to be slightly out of date, such as some reporting applications. Applications can also read from the closest copy of the data (as measured by ping distance) when latency is more important than consistency.

Learn more in the MongoDB Architecture Guide.

Is MongoDB schema-less?

No. In MongoDB schema design is still important. MongoDB's document model does, however, employ a different schema paradigm than traditional relational databases.

In MongoDB, documents are self-describing; there is no central catalog where schemas are declared and maintained. The schema can vary across documents, and the schema can evolve quickly without requiring the modification of existing data.

MongoDB's dynamic schema also makes it easier to represent semi-structured and polymorphic data, as documents do not all need to have exactly the same fields. For example, a collection of financial trading positions might have positions that are equity positions, and some that are bonds, and some that are cash. All may have some fields in common, but some fields ("ticker", “number_of_shares”) do not apply to all position types.

When designing schemas in MongoDB you should consider a number of topics, including the types of queries the application will need to perform, how objects are managed in the application code, and how documents will change and potentially grow over time.

Learn more about schema design:

Should I normalize my data before storing it in MongoDB?

No. Schema design is very important when using MongoDB, but very different from schema design for relational databases.

Learn more about schema design:

What's the advantage of the backup features in MongoDB Management Service (MMS) versus traditional backup strategies?

MMS offers a lot of advantages, including:

  • Point-in-Time-Recovery. You can generate a restore image from an exact time in the past, which can be very helpful for restoring operations just prior to a catastrophic event.

  • Continuous, Incremental Backup. Data is backed up continuously as the cluster updates. Your backups are always up-to-date.

  • Sharded Cluster Backup. Backing up sharded clusters can be hard. MMS Backup automates this for you.

MMS is available as a cloud-based service and as on-premise software.

Get started with MMS in the cloud. To get started with MMS On-Prem, contact us.

To learn more, read the white paper on database backup strategies.

Do you have a cloud product or cloud hosting?

MongoDB was designed for cloud deployments; there is not a different edition of MongoDB for the cloud. Many partners provide MongoDB offerings as part of their cloud products, including:

  • Amazon Web Services

  • IBM Softlayer

  • Rackspace

  • Compose

  • MongoLab

  • Microsoft Azure

Learn more about our cloud partners.

What's new in the MongoDB 2.6 release?

MongoDB 2.6 was released in April of 2014. MongoDB 2.6 adds security, integration and analytics enhancements to ease deployment in enterprise environments, such as LDAP, x.509 and Kerberos authentication. A new query planner and index intersection significantly improve query performance and minimize the number of compound indexes necessary for many deployments. Several operational enhancements were added, including automatic query cancelling to better manage resource utilization, and background index builds, so indexes can be created without impacting application performance.

MongoDB 2.6 also introduced backup and point-in-time restore to MongoDB Management Service (MMS), available on-premise as part of MongoDB Enterprise and in the cloud as a premium service.

For more information on the release, read the What's New in 2.6 white paper, watch for our webinar, and read the release notes.

What will be included in the MongoDB 2.8 release?

The focus of the 2.8 release is document-level locking (i.e., fine-grained concurrency) and automation capabilities for MMS, which allows users to create, upgrade and add capacity to MongoDB deployments of any topology and any size with the click of a button. To learn more about what's coming in MongoDB 2.8, watch cofounder and CTO Eliot Horowitz's keynote at MongoDB World. To learn more about the longer-term roadmap, watch Eliot's roadmap talk at MongoDB World.

Where does the name MongoDB come from?

MongoDB comes from the word humongous. Our founders built large Internet companies like DoubleClick. They consistently ran into the same problems with databases, one of the biggest problems being scalability. When they set out to build MongoDB, they wanted a database that scaled. Thus, MongoDB.

What does the leaf mean in the MongoDB logo?

Our founders believe that coding should be natural, and so should using a database. They want the experience of using MongoDB to be simple and natural. Thus, the leaf.