MongoDB and MySQL Compared

Overview

The relational database has been the foundation of enterprise applications for decades, and since MySQL’s release in 1995 it has been a popular and inexpensive option, especially as part of the ubiquitous LAMP stack underpinning early web applications.

Today, modern enterprises are thinking about better ways to store and manage their data -- whether it's to gain better customer insight, adapt to changing user expectations, or beat competitors to market with new applications and business models. As a result, many of the assumptions that drove the development of earlier relational databases have changed:

  • Demands for higher developer productivity and faster time to market, with traditional rigid relational data models and waterfall development of monolithic applications giving way to agile methodologies, microservices, and DevOps, compressing release cycles from months and years to days and weeks.

  • The need to manage massive increases in new, rapidly changing data types – structured, semi-structured, and polymorphic data generated by new classes of web, mobile, social, and IoT applications.

  • The wholesale shift to distributed systems and cloud computing, enabling developers to exploit on-demand, highly scalable compute and storage infrastructure, with the ability to serve audiences any place they work and play around the globe, while meeting a whole new set of regulatory demands for data sovereignty.

As a result, non-tabular databases, like MongoDB, have emerged in order to address the requirements of new applications, and modernize existing workloads. And with support for multi-document ACID transactions from MongoDB 4.0, it’s now even easier for developers to address use-cases that are now, or will in future, struggle with MySQL.

This page provides an overview of MySQL and MongoDB, and the appropriate use cases for each.

What is MySQL?

MySQL is a popular open-source relational database management system (RDBMS) that is developed, distributed and supported by Oracle Corporation. Like other relational systems, MySQL stores data in tables and uses structured query language (SQL) for database access. In MySQL, you pre-define your database schema based on your requirements and set up rules to govern the relationships between fields in your tables. Any changes in schema necessitates a migration procedure that can take the database offline or significantly reduce application performance.

What is MongoDB?

MongoDB is an open-source, non-relational database developed by MongoDB, Inc. MongoDB stores data as documents in a binary representation called BSON (Binary JSON). Related information is stored together for fast query access through the MongoDB query language. Fields can vary from document to document; there is no need to declare the structure of documents to the system – documents are self-describing. If a new field needs to be added to a document, then the field can be created without affecting all other documents in the collection, without updating a central system catalog, and without taking the system offline. Optionally, schema validation can be used to enforce data governance controls over each collection.

MongoDB’s document data model maps naturally to objects in application code, making it simple for developers to learn and use. Documents give you the ability to represent hierarchical relationships to store arrays and other more complex structures easily.

Native, idiomatic drivers are provided for 10+ languages – and the community has built dozens more – enabling ad-hoc queries, real-time aggregation and rich indexing to provide powerful programmatic ways to access and analyze data of any structure.

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

MongoDB 4.0 added support for multi-document transactions, making it the only open source database to combine the ACID guarantees of traditional relational databases, the speed, flexibility, and power of the document model, with the intelligent distributed systems design to scale-out and place data where you need it. Through snapshot isolation, transactions provide a consistent view of data, and enforce all-or-nothing execution to maintain data integrity. Transactions in MongoDB feel just like transactions developers are familiar with in MySQL. They are multi-statement, with similar syntax (e.g. start_transaction and commit_transaction), and therefore easy for anyone with prior transaction experience to add to any application.

Unlike MySQL and other relational databases, MongoDB is built on a distributed systems architecture, rather than a monolithic, single node design. As a result, MongoDB offers out-of-the-box scale-out and data localization with automatic sharding, and replica sets to maintain always-on availability.

Terminology and Concepts

Many concepts in MySQL have close analogs in MongoDB. The table below outlines the common concepts across MySQL and MongoDB.

MySQLMongoDB
ACID TransactionsACID Transactions
TableCollection
RowDocument
ColumnField
Secondary IndexSecondary Index
JOINsEmbedded documents, $lookup & $graphLookup
GROUP_BYAggregation Pipeline

Feature Comparison

Like MySQL, MongoDB offers a rich set of features and functionality far beyond those offered by simple NoSQL data stores. MongoDB has a rich query language, highly-functional secondary indexes (including text search and geospatial), a powerful aggregation framework for data analysis, faceted search, graph processing and more. With MongoDB you can also make use of these features across more diverse data types than a relational database, and you can do it at scale.

MySQLMongoDBNoSQL Data Store
Open sourceYesYesYes
ACID TransactionsYesYesNo
Flexible, rich data modelNoYesPartial: schema flexibility but support for only simple data structures
Schema governanceYesYesNo
Expressive joins, faceted search, graphs queries, powerful aggregationsYesYesNo
Idiomatic, native language driversNoYesNo
Horizontal scale-out with data locality controlsNoYesPartial: no controls over data locality
Analytics and BI readyYesYesNo
Enterprise grade security and mature management toolsYesYesNo
Database as a service on all major cloudsYesYesNo

