The ease of operation. It's so easy to scale it up and down. And it delivers predictable performance, as promised.
We are using DynamoDB in two projects now. One for storing large amounts of file metadata, and one for storing small amounts of session data. The fact that it is so easy to create tables and provision for known throughput saved us a lot of time, especially because we are deploying multiple environments and multiple regions.
DynamoDB doesn't provide server-side encryption, so we had to do it manually.
Any replication to other regions requires writing code. It's not so bad, but would be better to get a solution out of the box.
We store some protected patient information in DynamoDB, and in order to keep it HIPAA-compliant, we have to encrypt it at rest. Some services such as S3, Redshift and SQS will do the encryption on the server side, but with DynamoDB, the client application had to do the encryption before writing to the DB, and has to decrypt when reading. This means that we need to manage encryption keys: we need to store then securely and rotate them periodically, which is extra coding and complexity.
As for cross-region replication, AWS offers a way to do this using DynamoDB streams and Lambda, whereas other databases such as postgresql enable to configure replication without coding.
I have used it for one year.
We have not encountered any deployment issues. It's straightforward.
We have not encountered any stability issues, but you should expect to get exceptions when you exceed the provisioned throughput. This is okay and it is by design. You need to handle it by retries with exponential backoff.
We have not encountered any scalability issues.
We used PostgreSQL. We switched to DynamoDB for the scalability and ease of deployment and operation.
Initial setup was straightforward.
An in-house team implemented it.
No time wasted on provisioning databases.
Pricing depends on volume and provisioned throughput. When low, the price is extremely low. But for really large amounts of data, it can be expensive. Make sure you keep there only data you really need available fast.
We evaluated Cassandra but chose to abandon it because it was harder to configure correctly and scale.