www.pluralsight.com
Why Amazon DynamoDB Isn't for Everyone
Excerpt
So when you combine inexperienced devs, the lack of a clear plan for how to model a dataset in DynamoDB, and a managed database service that makes it really easy to ingest a lot of unstructured data — you can end up with a solution that spirals out of control even at a small scale. Lynn Langit, a cloud data consultant with experience in all three of the big public clouds, has seen enough of these botched implementations to be justifiably wary of businesses relying on NoSQL solutions like DynamoDB. … ### The Second Law of DynamoDB: At massive scale, DynamoDB’s usability is limited by its own simplicity. This is not a problem with the *architecture of Dynamo.* It’s a problem with what AWS has chosen to expose through the *service of DynamoDB*. At this point, we haven’t even touched on the issue of backups and restores — something DynamoDB doesn’t support natively and which gets awfully tricky at scale. The inability to back up 100TB of DynamoDB data was apparently a big reason why Timehop recently moved off the service altogether.
Related Pain Points
Backup and restore limitations at scale
9DynamoDB does not support native backup and restore functionality, which becomes extremely problematic at scale. Unable to back up large datasets (e.g., 100TB) was a significant reason why companies like Timehop migrated away from DynamoDB.
Rigid schema and access pattern design required upfront
7DynamoDB forces developers to decide partition and sort keys and design access patterns before product requirements crystallize. Changing queries later requires backfilling GSIs, schema migrations, and complex denormalized projections, whereas traditional databases allow simple index additions.