MySQL is a relational database management system (RDBMS) from the Oracle Corporation. Like other relational systems, MySQL stores data in tables and uses structured query language (SQL) for database access. When MySQL developers need to access data in an application, they merge data from multiple tables together in a process called a join. In MySQL, you predefine your database schema and set up rules to govern the relationships between fields in your tables.
MongoDB is a NoSQL database that stores data as JSON-like documents. Documents store related information together and use the MongoDB query language (MQL) for access. 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. Optionally, schema validation can be used to enforce data governance controls over each collection.
Organizations of all sizes are adopting MongoDB, especially as a cloud database, 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. MySQL's rigid relational structure adds overhead to applications and slows developers down as they must adapt objects in code to a relational structure.
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.
MongoDB automatically replicates your data to additional nodes for high availability and durability. In the event of a system failure, failover completes automatically - typically in less than 5 seconds.
While MySQL can replicate data to another node, failover between nodes is a complex, manual process that increases application downtime.
MongoDB’s document data model maps naturally to objects in application code, making it simple for developers to learn and use.
While many developers are familiar with SQL and the relational model that MySQL uses, they impose constraints on database schema and data modeling that slow development down.
MongoDB includes native support for distributing, or sharding, a database across any number of commodity machines in a way that is transparent to the application.
Scaling MySQL requires purchasing a beefier server or implementing a more complex sharding solution in the application.
Replication of data in MongoDB is a first-class citizen - groups of MongoDB nodes that hold the same data set are called replica sets. Replica sets enable high availability of data, with developers able to fine-tune their consistency requirements for even greater performance and availability.
Blazing fast failover. If your database goes down, every second counts. MongoDB can natively detect failures, automatically electing a new primary node in less than five seconds in most cases. Applications can continue to function while the malfunctioning node is replaced.
Failover in MySQL is a manual process - taxing your operations team at the most critical time. If a database node goes down, it can take minutes before a replacement can be brought up.
Tuneable consistency guarantees. MongoDB's read concern and write concern. As an example, an application requesting a lower read concern would see lower database latency and be able to continue functioning in the event of a serious database outage, in exchange for the possibility of seeing stale data.
MySQL does not support tuneable consistency guarantees, limiting the options developers have to ensure their applications are available even if a several database nodes are down.
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 like MySQL, data can be structured within arrays and subdocuments – in the same way applications represent data, as lists and members / instance variables respectively.
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 television. 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. Changing schema causes downtime or significant performance overhead in a relational database like MySQL.
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.
MongoDB includes native support in the database for sharding data across multiple nodes.
Scale your applications cheaply. Sharding is cost-effective, spreading the load on the database across multiple sets of commodity hardware. Buying several low-cost machines is often cheaper than buying a smaller number of machines with significantly beefier specifications - as would be necessary to scale a relational database.
No need to make changes to your application to scale. In most relational systems, scaling the database behind an application requires making application-level changes or enduring downtime while the database is migrated to a new, larger server. Since the relational data model includes frequent JOINs, placing tables across multiple nodes must be done with extreme care.
In MongoDB, a new shard can be added at anytime and will automatically begin migrating data. There are no changes to be made in the application. Shards can be geographically distributed around the world with Atlas Global Clusters, providing low latency access to users around the world.
Both databases support a rich query language.
MySQL, like many relational databases, uses structured query language (SQL) for access.
MongoDB uses the MongoDB Query Language (MQL), designed for easy use by developers. The documentation compares MQL and SQL syntax for common database operations.
Database performance can vary widely depending on a number of factors - database design, application query patterns and load on the database being just a few. Since MongoDB's document model stores related data together, it is often faster to retrieve a single document from MongoDB than to JOIN data across multiple tables in MySQL.
Many customers have evaluated and selected MongoDB over MySQL, both because of better performance at scale and for radical improvements to developer productivity.
Biotech giant Thermo Fisher 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.
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.
Sega migrated on-premise MySQL tabular databases to MongoDB running in the fully managed Atlas service.
The result? Building new games faster with the MongoDB document model, scaling an always-on gaming experience to millions of users.
Experian Health selected MongoDB over MySQL and other relational databases to power its Universal Identification Manager, a new application used to uniquely identify healthcare customers.
Using a relational database like MySQL would have forced developers to execute up to 10 SQL joins to positively match a patient's identity. Using MongoDB allowed Experian to remove that complexity, drastically reduce the number of queries, and improve performance.
For the reasons discussed above, 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 to SQL: 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). 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. 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.
In this white paper, you'll learn:
Step by step how to migrate from a relational database to MongoDB.
The relevant technical considerations, including differences between relational and document data models and the implications for schema design.
Indexing, queries, application integration and data migration.