Query Language

Both MySQL and MongoDB have a rich query language. A comprehensive list of statements can be found in the MongoDB documentation.

MySQLMongoDB
INSERT INTO users (user_id, age, status)
VALUES ('bcd001', 45, 'A')
db.users.insert({
  user_id: 'bcd001',
  age: 45,
  status: 'A'
})
SELECT * FROM users
db.users.find()
UPDATE users SET status = 'C'
WHERE age > 25
db.users.update(
  { age: { $gt: 25 } },
  { $set: { status: 'C' } },
  { multi: true }
)
db.start_transaction()
 cursor.execute(orderInsert, orderData)
 cursor.execute(stockUpdate, stockData)
db.commit()
s.start_transaction()
 orders.insert_one(order, session=s)
 stock.update_one(item, stockUpdate, session=s)
s.commit_transaction()

Why use MongoDB instead of MySQL?

Organizations of all sizes are adopting MongoDB because it enables them to build applications faster, handle highly diverse data types, and manage applications more efficiently at scale.

Development is simplified as MongoDB documents map naturally to modern, object-oriented programming languages. Using MongoDB removes the complex object-relational mapping (ORM) layer that translates objects in code to relational tables. MongoDB’s flexible data model also means that your database schema can evolve with business requirements.

MongoDB can also be scaled within and across multiple distributed data centers, providing new levels of availability and scalability previously unachievable with relational databases like MySQL. As your deployments grow in terms of data volume and throughput, MongoDB scales easily with no downtime, and without changing your application. In contrast, to achieve scale with MySQL often requires significant, custom engineering work.

Developer Productivity with JSON Documents

Working with data as flexible JSON documents, rather than as rigid rows and columns, is proven to help developers move faster. It’s not hard to find teams who have been able to accelerate development cycles by 4-or-5x after moving to MongoDB from relational databases. Why is this?:

  • Documents are natural. Documents represent data in the same way that applications do. Unlike the tabular rows and columns of a relational database, data can be structured with arrays and subdocuments – in the same way applications represent data, as lists and members / instance variables respectively. This makes it much simpler and faster for developers to model how data in the application will map to data stored in the database.

  • Documents are flexible. Each document can store data with different attributes from other documents. As an example, consider a product catalog where a document storing details for an item of mens’ clothing will store different attributes from a document storing details of a tablet. This is a property commonly called “polymorphism”. With JSON documents, we can add new attributes when we need to, without having to alter a centralized database schema. At worst, this causes downtime, at best, significant performance overhead in a relational database. The flexibility documents bring allows the developer to much more easily handle the semi and unstructured data generated by modern mobile, web, and IoT applications.

  • Documents make applications fast. With data for an entity stored in a single document, rather than spread across multiple relational tables, the database only needs to read and write to a single place. Having all the data for an object in one place also makes it easier for developers to understand and optimize query performance.

It’s for these reasons that MySQL, and other relational databases, have added support for JSON. However, simply adding a JSON data type does not bring the developer productivity benefits of a document database to MySQL. Why? Because MySQL’s approach can detract from developer productivity, rather than improve it. Consider the following:

  • Proprietary Extensions: Querying and manipulating the contents of a JSON document requires the use of separate MySQL-specific SQL functions to access values, which will not be familiar to most developers. In addition, they are not supported or recognized by 3rd party SQL tools, such as BI platforms, data warehouse connectors, ETL and ESB pipelines, and more.

    • How is MongoDB different: The MongoDB API is widely understood, and adopted by industry standard tools and connectors. Several mega-vendor database companies have even adopted the MongoDB API themselves.

  • Legacy Relational Overhead: Even with JSON support, MySQL users are still tied to multiple layers of SQL/relational functionality to interact with JSON data – low level JDBC/ODBC drivers and Object Relational Mappers (ORMs). To experienced MySQL developers, these layers maybe familiar, but to many other developers who want to interact with documents and data through APIs that are natural and idiomatic to their programming language, these layers impose high learning overhead. ORMs are also generally recognized as hard to optimize for performance and query efficiency – even for experienced relational developers. In addition, query optimization statistics for JSON data are more limited than those maintained for regular relational data types.

    • How is MongoDB different: MongoDB drivers are implemented in the methods and functions that are idiomatic and natural to the programming languages used by developers.

  • Complex Data Handling: When using JSON data, MySQL drivers do not have the capability to properly and precisely convert JSON into a useful native data type used by the application. This includes different types of numeric values (e.g. floating points, 64-bit integers, decimals) timestamps, and dates, or a Map or List in Java or a Dictionary or List in Python. Instead developers have to manually convert text-based JSON in their application, losing the ability to have fields that can take on multiple data types in different documents (polymorphism) and making the computation, sorting and comparison of values difficult and error-prone.

    • How is MongoDB different: Binary Encoded JSON (BSON) used by MongoDB and its drivers supports advanced data types not supported by regular text-based JSON.

  • No Data Governance: MySQL offers no native mechanism to validate the schema of JSON inserted or updated in the database, so developers need to add either application or database-side functionality to apply governance controls against the data.

    • How is MongoDB different: Schema validation, based on the JSON Schema IETF standard, allows developers and DBAs to define and enforce a prescribed schema structure for each MongoDB collection.

  • Schema Rigidity: MySQL users still need to define a schema for their regular relational data. If the schema is then modified to accommodate new application requirements, the table is locked for some operations until existing data is copied into the new schema, requiring applications to be quiesced during schema migration.

    • How is MongoDB different: Developers and DBAs can combine the flexibility of a fully dynamic schema with the governance controls needed for some applications across all data stored in the database, not just subsets of it.

