Skip to content

Only a single typo #106

New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

Sign up for GitHub

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Open
mcvendrell wants to merge 1 commit into
base: master
Choose a base branch
from
Open

Only a single typo #106

Changes from all commits
Commits
Show all changes
1 commit
Select commit
File filter

Filter by extension

Filter by extension
Conversations
Failed to load comments.
Loading
Jump to
Jump to file
Failed to load files.
Loading
Diff view
Diff view
4 changes: 2 additions & 2 deletions content/lessons/comparisons/mongodb.md
View file
Open in desktop
Original file line number Diff line number Diff line change
Expand Up @@ -70,7 +70,7 @@ Operationally, MongoDB uses a more traditional model for databases. You will ins

DynamoDB has a more radical model. Rather than thinking about instances, you only think about usage. You are not responsible for installing software, managing servers, or increasing your cluster size. You only tell AWS how much read and write capacity you want (or skip it altogether by using On-Demand Pricing). As your data usage needs grow, you simply increase the capacity you need.

AWS will completely handle the instances in their DynamoDB fleet, so you don't need to think about instance failure or degredation. You don't need to worry about backups. You don't need to worry about increasing your cluster size.
AWS will completely handle the instances in their DynamoDB fleet, so you don't need to think about instance failure or degradation. You don't need to worry about backups. You don't need to worry about increasing your cluster size.

There are more 'managed' MongoDB offerings in recent years, such as MongoDB Atlas or AWS DocumentDB (with MongoDB compatibility). These offerings help with the low-level aspects of running a database, but you are still bound to instance-based thinking. Scaling down is near impossible. Scaling up requires increase the size or number of instances and the associated migration. [Rick Houlihan](https://twitter.com/houlihan_rick) has shared stories of MongoDB customers that need to wait _nine months_ to add shards due to all the rebalancing of data that occurs.

Expand Down Expand Up @@ -100,4 +100,4 @@ In this post, we saw how DynamoDB compares to MongoDB. The major points are:
* DynamoDB has a more hands-off operations model than MongoDB as you don't think to think about instances and scaling up or down.
* At high scale, DynamoDB and MongoDB have very similar data modeling principles.
* At lower scale, MongoDB has a more flexible data model.
* DynamoDB's connection and security model make it a popular choice for use with serverless compute like AWS Lambda.
* DynamoDB's connection and security model make it a popular choice for use with serverless compute like AWS Lambda.