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. With support for multi-document ACID transactions in MongoDB it’s now even easier for developers to address a wide range of use cases with the best way to work with data - the document model.
This page provides an overview of MySQL and MongoDB, and the appropriate use cases for each. You can learn more about the benefits of modernizing legacy systems and development processes by visiting our legacy modernization page.
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 predefine 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.
MongoDB is an open, non-tabular 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, as 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 was designed to create a technology foundation that enables development teams through:
The document data model – presenting them the best way to work with data.
A distributed systems design – allowing them to intelligently put data where they want it.
A unified experience that gives them the freedom to run anywhere – allowing them to future-proof their work and eliminate vendor lock-in.
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 over a dozen languages - 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 transactional 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.
With multi-document transactions, MongoDB is the only database to combine the ACID guarantees of traditional relational databases, the speed, flexibility, and power of the document model, and an 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.
Many concepts in MySQL have close analogs in MongoDB. The table below outlines the common concepts across MySQL and MongoDB.
|ACID Transactions||ACID Transactions|
|Secondary Index||Secondary Index|
|JOINs||Embedded documents, $lookup & $graphLookup|
Both MySQL and MongoDB have a rich query language. A comprehensive list of statements can be found in the MongoDB documentation.
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, achieving scale with MySQL often requires significant custom engineering work.
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 3-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.
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.
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.
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.
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.
The MongoDB Realm and Stitch serverless platforms are 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. Atlas Triggers let your app respond in real time to data changes, wherever the changes originated. The trigger code is written and executed within Atlas, 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 Realm brings your data and the power of objects to your mobile and IoT devices. With local access to your data and a familiar query language, your apps run faster, and keep on running – even when disconnected from the network. Realm 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.
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.
Through the MongoDB Server and Atlas Data Lake, MongoDB offers an integrated data platform that shares the same query language and tools, fully managed for you by the cloud-native Atlas service, enabling you to serve a broad range of operational and analytical applications.
The MongoDB database server is designed to serve both OLTP applications requiring millisecond response times and real time analytics workloads. Whenever you are considering a relational or NoSQL database, you should consider leveraging MongoDB as the best way to work with data. Since documents can unite related data that would otherwise be modeled across disparate parent-child tables in a relational schema, MongoDB can provide faster access to data by avoiding JOINs across multiple tables.
Beyond the MongoDB Server, Atlas Data Lake extends the power and productivity of MongoDB to offline analytics workloads. The Atlas Data Lake allows you to quickly and easily query data in any format on Amazon S3 (with other cloud providers coming) using the MongoDB Query Language and tools.
For more information on all the cases where you can leverage the power of MongoDB and the document model, download the MongoDB Use Case Guidance whitepaper.
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.
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.