A MongoDB White Paper

Why the Document Data Model

How JSON Documents Help Developers Innovate Faster
Table of Contents
Introduction 1

Intuitive Data Model: Faster and Easier for Developers 2

Beyond Developer Speed: Application Speed 3
Data Typing 3

Flexible Schema: Dynamically Adapt to Change 3

Schema Governance 4

Universal: JSON Documents for Multi-Model 5

Superset of all Data Models 5

Powerful: Query Data Anyway You Need. ACID without

Compromise 5
Indexing Documents 6
Working with Document Data 7
Data Consistency and Transactional Integrity 8

Distributed: Resilient and Globally Scalable 9

Replication: No Single Point of Failure 9
Sharding for Horizontal Scale Out 10

JSON in Relational Databases 11

Use Cases for Document Databases 11

Summary 12

We Can Help 12

Resources 13
Introduction

Relational databases have a long-standing position in most Meeting these challenges has driven developer adoption of
organizations. Based on a tabular data model composed of non-tabular, sometimes called “NoSQL” databases over the
rows and columns, relational databases – designed back in past decade. There are many flavors of non-relational
the 1970s and popularized in the 80s – became the default databases defined by the data model they support –
way of managing data. key-value, wide-column, and graph. But it is document
databases, based on JSON-like documents, that have risen
However as developers build applications for today's digital
to become the most popular and widely used alternative to
economy, they are facing demands that stretch the limits of
traditional relational systems. This is because the
what’s possible with relational systems. These demands
document data model is:
include:
• Intuitive: mapping to the way developers think and
• Accelerating developer productivity to keep pace with a
code.
constant stream of ideas from the business,
compressing application release cycles from months to • Flexible: dynamically adapting to change.
days and weeks. • Universal: allowing data to be modeled in any shape or
• Storing and querying rapidly changing data that arrives structure (sometimes called “multi-model”).
in all shapes and sizes – structured, semi-structured, • Powerful: enabling developers to work with data for
and polymorphic – where defining a flat, tabular schema almost any class of application using a consistent and
in advance is not practical. expressive API.
• Distributing data across multiple servers and regions for
In this guide, we explore why the document data model has
application resilience, scalability, and intelligent
become so widely used by engineering teams building
geo-placement.
modern applications. We also discuss those features that
differentiate document databases from one another.

1
Intuitive Data Model: Faster and One workaround is to introduce an Object-Relational
Mapping (ORM) layer into the development stack. But this
Easier for Developers creates its own challenges, including managing the
middleware and revising the mapping whenever either the
application code or the database schema changes. These
The tabular row-and-column data model used by relational
changes typically need to be coordinated across multiple
databases bears little resemblance to how data is
engineering teams – developer, DBA, and Ops – creating
represented in application code. In modern programming
complex dependencies that are at odds with modern
languages, the entity you want to store in the database (i.e.,
development practices.
customer, product, order, trade, log message, sensor
reading) is represented as a complete object, with all A further challenge is that ORMs do not always produce
related attributes contained in a single data structure. the most efficient or performant queries, and the
abstraction they present makes it difficult for developers to
Typically developers must coordinate with database
optimize the query.
administrators (DBAs) to translate that rich structure in the
application to one that fits the rules of the relational model.
Through normalization the object’s data is decomposed How the Document Data Model is
across many separate parent-child tables connected by
Different
foreign keys. The example in Figure 1 shows how even a
lightweight customer record is split across seven separate In contrast to the tabular model, the document data model
tables. presents a much more intuitive and natural way to describe
data. This is because documents are consistent with the
way developers think and code.

Rather than splitting data apart and flattening it out across

multiple tables, documents are closely aligned to the
structure of objects in the programming language.
Documents are single and contained data structures with
related data embedded as subdocuments and arrays. In
more advanced document databases like MongoDB, each
element can be individually indexed and updated, no matter
how deeply nested it is within the document.

