I have a new chart I've been showing in my DynamoDB training and talks recently.
It's about DynamoDB performance, and there are two key points I want folks to understand:
1. DynamoDB is fast (not blazing fast! but definitely not slow)
2. DynamoDB perf is consistent
(cont.)
It's about DynamoDB performance, and there are two key points I want folks to understand:
1. DynamoDB is fast (not blazing fast! but definitely not slow)
2. DynamoDB perf is consistent
(cont.)
Point 1: 'DynamoDB is fast.'
You'll get single-digit response times (at the server) from DynamoDB.
This is nice! Your users will appreciate that.
(cont.)
You'll get single-digit response times (at the server) from DynamoDB.
This is nice! Your users will appreciate that.
(cont.)
Note that DynamoDB is not 'blazing fast'. You *can* get better response times from other databases if you're not straining them.
However, the different between 'blazing fast' and 'fast' is probably not meaningful unless you have a deep call chain in a single request.
(cont.)
However, the different between 'blazing fast' and 'fast' is probably not meaningful unless you have a deep call chain in a single request.
(cont.)
Point 2: 'DynamoDB perf is consistent.'
DynamoDB is going to perform the same at 1GB and 10GB as at 1TB and 10TB. It will perform the same in your dev environment as in production.
This is important and underrated.
(cont.)
DynamoDB is going to perform the same at 1GB and 10GB as at 1TB and 10TB. It will perform the same in your dev environment as in production.
This is important and underrated.
(cont.)
With other databases, your experience looks as below:
Day 1: Our app is so fast in dev / in beta!
Six months later: 'Hmm, can someone see why our app feels sluggish now?'
1 year later: 'What if we remove/rearchitect $FEATURE so we can reduce load on database?
(cont.)
Day 1: Our app is so fast in dev / in beta!
Six months later: 'Hmm, can someone see why our app feels sluggish now?'
1 year later: 'What if we remove/rearchitect $FEATURE so we can reduce load on database?
(cont.)
There are lots of hidden footguns with other databases that work well at low volumes but will cost an arm and a leg if you scale:
- Aggregations
- Full-text search
- Complex filters
- Joins across many tables
Super easy to add in dev, but they're ticking time bombs.
(cont.)
- Aggregations
- Full-text search
- Complex filters
- Joins across many tables
Super easy to add in dev, but they're ticking time bombs.
(cont.)
DynamoDB won't let you do things that won't scale (alexdebrie.com/posts/dynamodb…).
This feels restrictive! Particularly when you're starting the application.
- "Why can't I filter on anything in a query?"
- "Why can't I find the sum of an attribute across multiple items?"
(cont.)
This feels restrictive! Particularly when you're starting the application.
- "Why can't I filter on anything in a query?"
- "Why can't I find the sum of an attribute across multiple items?"
(cont.)
This is an intentional design philosophy by the DynamoDB team.
You don't need a PhD in database design to understand if your app will scale with DynamoDB. But you do need to learn the principles of DynamoDB upfront.
You don't need a PhD in database design to understand if your app will scale with DynamoDB. But you do need to learn the principles of DynamoDB upfront.
If you want to know more, hit me up about DynamoDB training or consulting. Or, get The DynamoDB Book:
dynamodbbook.com
/fin
dynamodbbook.com
/fin
