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

MongoDB provides products and services to help customers get to production faster with less effort and risk, including:

MongoDB Enterprise provides a management platform for automating, monitoring, and backing up MongoDB deployments; advanced security; support from MongoDB engineers; on-demand training; platform certification; and a commercial license.

MongoDB Management Service (MMS) offers automated deployment and zero-downtime upgrades, disaster recovery and continuous monitoring in the cloud.

Production Support helps customers proactively identify and address potential issues. The same engineers that build the database are available 24x7x365 to help teams address their needs quickly and safely.

Development Support helps customers move swiftly through application development, test and implementation by providing expert support, on-demand training, a healthcheck with MongoDB consultants and access to the advanced capabilities included with MongoDB Enterprise.

MongoDB Consulting helps customers get to production quickly, with packaged service offerings that add value at critical points through the project lifecycle, such as schema design and performance tuning.

MongoDB Training provides certification and education for developers and DBAs with free online classes, in person classes in major cities all over the world, and private, customized offerings in customer facilities.

Contact us to learn more.

Why is MongoDB useful?

MongoDB helps organizations:

  • Build Apps Faster. MongoDB improves developer agility, allowing organizations to iterate on their ideas and bring new applications to market faster.

  • Scale for Performance. MongoDB scales horizontally to ensure high-performance, low-latency data access for real-time applications.

  • Reduce Costs. MongoDB can be up to 70% less expensive than relational databases. The cost disparity is driven by increased developer productivity, MongoDB's use of commodity hardware, and substantially lower licensing and support costs.

Learn more about why organizations adopt MongoDB and the results they achieve in one of our whitepapers:

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 suitable for 60%-80% of the applications being built by organizations today. MongoDB is simple to operate and scale in ways that are hard if not impossible with relational databases.

MongoDB excels in many use cases where relational databases are not a good fit, such as 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 Internet of Things, mobile apps, product catalogs, 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. Each write can be configured 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. Users can configure their reads and writes to achieve the consistency and availability required for their 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?

MMS is available 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. It can be used 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. It can be run privately, behind your firewalls and on your own infrastructure. To get started with MMS On-Prem, contact us.

Does MongoDB scale?

Tens of thousands of organizations 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.

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

To learn about best practices and considerations for running MongoDB at scale, read our whitepaper 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 schemaless?

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.

Developers and DBAs designing schemas in MongoDB 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 several advantages, including:

  • Point-in-Time-Recovery. You can generate a restore image from an exact time in the past, which can be very useful 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 whitepaper 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

  • MongoHQ

  • 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 whitepaper, 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.