Increasing Developer Productivity with MongoDB’s Serverless and Mobile Platforms

The MongoDB Stitch serverless platform is the best way to work with MongoDB, cutting development time in half by taking care of mundane backend jobs such as service integrations, and getting data safely to your application frontend. Stitch QueryAnywhere lets you execute any MongoDB query, right from inside your frontend app. Stitch Triggers let your app respond in real time to data changes, wherever the changes originated. The trigger code is written and executed within Stitch, giving them far more flexibility and making them easier to maintain than stored procedures and triggers in MySQL – it also means they don't consume valuable database resources. MySQL offers no equivalent way of working with data or services, forcing you to waste months writing thousands of lines of undifferentiated, boilerplate code, and then provisioning application servers to run it on.

MongoDB Mobile brings your data and the power of the document model to your mobile and IoT devices. With local access to your data and the full MongoDB query language, your apps run faster, and keep on running – even when disconnected from the network. Stitch Mobile Sync (coming soon) keeps the data in MongoDB Atlas and all your devices in sync. There is no native mobile MySQL database, so developers are forced to use another database technology (such as SQLite) and write bespoke, complex code, or integrate third party solutions to sync with the backend database.

Users Selecting MongoDB over MySQL

As the following examples illustrate, MongoDB’s selection over MySQL is driven by radical improvements to developer productivity, application performance, and scale:

  • Baidu started out with MongoDB in 2012, initially migrating its user address book service from MySQL after hitting performance and scalability limits. Now over 100 different products and services are powered by MongoDB running on a 650 node cluster, deployed across multiple data centers, storing over 1PB of data. The scalability of MongoDB’s distributed design and developer productivity from the flexible document data model is unmatched by MySQL.

  • Experian Health selected MongoDB over MySQL and other relational databases to power its Universal Identification Manager, a new application the company uses to uniquely identify healthcare customers. MongoDB was chosen because of its flexible data model, scalability, strong performance, and overall cost. Developing the Universal Identity Manager on a relational database would have meant that Experian Health developers would need to execute up to 10 SQL joins to positively match a patient's identity. Using MongoDB allowed the company to simplify its schema to remove that complexity; drastically reduce the number of queries; improve performance; and simplify growth as the data volume increases.

  • Sega HARDlight, publisher of iconic gaming titles such as Sonic the Hedgehog, Crazy Taxi, and Kingdom Conquest faced increased scalability challenges as its games moved to online and mobile platforms. It's solution was to migrate from on-premise data centers and MySQL tabular databases to MongoDB, running in the fully managed Atlas service in the cloud with agile DevOps processes. The results: building new games faster by using the MongoDB document model, and scaling to millions of users enjoying an always-on gaming experience.

  • Viacom Media Networks, home of MTV, Comedy Central, Nickelodeon, and dozens of other brands, built its high volume polling, voting, and data collection service on MongoDB after moving from MySQL. MongoDB’s flexible document data model, scale-out design, and rich aggregation pipeline allow Viacom to capture and analyze data at scale.

  • Biotech giant Thermo Fisher reduced reduced experiment times from days to minutes following its migration from MySQL on AWS Aurora to MongoDB and the fully managed Atlas database as a service. In additional to delivering 6x higher performance with 40x less code, MongoDB also helped reduce the schema complexity of the app.

What are common use cases for MongoDB?

MongoDB is a general purpose database that is used for a variety of use cases. The most common use cases for MongoDB include Single View, Internet of Things, Mobile, Real-Time Analytics, Personalization, Catalog, and Content Management. With the addition of multi-document transactions, it is even easier for you to address a complete range of use cases with MongoDB.

When would MySQL be a better fit?

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.

Want to Learn More? Get the RDBMS to MongoDB Migration Guide

Relational databases are being pushed beyond their limits because of the way we build and run applications today, coupled with growth in data sources and user loads. To address these challenges, companies like MTV and Cisco have migrated successfully from relational databases to MongoDB. In this white paper, you'll learn:

  • Step by step how to migrate from a relational database to MongoDB.

  • The relevant technical considerations, such as differences between the relational and document data models and the implications for schema design.

  • Indexing, queries, application integration and data migration.