The JSON document example below contrasts how our

customer object modeled across separate parent-child
tables in a relational database is modeled in a single, rich
document structure in a document database.
Figur
Figuree 1: Customer data modeled across separate tables
in a relational database

Simple applications require tens of tables, escalating to

hundreds or even thousands as the application and its data
becomes more complex.

This difference in data structures, sometimes referred to as

“object-relational impedance mismatch”, makes it difficult
for developers to reason about the underlying data model
while writing code, adding friction to application
development.

2
{ Should your application access patterns require it, some
"_id": "5ad88534e3632e1a35a58d00",
"customerID": 12345, document databases like MongoDB provide the ability to
"name": { JOIN data between multiple collections (analogous to
"first": "John",
tables in a relational database), and to UNION complete
"last": "Doe"
}, collections. This provides additional flexibility for analytics
"address": [ workloads, but is generally not required for most
{
"location": "work", transactional use cases.
"address": {
"street": "16 Hatfields",
"city": "London", Data Typing
"postal_code": "SE1 8DJ"
},
Many relational databases that have been retrofitted with
"country": "United Kingdom",
"geo": { support for JSON columns simply store data as primitive
"type": "Point", JSON data types made up of strings and numbers, or even
"coord": [ 51.5065752,-0.109081 ]
} worse, as opaque BLOBs. There are many native document
} databases that do the same.
],
"email": "[email protected]", MongoDB on the other hand extends the JSON
"phone": [
{ representation with the BSON (Binary JSON) encoding to
"location": "work", include additional data types such as int, long, floating
"number": "+44-1234567890" point, data, and decimal128.
}
],
"dob": "1977-04-01T05:00:00Z", This makes it much easier for developers to reliably index,
"interests": [ "devops", "data science" ], process, sort, and compare more advanced data types
"annualSpend": 1292815.75 representing things like monetary values, geospatial
}
coordinates, and time-series data. This approach also
As a result of the document model approach it’s simpler improves the portability of documents between different
and faster for developers to model how data in the programming languages.
application will map to data stored in the database. It also
significantly reduces the barrier-to-entry for new
developers who begin working on a project – for example, Flexible Schema: Dynamically
adding new microservices to an existing application. Adapt to Change
Beyond Developer Speed: Application The relational data model is built for tabular data where
Speed each record in a table has identical columns. While it’s
possible to handle polymorphism and semi-structured data,
Normalizing data in the tabular model means that
it's inefficient as every row must include columns that may
accessing data for an entity, such as our earlier customer
rarely be populated with data. Working around the basic
record example, requires JOINing multiple tables together.
structural limitations of flat tables consumes development
JOINs incur a performance penalty, even when optimized –
time, requiring lots of additional code.
which takes time, effort, and advanced SQL skills.
In the relational model, the schema for each table must
Documents, on the other hand, present a single place for
also be known in advance and predefined before any data
the database to read and write data for an entity – what is
can be inserted into the database. Practically this means
stored together is typically accessed together. This locality
that developers and DBAs need to define their data model
of data ensures the complete document can be returned in
early in the development cycle. Any subsequent changes to
a single database operation, avoiding the need internally to
the data model then requires complex schema migrations
retrieve data from many different tables and rows.
that need to be coordinated across multiple teams. Schema

