DynamoDB is Amazon’s fully managed, serverless, NoSQL database service. It’s built to deliver single-digit millisecond performance at any scale — from a side project with a few users to a global app with millions of requests per second. That’s a lot in a couple of sentences, so let’s break it down a bit:
Fully Managed & Serverless
Forget about provisioning infrastructure, patching, or maintenance windows. You simply create a table and start storing data.
NoSQL Flexibility
DynamoDB supports key-value and document data models. This schema-less design means that you can easily evolve your app over time.
Millisecond Latency
Consistently fast reads and writes — perfect for user-facing applications where speed matters.
Additional Benefits of DynamoDB
High Availability by Default
Your data is replicated across multiple data centers (availability zones) automatically.
Instantly Scalable
It automatically scales up and down to match your workload. You focus on building — DynamoDB handles the heavy lifting.
Secure by Design
Integration with AWS IAM lets you control who can read or write your data.
How is Data Stored?
You store your data in tables. Each table holds items (think rows), and each item has attributes (think columns). The benefit of NoSQL is that the attributes are flexible, meaning you can add or remove attributes later, making it more flexible for the future.
Primary Keys & Sort Keys
DynamoDB doesn’t do fancy SQL joins — instead, it’s all about key design. When you create a table, you define its Primary Key. There are two ways to do this:
- Simple Primary Key (Partition Key Only)
One attribute uniquely identifies each item — for example,UserID. - Composite Primary Key (Partition Key + Sort Key)
Here’s where it gets interesting. You combine a Partition Key (PK) with a Sort Key (SK). The PK decides which partition your data lives in, and the SK lets you store multiple related items under the same PK, sorted however you want.
Example:
Imagine an Orders table:
- Partition Key:
CustomerID - Sort Key:
OrderDate
One customer can place lots of orders — same PK (CustomerID), different SK (OrderDate). This makes it easy to pull up a customer’s order history sorted by time.
Capacity Options
DynamoDB gives you two ways to handle capacity that you must determine when you create your table.
- Provisioned Capacity: You set how much read and write throughput you want. Good for predictable workloads.
- On-Demand Capacity: DynamoDB automatically adjusts throughput as your traffic changes. Perfect for unpredictable spikes.
Supercharge with DAX
Got read-heavy workloads that need to be lightning fast? DynamoDB has DAX (DynamoDB Accelerator) — an in-memory cache that drops read latency to microseconds. It’s fully managed and works with your existing DynamoDB API calls. No big rewrites required because it uses the same interface as DynamoDB.
DynamoDB Streams
DynamoDB can do more than just store data — it can stream changes as they happen.
Turn on Streams, and you get a real-time feed of all inserts, updates, and deletes in your table. Hook this up to AWS Lambda or Kinesis, and boom — you have an event-driven architecture that reacts instantly when your data changes, like sending notifications when a profile is updated, syncing data to other services, or keeping audit logs
Go Global with Global Tables
If your users are all over the planet, DynamoDB’s Global Tables replicate your data across multiple AWS Regions automatically. Low latency, multi-region resilience, and active-active writes — no extra infrastructure needed.
Should You Use DynamoDB?
If you’re looking for a NoSQL database that has fast, consistent performance, easy to manage and highly available, DynamoDB is a great option.
If your data would require advanced queries or aggregated data, or you have records over 400KB (exceeds DynamoDB data limit), then you may need to stick to a relational DB.
Next Steps
In the next post, we will build our first DynamoDB table and deploy it using AWS CDK.
Until then, Happy Coding!
Breakpoint 