So you're at the point of your project where the discussion of SQL vs. NoSQL is old news, and NoSQL is the path forward.
Now you're in the market for the actual product you're going to use as your database. Since you're reading this article, you have probably narrowed it down to 2 contenders: DynamoDB and MongoDB.
Let's explore the details of each one of these products so you can make an informed decision.
Below I'm going to cover the following:
While DynamoDB and MongoDB aim to solve the same problem, store data in a NoSQL fashion, they approach that goal differently.
Let's look at the main differences between them that you need to be aware of to make the right choice for you or your business.
The first difference is infrastructure management.
MongoDB is an open source product, whereas DynamoDB is a service provided by Amazon via Amazon Web Services (AWS).
What this means in practice is that, when it comes to infrastructure management, you're looking at a completely different picture than you would from a development perspective.
While DynamoDB is only available as part of AWS, MongoDB can be deployed in the hosting environment of your choice. This is especially important if you're worried about vendor lock-in problems.
On the other hand, with DynamoDB you don't have to worry about provisioning, monitoring, and keeping servers running (not to mention making backups).
Because it's a fully managed system, getting things up and running with DynamoDB is a breeze, whereas MongoDB can be challenging to install and set up.
When it comes to security, DynamoDB offers much better features out-of-the-box. Being a part of AWS, the AWS Identity and Access Management (IAM) permission model applies to it, as it does with AWS services like EC2, RDS, and others.
In addition, DynamoDB is not accessible directly from the internet, which adds another layer of security on top of its particular configuration.
MongoDB also offers good security features, but not through its default settings. Meaning that to increase security, you need to tweak the configuration. Thus, MongoDB is not very secure right after the default implementation.
MongoDB stores its information in a JSON-like, schema-free format.
The main stored objects are called documents, which are grouped into collections.
In MongoDB you don't need to create a collection before inserting new documents into it, making it really fast to put to use.
A very quick example would be running the following code straight from the command line client:
db.users.insert( { 'name': 'John Doe' } )
This code would insert a new document into the "users collection" if available, or create it otherwise.
In the case of DynamoDB, its databases are structured in a very similar way to relational databases; you have tables that contain items which in turn have attributes. Although, not every item in a table must have the same number of attributes.
In order to use a table, you must first create it and define a primary key.
The same operation in DynamoDB would require using a specific SDK.
Let's look at a JavaScript example:
var AWS = require("aws-sdk");
AWS.config.update({
region: "REGION",
endpoint: "ENDPOINT"
});
var dynamodb = new AWS.DynamoDB();
var params = {
TableName : "Employees",
KeySchema: [
{ AttributeName: "name", KeyType: "HASH"},
],
AttributeDefinitions: [
{ AttributeName: "name", AttributeType: "S" }
],
ProvisionedThroughput: {
ReadCapacityUnits: 10,
WriteCapacityUnits: 10
}
};
dynamodb.createTable(params, function(err, data) {
if (err) {
console.error("Couldn't create table. Error:", JSON.stringify(err, null, 2));
} else {
console.log("Table created:", JSON.stringify(data, null, 2));
}
});
Another difference between DynamoDB and MongoDB is document size. DynamoDB will allow a maximum of just 400 KB, while MongoDB has a limit of 16 MB.
If you need to store big objects with DynamoDB, AWS recommends using another service, such as S3. Bear in mind that while this solution can work, it does so at the cost of reduced performance.
DynamoDB offers minimal query functionality; basically, it only allows key-value lookups. However, you can leverage complementary AWS services, such as Elastic MapReduce, to achieve aggregation and other sorts of more sophisticated queries.
MongoDB has its own query language, which allows developers to analyze data in a wide variety of ways (including limited joins, geospatial, and aggregations).
DynamoDB offers three allowable data types: number, string, and binary.
MongoDB has a more extensive set of data types, namely: int, long, date, timestamp, geospatial, floating-point, and decimal128. This makes sense given its more advanced querying capabilities.
DynamoDB only offers eventual data consistency which can lead to unnoticed data losses, while MongoDB offers strong data consistency.
When it comes to performance there are no big differences, assuming usage conditions across the two products are similar.
If you're going to be running many complex queries involving more than one table/collection, you'll most likely be better off using MongoDB since the exchange between DynamoDB and their satellite services will incur added latency.
DynamoDB can be more expensive; MongoDB will provide savings in terms of service fees.
But keep in mind, if you use Mongo DB, it will be up to your own infrastructure team to keep everything running smoothly (monitoring the services, scaling storage up and down, etc.). While that approach provides more fine-grained control, the cost of additional data team salaries can quickly surpass your AWS bill.
However, MongoDB also offers add-on support services, which may be a better (and cheaper) option than handling everything internally.
So far, you've learned the main differences between DynamoDB and MongoDB along with the advantages and disadvantages of each one. Now it's time to put that information to use and apply it to your particular situation.
If your business already relies on AWS services, then DynamoDB is probably the best option for you. It'll be easy to deploy, maintain, and integrate with your current infrastructure.
If, on the other hand, you're planning on putting together a multi-cloud infrastructure, then MongoDB is definitely the way to go.
Of course, you can find yourself in neither one of these scenarios, which calls for a more detailed analysis. Here are some things to consider:
First of all, you should assess the skill level of your team members and consider the following questions:
If you answer no to those questions, then you should give DynamoDB a deeper look.
Another option you might want to consider is MongoDB Atlas (a managed MongoDB service similar to DynamoDB).
Also, take into account how much speed your application needs and what you can sacrifice in terms of information consistency in order to get that speed. In other words, what's worse: a couple of seconds of delay to get the answer you need or less-than-trustworthy data?
Last but not least, you have to evaluate how complex your queries will be. If your application won't perform complex queries, you don't need MongoDB; you can do fine with DynamoDB.
Regardless of your choice between MongoDB and DynamoDB, if you want to do proper data analysis, you should consider trying Panoply.
With Panoply, you can power your BI tools and dashboards from different data sources (NoSQL databases, relational databases, Excel spreadsheets, etc...) with very little coding involved. Learn more with a personalized demo.