3
changes can add performance overhead during the you to maintain similar levels of schema control that
migration process, and in some cases, can even take the relational databases have traditionally afforded.
database offline.
Firstly the document model is polymorphic – fields can vary
92% of respondents in a survey of DevOps professionals from document to document within a single collection. For
reported that it was difficult to accelerate the deployment example, you can enforce that all customer documents
of database schema changes in an effort to match the contain the customer ID, name, address, and the date they
pace at which they deploy application code changes. The opened their account. But you may have additional
survey showed that just under 60% of all application attributes for only some of your customers such as their
changes require modifications to an existing schema, and social media handle, interests, or location data from a
that database changes take longer to deploy than mobile app. Documents make modeling such diverse
application changes. Consider also that in the same survey: attributes easy for developers, elegantly handling data of
any structure.
• 43% of respondents reported they are releasing
changes daily or weekly. Secondly, there is no need to declare the structure of
documents to the database – documents are
• Respondents lost hours or days reviewing database
self-describing. Developers can start writing code and
change scripts.
persist objects as they are created.
• Even after these reviews, 84% had serious production
issues due to database change errors. Thirdly, when you need to make changes to the data model,
the document database continues to store the updated
• 88% took more than an hour to resolve these issues.
objects without the need to perform costly ALTER TABLE
Even trivial modifications to an existing relational schema operations, update a separate ORM middleware layer, and
results in a complex dependency chain – from updating coordinate all of these changes across multiple developer,
ORM class-table mappings to programming language DBA, and Ops teams. Documents allow multiple versions of
classes that have to be recompiled and application code the same schema to exist in the same table space. Old and
changed accordingly. All of these steps have to be new applications can co-exist.
coordinated across different engineering teams,
Through these advantages, the flexibility of the document
consuming both developer and DBA time and adding
data model is well suited to the demands of modern
cycles and cost to the release process.
application development practices.
To avoid this complexity, some developers may be tempted,
or even be recommended to overload the meaning of
existing schema attributes rather than adding new ones. Schema Governance
This runs the risk of obfuscating the code and building While a flexible schema is a powerful feature, there may
technical debt. come a time in an application’s lifecycle – for example
What these issues show is that the relational database’s when it’s functionality has reached steady state – that you
rigid, tabular data model is a poor match for today’s agile, want more centralized control over the data structure and
iterative development processes and continuous delivery content of your database.
pipelines. Most document databases push enforcement of these
controls back to the developer to implement in application
code. However more advanced document databases
How the Document Data Model is
provide schema validation, using approaches such as the
Different
IETF JSON Schema standard adopted by MongoDB.
The document data model offers a number of properties
Using MongoDB’s schema validation, you can define a
that make it flexible and dynamic, but which also enable
prescribed document structure for each collection, with the
database configured to either reject or log any documents

4
that do not conform to it. You can enforce the presence of significantly enhances developer productivity, eliminates
mandatory fields, define data types and permissible field data duplication, and reduces operational costs:
values, and optionally block the addition of new fields that
• Developers work with a single query language across all
have not been explicitly approved by the application owner.
data models, providing a consistent development
With schema validation, you have control to apply data experience.
governance standards to a document schema when an • Rather than trying to run multiple databases, you
application is in production, while maintaining the benefits operationalize one platform with consistent controls for
of a flexible data model in development. resilience, scalability, and security.

Review our Building with Patterns blog series to learn more

Universal: JSON Documents for about schema design best practices for different

Multi-Model categories of use-case.

Lightweight, language-independent, and human readable, Powerful: Query Data Any Way
JSON has become an established standard for data
You Need. ACID without
interchange and storage. JSON is used across the
application stack – from frontend web and mobile services, Compromise
to inter-service messaging, streaming and APIs, through to
the backend server and data storage. You don’t have to
A major point of differentiation between document
transpose, serialize and deserialize your data between
databases is how they allow you to query and manipulate
different formats in each layer of your application stack,
data. Some offer little more than key-value and range
making development much more fluid.
queries. They also require you to rewrite a complete copy
of the document, even if you are just modifying a single
Superset of all Data Models element in an array.

Wherever you use them in your application, a major More advanced document databases offer additional
advantage of JSON documents is that you have the capabilities that allow you to filter, sort, aggregate and
flexibility to model your data any way your application update any fields, no matter how deeply nested they are
needs. within a document.

