MongoDB World LogoExplore MongoDB World 2019 announcements

MongoDB and Oracle Compared

Overview

In the 1970’s, Oracle Corporation became the first company to commercialize the relational database. At a time when software engineers were writing code on pads of paper, Oracle created software that provided tremendous gains in efficiency. The RDBMS became a standard and Oracle became one of most established and entrenched software vendors in the enterprise. Alternatives like MongoDB arrived within the past decade to address the changes in the way we store and manage data.

Today, modern enterprises are thinking about ways to better leverage 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 Oracle.

This page provides an overview of Oracle 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.

What is Oracle?

Oracle is a global technology company specializing in database management systems. It’s core database offering is Oracle Database 12c Enterprise Edition (and forthcoming 18c), which is sold via a per-processing licensing model with required licensed add-ons for specific functionality. In Oracle, you pre-define your database schema based on your requirements and set up rules to govern the relationships between fields in your tables. Related information may be stored in separate tables, but associated through the use of foreign keys and joins. Any changes in schema necessitates a migration procedure that can take the database offline or significantly reduce application performance.

What is MongoDB?

MongoDB is a 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 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 Oracle. 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 Oracle 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 Oracle have close analogs in MongoDB. The table below outlines the common concepts across Oracle and MongoDB.

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

Feature Comparison

Like Oracle, 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.

OracleMongoDBNoSQL Data Store
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 cloudsPartial: AWS and Oracle cloudYesNo

Query Language

Both Oracle and MongoDB have a rich query language. Below are a few examples of SQL statements and how they map to MongoDB. A more comprehensive list of statements can be found in the MongoDB documentation.

OracleMongoDB
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()

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 Oracle – it also means they don't consume valuable database resources. Oracle 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 Oracle Enterprise database, so developers are forced to use another database technology (such as SQLite or BerkeleyDB) and write bespoke, complex solutions, or license expense database options, to sync with the backend Oracle database.

Why use MongoDB instead of Oracle?

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 cells in relational tables.

When evaluating databases, it is critical to consider the relative costs of each solution -- not just the cost of the software, but also the hardware, development and deployment costs. Organizations save $ millions in cost by switching from Oracle to MongoDB as a result of gains in developer productivity, reduced licensing, and lower hardware 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 Oracle. 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 Oracle often requires significant, custom engineering work or investment in expensive, custom hardware.

Users Selecting MongoDB over Oracle

As the following examples illustrate, MongoDB’s selection over Oracle is driven by radical improvements to developer productivity, application performance, and scale, while significantly reducing cost and lock-in:

  • To keep pace with demands from the business, Travelers Insurance modernized its development processes with a microservices architecture supported by agile and DevOps methodologies. But the rigidity of its existing Oracle and SQL Server databases imposed blockers to moving at the speed they needed. The solution was MongoDB and its flexible data model. They eliminated the 3-day wait to make any database changes, creating a software development pipeline supporting continuous delivery of new business functionality.

  • Financial giant RBS has modernized its investment banking systems with a new data fabric powered by MongoDB . As a result of decommissioning hundreds of Oracle servers, it has accelerated developer productivity to build new applications faster, created a simplified cloud-ready infrastructure for data scale, and avoided millions of dollars of cost.

  • Telefonica migrated its customer personalization service from Oracle to MongoDB. Using Oracle, it took 7 developers, multiple iterations and 14 months to build a system that just didn't perform. Using MongoDB, a team of 3 developers built its new personalization service in 3 months, which now powers both legacy and new products across the globe. MongoDB helps Telefonica be more agile, save money and drive new revenues streams.

  • China Eastern moved its travel search apps from Oracle to MongoDB. Using MongoDB enabled the company’s project and engineering teams to build an application that was not possible with Oracle, transforming customer experience, and driving more business online. The simplicity of the document data model, dynamic schema, idiomatic drivers and indexing flexibility means the development teams can now launch new applications faster, while also unlocking significant cost savings.

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 Oracle 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 our guide to relational database migration.

A step-by-step guide for project teams that want to know how to migrate to MongoDB, covering schema design, query language, and moving data. It also explains the considerations for teams that come from relational database backgrounds and want to build new applications on MongoDB.