CAP Theorem and DynamoDB
In distributed systems, the CAP Theorem states that you can only guarantee two out of the following three at any given time:
- Consistency
- Availability
- Partition Tolerance
DynamoDB is designed as an AP (Availability + Partition Tolerance) system. This means it prioritizes high availability and resilience to network partitions.
- Consistency in DynamoDB is tunable:
- By default, reads are eventually consistent.
- For stronger consistency guarantees, strongly consistent reads can be enabled, which cost 2x RCU (Read Capacity Unit) compared to eventually consistent reads.
ACID vs BASE Models
- RDBMS follows the ACID model:
- Atomicity, Consistency, Isolation, Durability.
- Ensures strict consistency and transactional integrity.
- DynamoDB aligns more with the BASE model:
- Basically Available, Soft state, Eventual consistency.
- Allows for high availability and partition tolerance with tunable consistency.
SQL Relations vs DynamoDB Modeling
SQL databases use normalized schemas and foreign keys to maintain relationships:
- Tables like Orders, Customers, Products, and OrderStatus are linked using JOINs.
- Flexible, ad-hoc queries are supported.
DynamoDB follows a denormalized, single-table design, optimized for access patterns:
Design around how you query, not how data relates logically.
Example: E-commerce Order Table in DynamoDB
- A single table might contain:
- PK = CUSTOMER#<customerId>
- SK = ORDER#<orderId>
Related items such as customer profile, order status, and shipping details can be stored together to reduce the need for JOINs.
Using GSIs for Query Flexibility
DynamoDB allows flexible querying through Global Secondary Indexes (GSIs):
- GSI 1: PK = orderStatus → Query all shipped/pending orders.
- GSI 2: PK = customerId, SK = orderDate → Query customer orders sorted by date.
GSIs act like alternate views of your data, much like SQL indexes, but for NoSQL.
Schema Flexibility
- SQL: Schema is rigid and defined upfront. Changes often require migrations.
- DynamoDB: Schema is flexible and can evolve without table redesigns.
This makes DynamoDB ideal for iterative development or microservices where different items in the same table might have different attributes.
Latency, Scalability, and Serverless Nature
- DynamoDB provides:
- Predictable low-latency reads/writes at any scale.
- Seamless auto-scaling.
- Fully managed and serverless, integrating easily with AWS Lambda and other services.
When to Use SQL vs DynamoDB
Criteria | SQL (RDBMS) | DynamoDB (NoSQL) |
Schema | Fixed, normalized | Flexible, denormalized |
Joins | Native support | Not supported, model for access patterns |
Transactions | Full ACID | Limited transactions, BASE consistency |
Query Flexibility | Ad-hoc, complex | Access pattern–driven, GSIs needed |
Scale | Vertical (limited) | Horizontal, massive scale |
Latency | Varies with load | Low-latency at any scale |
Use Case | Financial apps, reporting, legacy apps | Real-time apps, IoT, gaming, serverless apps |
References and Further Reading
Summary
DynamoDB’s approach to scaling, availability, and flexible schema design makes it a compelling choice for modern cloud-native applications—especially when data access patterns are well-defined. While it lacks the relational integrity of SQL, thoughtful modeling using single-table design and GSIs can enable highly efficient, scalable applications without compromising performance.