The nesting of arrays and subdocuments makes The MongoDB Query Language (MQL) and aggregation
documents very powerful at modeling complex pipeline is comprehensive and expressive. You can
relationships between data. But you can also model flat, compose powerful queries and federate them across all
tabular and columnar structures, simple key-value pairs, your data wherever it lives – in databases and search for
text, geospatial and time-series data, or the nodes and transactional applications, and in your data lake for
edges of a connected graph data structure. Because of operational analytics.
this flexibility, documents are a superset of all these
As illustrated in Table 1, MQL gives you much more than
different data models.
just simple lookups. You can create sophisticated
Rather than use multiple databases each supporting a processing pipelines for data analytics and transformations
specific data model for each part of your application, the with aggregations, JOINs, UNIONs, geo, text, and graph
multi-model approach offered by document databases search, and on-demand materialized views.

5
 • Find anyone with phone # “1-212…”
Expr
Expressive
essive Queries
• Check if the person with number “555…” is on the “do not call” list

Geospatial • Find the best offer for the customer at geo coordinates of 42nd St. and 6th Ave

Text Sear
Searcch • Find all tweets that mention the firm within the last 2 days

Faceted Navigation • Filter results to show only products <$50, size large, and manufactured by ExampleCo

Aggr
Aggregation
egation • Count and sort number of customers by city, compute min, max, and average spend

• Add an additional phone number to Mark Smith’s record without rewriting the
Native Binary JJSON
SON document at the client
Support • Update just 2 phone numbers out of 10
• Sort on the modified date

Fine-grained Array • In Mark Smith’s array of test scores, update every score <70 to be 0
Operations

• Query for all San Francisco residences, lookup their transactions, and sum the amount
JOI
JOINN ($lookup)
by person

Graph Queries • Query for all people within 3 degrees of separation from Mark
($graphL
($graphLookup)
ookup)

Table 1: MongoDB’s rich query functionality

The SQL to MongoDB mapping chart is a useful resource the output into buckets – for example counting all
for anyone coming to MongoDB from a traditional SQL customers who place one order per day, counting those
development background. It provides examples of SELECT, who place two to five orders per day, etc – it becomes
INSERT, UPDATE, DELETE and table level SQL highly complex in SQL. Using the MongoDB aggregation
statements and contrasts them directly to the equivalent pipeline, you simply add a new stage.
MongoDB Query Language syntax.

The SQL to Aggregation mapping chart provides an Indexing Documents

overview of common SQL aggregation terms, functions,
For your queries to efficiently access data, you should be
and concepts and the corresponding MongoDB
able to declare indexes on any field within your documents,
aggregation operators. MongoDB’s aggregation framework
including fields nested within arrays.
is modeled on the concept of data processing pipelines.
Documents enter a multi-stage pipeline that transforms the Some document databases support only indexes against a
documents into an aggregated result. If you have a query document’s primary key, limiting how you can access data
that returns a set of documents and you then want to without resorting to slow full table scans. Other document
transform them, you simply add new stages as needed. In databases support only a limited range of secondary
the case of SQL, you’d need to rewrite the entire query indexes that are maintained asynchronously from base
from scratch. document data, introducing the complexity of eventual
consistency to your applications.
For the purposes of illustration, consider the final example
in the SQL to Aggregation mapping chart where you are MongoDB overcomes these limitations by offering a broad
looking to count the number of distinct customer IDs and range of index types and features with language-specific
order_date groupings. sort orders to support complex access patterns to your
data. MongoDB indexes can be created and dropped
Using SQL, you would first have to write a subquery to
on-demand to accommodate evolving application
count the distinct groupings. If you then wanted to group
requirements and query patterns.

6
 Index T
Types
ypes Index F
Featur
eatures
es

Primary Index
Index: Every Collection has a primary key TTL Indexes
Indexes: Single Field indexes, when expired delete the
index document

Compound Index
Index: Index against multiple keys in the Unique Index
Index: Ensures value is not duplicated
document

MultiK
MultiKey
ey Index
Index: Index into arrays Partial Index
Index: Expression based indexes, allowing indexes on
subsets of data

