DynamoDB VS MongoDB: Detailed Comparison

In this post we will try to see what are the main differences between two databases, DynamoDB and MongoDB, although it is not proper to say something like “DynamoDB VS MongoDB” and there is no point in comparing these two databases because the power of any database depends on its use case, both of these are excellent in what they are supposed to do and where they are supposed to be used.

But still, for the sake of it, we will look into the differences between these two databases on the basis of parameters like how data gets stored, security, querying and filtering, scaling, and pricing.

What is DynamoDB?

It is a Serverless technology offered by AWS (Amazon Web Services) which is managed by AWS itself, when using DynamoDB users don’t have to worry about things like scaling, automated backups, maintenance, and security because all these things are automatically managed by AWS.

It is designed to handle millions of requests because we can scale throughput capacity to handle as many requests as we want, it is also cost-effective because we are only paying for what we are using (more on this later).

What is MongoDB?

It is an open-source database by MongoDB, Inc, MongoDB is a no-SQL database that stores data as BSON objects, which look exactly like JSON objects. As this is an open-source database we can install it on any c server we want and the main advantage of using MongoDB is we can set up the infrastructure according to our requirements.

Although MongoDB is not a SQL relational database we can achieve different relations like one-one, one-many, etc in MongoDB using different methods like Refs and Embedded data, It provides us a way to write complex queries and fetch nested data with filters using Aggregations.

Storing data

MongoDB stores data in a JSON-like format called BSON, a default property named _id gets created for every object which is used as a primary key to uniquely identify each object from the other. Each object is called a document and a collection of documents is called a collection. Generally, it is a good practice to define a schema for each collection but there is no strict rule to define the schema, which means we can add/remove fields on the go.

DynamoDB stores data differently than MongoDB database, items get stored in a DynamoDB table and each row in a table is uniquely identified with a primary key called partition key, DynamoDB doesn’t generate this key automatically like MongoDB, the user has to dynamically store this key while inserting a new row to the table. It also uses another key called the sort key which is generally used when there are multiple items with the same partition key.

Security

In the case of DynamoDB data security is managed by AWS, data from DynamoDB gets stored in multiple physical locations which are called regions and availability zones which are highly secured and redundancy of data is made sure by storing it in different places.

AWS also encrypts the data which gets stored in DynamoDB, we can also implement our own encryption using services like AWS KMS (Key management service). Data also get protected using DAX (DynamoDB Accelerator) which helps to prevent unauthorized access to the database, so overall there is a great deal of built-in security which is offered by DynamoDB and the user has to worry less about doing all the things related to security by themselves.

On the other side in the case of MongoDB, it doesn’t offer as much as DynamoDB right off the bat, because it is kind of a self-managed service. User has all the flexibility to take different security measures like access control, role-based user access, using SSL/TLS for secured connections and data transfer, limiting the access to the database by changing the MongoDB configuration, Auditing, and logging operations to the database.

All these things are required to be done by the user if we are not using any managed service like Atlas Cloud or AWS DocumentDB, it provides their users the flexibility to set the infrastructure as they like and according to their requirements.

Querying and filtering

DynamoDB allows us to query the data according to the partition key and sort key, it also enables users to scan the whole table but scan operations in DynamoDB can be costly so we should try not to scan tables very often.

We could say that DynamoDB lacks when it comes to complex queries and filters by joining data from multiple tables as we do in the case of SQL databases, although there are different ways to achieve cross-table data querying and filtering but these operations can be costly.

In the case of MongoDB querying and filtering can be very detailed and it also supports searching through the data from different collections simultaneously and allowing users to create relations between collections in a very natural way by using Refs, in this approach, we store the primary key from one collection to another collection as a foreign key which allows us to get the data from both tables.

Filtering can be achieved using MongoDB aggregations which can be used to write very detailed and complex queries, this is a great feature given in MongoDB which allows cross-collection data search.

Scaling

When we talk about DynamoDB scaling it is one of the main advantages of using DynamoDB, auto scaling is available in DynamoDB, it allows us to handle unexpected spikes or drops in traffic, provisioned throughput capacity units are used for read and write operations in DynamoDB.

We can enable automatic provisioning to allow AWS to adjust these units without us having to manually manage it, for example in case of more traffic it will add more units and in case of drops in traffic, it will reduce the number of units so we don’t pay extra. This feature makes DynamoDB one of the databases which can scale up to millions of requests without having to worry about adding more servers manually.

This is especially useful when we don’t have any good idea about our application’s traffic patterns, meaning sometimes it is high and sometimes it is low.

In the case of MongoDB , Sharding and Replica sets are used for scaling the database, now if we are not using Atlas Cloud for our MongoDB instance then we will need to manage the scaling part ourselves either by adding some kind of horizontal or vertical scaling solution to the servers which is very not a very efficient way to scale any database.

But if we are using Atlas Cloud for hosting our MongoDB instance then auto scaling is available for us, both vertical and horizontal scaling is supported. We have an option of using shared clusters where we can specify the number of shards for our MongoDB instance.

The other method to scale while using MongoDB Atlas is cluster auto scaling, where we can define a maximum and minimum range for each cluster size. CPU and memory utilization are used as a parameter to take the scaling decision meaning whether to scale up or down.

Pricing

If we talk about DynamoDB pricing it is a bit complex (at least for me XD) so let’s try to understand it, there are two types of pricing models that DynamoDB uses.

On-Demand Pricing, which means AWS charges us on the basis of the number of requests of reads and writes done on your DynamoDB table, we don’t need to specify the number of capacity units, AWS automatically scales up or down our table units according to the number of requests.

In the case of Provisioned Capacity Mode pricing, we need to specify the number of RCU and WCU for our DynamoDB table, this type of scaling is best if we know how many resources we will need.

Reading data — Billing for read operations is done according to the number of reading units used to read the data from the DynamoDB table, there are three types of reads done on a DynamoDB table, strongly consistent, eventually consistent, and transactional. 1 RCU (Read Capacity Unit) gets used for reading data up to 4KB, data that is more than 4KB requires 2 RCU, eventually consistent reads require half RCU and transactional reads require double RCU in comparison to strongly consistent reads.

Writing data — Billing for write operations are done according to the number of write units used to write the data to the DynampoDB table, there are two types of writes one is standard write and another is transactional write. 1 WCU is used to write the data up to 1KB, transactional writes require a double number of WCU to write the same size of data.

Now let’s see MongoDB pricing model, If we are using custom MongoDB server instances then pricing depends on the pricing of the server being used, in the case of MongoDB Atlas there are different plans that one can buy according to the requirement, if we get the Serverless package then we only pay for what we use.

Conclusion

Both databases are on top of the list of industry grade databases, there is no need to say that one is better than the other one, it all depends on the use case, there are a lot of use cases that determine which database to use.

For example, if we want a database where we need a way to interact with other AWS services (as DynamoDB has a feature called streams) or if we want to automatically scale the database then DynamoDB might be a better choice, on the other hand, if we need to write complex queries and do nested filtering with complex database relations then MongoDB might be a better choice.

Do leave your feedback in the comment section, and follow me for more content like this.