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

Back to Table of Contents

We are the MongoDB experts. Over 4,900 organizations rely on our commercial products, from Fortune 100 enterprises to the most agile startups. 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 Atlas is a database as a service for MongoDB, letting you focus on apps instead of ops. With MongoDB Atlas, you only pay for what you use with a convenient hourly billing model. With the click of a button, you can scale up and down when you need to, with no downtime, full security, and high performance.

MongoDB Cloud Manager is a cloud-based tool that helps you manage MongoDB on your own infrastructure. With automated provisioning, fine-grained monitoring, and continuous backups, you get a full management suite that reduces operational overhead, while maintaining full control over your databases.

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?

Back to Table of Contents

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

Why is MongoDB useful?

Back to Table of Contents

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?

Back to Table of Contents

MongoDB is typically used as the primary database for operational applications with real-time requirements (i.e., low-latency, always-on availability). MongoDB is generally a good fit for 80%-90% of the applications you may be building today. MongoDB is easy to develop against, run, and scale in ways that are hard, if not impossible, with relational databases. The addition of multi-document transactions in MongoDB 4.0* will make it easier than ever for developers to address an even more complete range of use-cases. See the Does MongoDB support ACID transactions question.

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.

While many organizations have successfully migrated from an RDBMS to MongoDB, you cannot drop-in MongoDB as a replacement for legacy applications built around the relational data model and SQL. However, organizations are benefiting from modernizing mission-critical, revenue generating applications to MongoDB. For example, Cisco migrated its ecommerce platform from a legacy relational database to MongoDB. As a result, it has improved customer experience by reducing latency 8x and eliminated downtime during system upgrades. Its development teams can build and release new applications faster, while the company’s e-commerce platform can tap into the business agility enabled by cloud computing.

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?

Back to Table of Contents

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 MongoDB Architecture Guide.

Does MongoDB support ACID transactions?

Back to Table of Contents

Because documents can bring together related data that would otherwise be modeled across separate parent-child tables in a relational schema, MongoDB’s atomic single-document operations already provide transaction semantics that meet the data integrity needs of the majority of applications. One or more fields may be written in a single operation, including updates to multiple sub-documents and elements of an array. The ACID guarantees provided by MongoDB ensure complete isolation as a document is updated; any errors cause the operation to roll back so that clients receive a consistent view of the document.

Multi-document transactions, scheduled for MongoDB 4.0 in Summer 2018*, will feel just like the transactions developers are familiar with from relational databases – multi-statement, similar syntax, and easy to add to any application. Through snapshot isolation, transactions provide a globally consistent view of data, enforce all-or-nothing execution, and they will not impact performance for workloads that do not require them. The addition of multi-document transactions makes it even easier for developers to address more use-cases with MongoDB. Sign up for the beta program.

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 MongoDB Architecture Guide.

Is MongoDB an alternative to Hadoop?

Back to Table of Contents

Many organizations are harnessing the power of Hadoop and MongoDB together to create complete big data applications:

  • MongoDB powers the online, real time operational application, serving business processes and end-users, exposing analytics models created by Hadoop to operational processes

  • Hadoop consumes data from MongoDB, blending it with data from other operational systems and sources to generate sophisticated analytics and machine learning models. Results are loaded back to MongoDB to serve smarter and contextually-aware operational processes – i.e., delivering more relevant offers, faster identification of fraud, better prediction of failure rates from manufacturing processes improved customer experience.

There are several architectural properties of Hadoop that help to determine the types of applications suitable for the system:

  • HDFS provides a write-once-read-many, append-only access model for data.

  • HDFS is optimized for sequential reads of large files (64MB or 128MB blocks by default).

  • Hadoop does not use indexes. Data is scanned for each query.

  • HDFS is designed for high-throughput, rather than low-latency.

  • Hadoop jobs tend to execute over several minutes or hours

Users need to make analytic outputs from Hadoop available to their online, operational apps. These applications have specific access demands that cannot be met by HDFS, including:

  • Millisecond latency query responsiveness.

  • Random access to indexed subsets of data.

  • Supporting real time expressive ad-hoc queries and aggregations against the data, making online applications smarter and contextual.

  • Updating fast-changing data in real time as users interact with online applications, without having to rewrite the entire data set.

Learn more about MongoDB and Hadoop.

Where can I run MongoDB?

Back to Table of Contents

MongoDB can be run anywhere, providing you complete freedom from platform lock-in.

MongoDB Atlas provides you with a complete, pay-as-you-go fully managed service for MongoDB in AWS, Azure, and Google Cloud Platform.

You can download MongoDB and run it yourself anywhere. MongoDB Ops Manager is the best way to run MongoDB on your own infrastructure – whether that lives on-premise or in a public cloud – making it fast and easy for operations teams to deploy, monitor, backup and scale MongoDB. Many of the capabilities of Ops Manager are also available in the MongoDB Cloud Manager service.

Does MongoDB scale?

Back to Table of Contents

Tens of thousands of organizations use MongoDB to build high-performance systems at scale. Organizations ranging from Fortune 100 enterprises to the most agile startups rely on MongoDB. They've grown from single server deployments to clusters with over 1,000 nodes, delivering millions of operations per second on more than 100 billion documents and petabytes of data. Learn more.

How does MongoDB ensure high availability?

Back to Table of Contents

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 MongoDB Architecture Guide.

How does MongoDB ensure consistency?

Back to Table of Contents

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 MongoDB Architecture Guide.

Is MongoDB schema-less?

Back to Table of Contents

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?

Back to Table of Contents

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 Ops Manager versus traditional backup strategies?

Back to Table of Contents

Ops Manager offers a lot of advantages, including:

  • Point-in-Time-Recovery, Scheduled Backups. 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. Ops Manager Backup automates this for you.

  • Queryable Backup. Query backups directly without having to restore them. Find the backup you need or examine how data has changed over time.

Ops Manager is included with MongoDB Enterprise Advanced, and provides continuous backup and point-in-time restore for MongoDB. Those interested in a cloud-based backup solution should consider MongoDB Cloud Manager, which provides continuous, online backup and point-in-time restore for MongoDB as a fully managed service.

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

What's new in the MongoDB 3.6 release?

Back to Table of Contents

Review this page to learn more

Where does the name MongoDB come from?

Back to Table of Contents

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?

Back to Table of Contents

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.

*Safe Harbour Statement: The development, release, and timing of any features or functionality described for our products remains at our sole discretion. This information is merely intended to outline our general product direction and it should not be relied on in making a purchasing decision nor is this a commitment, promise or legal obligation to deliver any material, code, or functionality.