Lucene Index
Index: Support for full-text search (MongoDB Case Insensitive Indexes
Indexes: supports text search using case
Atlas) insensitive search

GeoSpatial Indexes
Indexes: 2d & 2dSphere indexes for Sparse Index
Index: Only index documents which have the given
spatial geometries field

Wildc
ildcar
ardd Index
Index: Auto-index all matching fields &
nested elements

Table 2: MongoDB offers fully-featured secondary indexes

Working with Document Data Much of this functionality is also available to you directly
within your favorite IDEs, including VS Code. These
To accelerate developer productivity, MongoDB provides integrations enable MongoDB to fit seamlessly into your
native drivers for all popular programming languages and native workflow and development tools.
frameworks.

Supported drivers include Java, Javascript, C#/.NET, Go, Tools and Connectors
Python, PHP, Rust, Scala and others. All supported
MongoDB drivers are designed to be idiomatic for the In the digital economy, it is vital that developers, business
given programming language – with syntax and behaviors analysts, and data scientists can extract insights from data
that are familiar to developers using those languages. This – whether that is for traditional reporting and BI or to build
makes it much more natural for you to work with the more intelligent applications with machine learning.
database than string-based languages like SQL. MongoDB provides a range of visualization tools and
connectors to make this straightforward:
The documentation includes examples of MongoDB
operations in supported languages – for example inserting • MongoDB Charts is the fastest and easiest way to
one or multiple documents into a collection. In addition, our create visualizations of MongoDB data. You can
Developer Quick Start channel provides deeper tutorials in construct graphs and build dashboards, sharing them
using the MongoDB Query Language with our drivers with other users for collaboration, and embed them
across all of the leading programming languages. directly into your web apps to create engaging,
data-driven user experiences.
Beyond programmatic access, you can also interact with
• The MongoDB Connector for BI lets you use MongoDB
MongoDB graphically using MongoDB Compass, the free
as a data source for your existing SQL-based BI and
GUI for MongoDB. Through Compass you can explore your
analytics platforms such as Tableau, Microstrategy,
schema with histograms that show your documents’ fields,
Looker, Excel, and more, without having to perform any
data types, and values. You can visually create queries and
ETL operations.
aggregation pipelines from the GUI and then export them
as code to your app; manipulate data, view and create • The MongoDB Connector for Apache Spark exposes
indexes; build schema validation rules and views; and more. MongoDB data to all of Spark’s libraries, including

7
 Figur
Figure
e 2: Creating rich visualizations of your data with MongoDB Charts

Scala, Java, Python and R. MongoDB data is Data Consistency and Transactional
materialized as DataFrames and Datasets for Integrity
integration with machine learning frameworks.
While documents make it much easier and faster to model
an application’s data, developer productivity can be
To make it easy for businesses to act on data in real time,
compromised if they then have to struggle to enforce data
many developers are building fully reactive, event-driven
consistency. Some document databases are designed on a
data pipelines. MongoDB goes beyond many other
concept of “eventual consistency”, where there are no
databases with features like Change Streams that allow
guarantees that the application will read the latest version
applications to access real-time data changes in the
of the data written to the database. This forces you to write
database, while MongoDB Atlas Triggers allow you to
complex correctness code if you want to ensure data
execute server-side logic in response to database change
quality.
events. This might be updating related data in other
documents, or calling functions that, for example, send an More advanced document databases like MongoDB
email to a new customer when they sign up to your service, enforce strong consistency, applying consistency
or firing an alert to a user’s mobile app when a large guarantees to both base data, as well as to native
charge is made to their account. secondary indexes. Strong consistency ensures the
application can not read data that is potentially stale or that
With the MongoDB Connector for Apache Kafka, you can
was previously deleted by another client.
build robust data pipelines that move events between
systems in real time, using MongoDB as both a source and
sink for Kafka. The connector is supported by MongoDB
and verified by Confluent.

