DynamoDB vs MongoDB vs Cassandra - Performance Comparison
Start learning this pattern below
Jump into concepts and practice - no test required
When working with databases like DynamoDB, MongoDB, and Cassandra, it's important to understand how their operations scale as data grows.
We want to know how the time to perform common tasks changes when the amount of data increases.
Analyze the time complexity of a simple read operation in DynamoDB.
const params = {
TableName: "Users",
Key: { "UserId": "123" }
};
const result = await dynamodb.get(params).promise();
This code fetches a single item by its primary key from a DynamoDB table.
Look for loops or repeated work inside the operation.
- Primary operation: Single key lookup in a distributed hash table.
- How many times: Exactly once per request, no loops over data.
As the number of items in the table grows, the time to get one item stays about the same.
| Input Size (n) | Approx. Operations |
|---|---|
| 10 | 1 lookup |
| 100 | 1 lookup |
| 1000 | 1 lookup |
Pattern observation: The time does not increase with more data because the lookup uses a key directly.
Time Complexity: O(1)
This means the time to get an item by key stays constant no matter how big the table is.
[X] Wrong: "Getting an item by key takes longer as the table grows because there are more items to search."
[OK] Correct: DynamoDB uses a hash-based index, so it goes directly to the item without scanning the whole table.
Understanding how different databases handle data lookup helps you choose the right tool and explain your choices clearly in conversations.
What if we changed the query to scan the entire table instead of using a key? How would the time complexity change?
Practice
Solution
Step 1: Understand DynamoDB's core feature
DynamoDB is designed for simple key-value access and automatic scaling.Step 2: Compare with other databases
MongoDB focuses on flexible document storage, Cassandra on high availability for huge data.Final Answer:
DynamoDB -> Option BQuick Check:
Automatic scaling + key-value = DynamoDB [OK]
- Confusing MongoDB's flexible documents with key-value simplicity
- Thinking Cassandra automatically scales like DynamoDB
- Choosing MySQL which is relational, not key-value
Solution
Step 1: Identify MongoDB's data model
MongoDB stores data as flexible JSON-like documents allowing rich queries.Step 2: Eliminate other options
Column-family store describes Cassandra, key-value with fixed schema fits DynamoDB less, relational tables fit SQL databases.Final Answer:
Flexible document storage with rich queries -> Option CQuick Check:
MongoDB = flexible documents + rich queries [OK]
- Confusing MongoDB with Cassandra's column-family model
- Thinking MongoDB uses fixed schema like relational DB
- Mixing key-value with document storage
Solution
Step 1: Analyze requirements for high availability and multi-datacenter writes
Cassandra is designed for huge data with high availability and multi-region replication.Step 2: Compare other options
MongoDB supports replication but less optimized for huge scale multi-datacenter writes; DynamoDB is scalable but less focused on multi-datacenter writes; SQLite is local and not distributed.Final Answer:
Cassandra -> Option DQuick Check:
High availability + multi-datacenter = Cassandra [OK]
- Choosing DynamoDB for multi-datacenter writes
- Confusing SQLite as distributed database
- Assuming MongoDB handles huge multi-region writes best
Solution
Step 1: Understand query capabilities of DynamoDB
DynamoDB supports key-value and simple queries but not rich flexible document queries like MongoDB.Step 2: Eliminate incorrect causes
DynamoDB does not use SQL syntax, is not column-family, and is not relational.Final Answer:
DynamoDB does not support flexible document queries like MongoDB -> Option AQuick Check:
DynamoDB lacks MongoDB's flexible queries [OK]
- Assuming DynamoDB uses SQL syntax
- Confusing data models between MongoDB and Cassandra
- Thinking DynamoDB supports relational tables
Solution
Step 1: Identify features needed
The app needs flexible JSON documents, automatic scaling, and global availability.Step 2: Match features to databases
DynamoDB supports JSON documents, automatic scaling, and global tables for availability. MongoDB supports JSON but global availability requires extra setup and scaling is manual. Cassandra lacks native JSON support and SQLite is local only.Final Answer:
Use DynamoDB with JSON support and global tables -> Option AQuick Check:
JSON + auto scale + global = DynamoDB [OK]
- Choosing MongoDB without considering scaling complexity
- Ignoring Cassandra's lack of JSON support
- Selecting SQLite which is not distributed
