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. For example, the ALTER TABLE command required to add a single, new field to Craiglist’s MySQL database would take months to execute. The Craigslist team migrated to MongoDB because it can accommodate changes to the data model without such costly schema migrations.
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.
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.
When would MySQL be a better fit?While most modern applications require a flexible, scalable system like MongoDB, there are use cases for which a relational database like MySQL would be better suited. Applications that remquire complex, multi-row transactions (e.g., a double-entry bookkeeping system) would be good examples. MongoDB is not a drop-in replacement for legacy applications built around the relational data model and SQL.
A concrete example would be the booking engine behind a travel reservation system, which also typically involves complex transactions. While the core booking engine might run on MySQL, those parts of the app that engage with users – serving up content, integrating with social networks, managing sessions – would be better placed in MongoDB
Are MongoDB and MySQL used together?There are many examples of hybrid deployments of MongoDB and MySQL. In some cases, it’s a matter of using the right tool for the job. For example, many e-commerce applications use a combination of MongoDB and MySQL. The product catalog, which includes multiple products with different attributes, is a good fit for MongoDB’s flexible data model. On the other hand, the checkout system, which requires complex transactions, would likely be built on MySQL or another relational technology.
In other cases, new business requirements push organizations to adopt MongoDB for the next-generation components of their applications. For example, Sage Group, one of the world’s leading suppliers of business management software and services, integrated MongoDB into its popular Enterprise Resource Planning (ERP) solution for midsize companies. Sage customers now enjoy a higher degree of functionality and personalization as a result of the integration. While many Sage products were originally built on and continue to run on MySQL, the latest user experience functionality centers around MongoDB.
These few exceptions aside, we think MongoDB is almost always a better option than MySQL because of its flexible data model and scalable architecture.
Want to Learn More? Get the RDBMS to MongoDB Migration GuideRelational 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 Salesforce.com, 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.