8
ACID Transactions MongoDB Query Language (MQL)

Most document databases offer atomic guarantees for session.startTransaction();

writes to a single document. This is suitable for many db.orders.insert ({....})
db.stock.update ({ ... } },
applications because the document model brings together { $set: { quantity: ... } }})
related data that would otherwise be modeled across session.commitTransaction();
separate parent-child tables in a tabular schema.
The availability of multi-document ACID transactions
With single document atomicity, one or more fields may be makes it even easier for developers to address a complete
written in a single operation, including updates to multiple range of use cases with MongoDB.
subdocuments and elements of an array. These guarantees
ensure complete isolation as the document is updated; any
Foreign Keys and Referential Integrity
errors cause the operation to roll back so that clients
receive a consistent view of the document. Foreign keys are necessary to maintain referential integrity
in tabular schema models that split data and its
However not every application can be served with atomicity
relationships up across multiple tables.
that is scoped to only a single document. This is why some
document databases go further by offering support for With documents, referential integrity is in-built to the rich,
multi-document ACID transactions. Many implement hierarchical structure of the data model. When modeling a
multi-document transactions via server-side stored parent-child or 1:many relationship with subdocuments or
procedures or in client-side code. In both cases, the arrays, there is no way you can have an orphan record –
developer still has to write the logic to control the related data is embedded inside a document so you know
consistency and isolation necessary to enforce ACID the parent exists.
properties.
Another use of foreign keys is to verify that the value of a
MongoDB takes a different approach by implementing specific field conforms to a range of permissible values –
multi-document transactions in a way that is consistent e.g., country names or user status. You can do this with
with relational databases, making them familiar to MongoDB’s schema validation as data is written to the
developers coming from a SQL background. database, avoiding the need to re-verify the data whenever
you retrieve it.
• They are fully conversational from the application
(whereas some databases insist that all reads are made
before the first write). Distributed: Resilient and
• They also present a similar syntax, supporting multiple
statements with all-or-nothing execution and snapshot
Globally Scalable
isolation. To ensure these guarantees, it is important
developers apply the appropriate read and write Unlike monolithic, scale-up relational databases, most
concerns for their transactions. document databases are distributed systems by design.

To show how straightforward it is to use transactions in As illustrated earlier, rather than the flat tabular data model
MongoDB, the following code snippets compare the with masses of inter-relationships between tables and
transactions syntax for a relational database and the rows, documents are single, self contained data structures.
MongoDB Query Language Therefore it is much easier to distribute documents across
multiple servers while preserving the locality of related data
SQL
in a single, rich document structure and maintaining
START TRANSACTION; performance as the application scales.
INSERT INTO orders (...) VALUES (...);
UPDATE stock SET quantity=... WHERE ...;
COMMIT;

9
 Figur
Figuree 3: Serving always-on, globally distributed, write-everywhere apps with MongoDB Atlas Global Clusters

Through replication and sharding, high availability, Sharding for Horizontal Scale Out
horizontal scaling, and geographic distribution are all built
into the database and easy to use. Through native sharding, MongoDB can scale your
database out across multiple nodes to handle
write-intensive workloads and growing data sizes. Sharding
Replication: No Single Point of Failure with MongoDB allows you to seamlessly scale the
database as your applications grow beyond the hardware
MongoDB replica sets enable you to create up to 50
limits of a single server, and it does so without adding
copies of your data, which can be provisioned across
complexity to the application.
separate servers and geographic regions. With self-healing
recovery, you have resilience to outages and planned To respond to evolving workload demands, you can add
maintenance events. Replica sets also enable you to: and remove shards at any time. You also have the flexibility
to refine your shard key on demand, without impacting
• Scale read operations, intelligently routing queries to a
system availability. As your shard key is modified or as you
copy of the data that is physically closest to the user.
change the cluster topology, MongoDB will automatically
• Isolate different workloads on a single cluster. With rebalance data across shards as needed without manual
MongoDB Atlas Analytics Nodes you can share the intervention.
same data in real time across transactional and
analytical applications, isolating the workloads so they By simply hashing a primary key value, most document
never contend for resource with one another. databases randomly spray data across a cluster of nodes.
This imposes performance penalties when data is queried,
and adds application complexity when data needs to be
localized to a specific region.

10
By exposing multiple sharding policies, MongoDB offers types supported by native document databases such as
you a better approach. With ranged, hashed, and zoned MongoDB makes computing, comparing, and sorting
sharding, you can partition your data based on query data complex and error prone.
patterns or data placement requirements, giving you much
• Poor Dat
Data a Quality & Rigid T Tables
ables: Relational
higher scalability across a diverse set of workloads.
databases offer little to validate the schema of
Global Clusters in MongoDB Atlas – the fully managed documents, so you have no way to apply quality controls
cloud database service – allows you to quickly implement against your JSON data. And you still need to define a
zoned sharding using a visual UI or the Atlas API. You can schema for your regular tabular data, with all the
easily create distributed databases to support overhead that comes when you need to alter your tables
geographically distributed apps, with policies enforcing as your application features evolve.
data residence within specific regions. • Low PPerformance
erformance: Most relational databases do not
maintain statistics on JSON data, preventing the query
planner from optimizing queries against documents, and
Tiered Scaling
you from tuning your queries.
Beyond horizontal scaling, MongoDB also offers tiered
• No sc
scale-out
ale-out: Traditional relational databases offer no
scaling. When working in the cloud, MongoDB Atlas Online
way for you to partition (“shard”) the database across
Archive will automatically tier aged data out of the
multiple instances to scale as workloads grow. Instead
database onto cloud object storage in the Atlas Data Lake.
you have to implement sharding yourself in the
Archived data remains fully accessible with federated
application layer, or rely on expensive scale-up systems.
queries that span both object and database storage in a
single connection string.

This approach enables you to more economically scale Use Cases for Document
data storage by moving it to a lower cost storage tier Databases
without losing access to the data, and without grappling
with slow and complex ETL pipelines.
With the ability to work natively with JSON, web and mobile
backends were some of the first use cases for document
JSON in Relational Databases databases. The flexibility of the data model and distributed
systems design also appealed to developers working on
fast evolving applications – domains such as content
With document databases empowering developers to move management, product catalogs, user profiles, and logging,
faster, most relational databases have added support for represented the next wave of use cases.
JSON columns. However, simply adding a JSON data type
does not bring the benefits of a native document database. All of these remain important applications. But as
This is because the relational approach detracts from document databases have rapidly matured – adding more
developer productivity, rather than improving it. These are powerful query engines, offering stronger durability and
some of the things you will have to deal with: transactional guarantees, hardened security controls, and
more – so document databases are now being used for an
• Pr
Propriet
oprietary
ary Extensions
Extensions: Working with documents even broader range of applications.
means using custom, vendor-specific SQL functions
which will not be familiar to most developers, and which Common use cases for MongoDB include the following:
don’t work with the broad ecosystem of SQL tools. Add
• Customer data management and personalization:
low-level JDBC/ODBC drivers and ORMs and you face
Expedia, YouGov
complex development processes and low productivity.
• Single view (of customer, of city): Barclays, City of
• Primitive Dat
Data
a Handling
Handling: Presenting JSON data as
Chicago
simple strings and numbers rather than the rich data

11
• IoT and time-series data: Bosch, Mercedes-Benz You should also register for the MongoDB University which
provides no-cost, web-based training on the basics of
• Trading and payments: HSBC, Coinbase
MongoDB, and provides a curated learning path for
• Ecommerce: Cisco, OTTO developers covering data modeling through to building your
• Product catalogs and content management: eBay, first application using the most popular programming
Adobe languages.

• Gaming: Sega, EA

• Mobile Apps: 7-Eleven, ADP We Can Help

• Mainframe Offload: Alight Solutions, formerly Aon
Hewitt, LCL
We are the company that builds and runs MongoDB. Over
• Online Analytics and AI: KPMG, Continental AG 18,400 organizations rely on our commercial products. We
offer cloud services and software to make your life easier:
You can learn more about use cases that are a good fit for
MongoDB, and those where you should evaluate MongoDB Atlas is the global cloud database service for
alternative solutions from our Use Case Guide. modern applications. Deploy fully managed MongoDB
across AWS, Azure, or Google Cloud with best-in-class
automation and proven practices that guarantee availability,
Summary scalability, and compliance with security standards.

MongoDB Enterprise Advanced is the best way to run

The use of document databases such as MongoDB has MongoDB on your own infrastructure. It's a finely-tuned
exploded over the past decade, supporting a range of package of advanced software, support, certifications, and
transactional, operational, and analytical workloads. other services designed for the way you do business.

The document data model is intuitive, flexible, universal, MongoDB Atlas Data Lake allows you to quickly and easily
and powerful, enabling developers to build applications query data in any format on Amazon S3 using the
faster, and scale them further than traditional relational MongoDB Query Language and tools. You don’t have to
databases. This is why MongoDB has been rated as the move data anywhere, you can work with complex data
database developers most want to work with in the Stack immediately in its native form, and with its fully-managed,
Overflow Developer Survey for the past four years. serverless architecture, you control costs and remove the
operational burden.
As most technologies in use today have moved on from the
designs of the 1970s and 80s, it’s about time your MongoDB Charts is the best way to create, share and
databases did as well. This is why documents represent the embed visualizations of MongoDB data. Build visualizations
largest advance in database design in a generation. quickly and easily to analyze complex, nested data. Embed
individual charts into any web application or assemble them
Getting Started into live dashboards for sharing.

The best way to explore the power of the document model Realm Mobile Database allows developers to store data
is to spin up MongoDB on the fully-managed Atlas cloud locally on iOS and Android devices using a rich data model
service. Our documentation steps you through how to that’s intuitive to them. Combined with the MongoDB
create a free MongoDB database cluster in the region and Realm sync-to-Atlas, Realm makes it simple to build
on the cloud provider of your choice. It includes steps on reactive, reliable apps that work even when users are
how to load our pre-prepared sample datasets, providing offline.
you with a simple way of getting started with documents.
MongoDB Realm allows developers to validate and build
key features quickly. Application development services like
Realm Sync for mobile and Realm’s GraphQL service, can

12
be used with Realm Functions, Triggers, and Data Access
Rules – simplifying the code required to build secure and
performant apps.

MongoDB Cloud Manager is a cloud-based tool that helps

you manage MongoDB on your own infrastructure. With
automated provisioning, fine-grained monitoring, and
continuous backups, you get a full management suite that
reduces operational overhead, while maintaining full control
over your databases.

MongoDB Consulting packages get you to production

faster, help you tune performance in production, help you
scale, and free you up to focus on your next release.

MongoDB Training helps you become a MongoDB expert,

from design to operating mission-critical systems at scale.
Whether you're a developer, DBA, or architect, we can
make you better at MongoDB.

Resources

For more information, please visit mongodb.com or contact

us at [email protected].

Case Studies (mongodb.com/customers)

Presentations (mongodb.com/presentations)
Free Online Training (university.mongodb.com)
Webinars and Events (mongodb.com/events)
Documentation (docs.mongodb.com)
MongoDB Atlas database as a service for MongoDB
(mongodb.com/cloud)
MongoDB Enterprise Download (mongodb.com/download)
MongoDB Realm (mongodb.com/realm)

US 866-237-8815 • INTL +1-650-440-4474 • [email protected]

© 2020 MongoDB, Inc. All rights reserved.

13