Amazon DynamoDB

DynamoDB partitions are limited to approximately 3,000 read capacity units and 1,000 write capacity units per second. When a single partition key receives excessive traffic ("hot key"), it can throttle and cause performance degradation. This is a hard limit that cannot be easily worked around and affects applications with uneven data access patterns.

DynamoDB is AWS-only with no support for multi-cloud or on-premises deployments. Its architecture doesn't translate easily to other databases, making migration off DynamoDB expensive and time-consuming. Organizations needing cloud provider independence or data sovereignty cannot use DynamoDB.

Loading large datasets into DynamoDB is cost-prohibitive and time-consuming. While DynamoDB excels at steady read/write operations of small, randomly distributed documents, bulk loading or batch operations can become economically unfeasible, making it unsuitable for analytical workloads or initial data migration.

Working with DynamoDB locally is not straightforward. Unlike traditional databases, it cannot simply be run in a Docker container, forcing developers to use remote development environments deployed to AWS. This prevents offline work and requires deployment cycles even for configuration changes.

DynamoDB provides limited built-in visibility into table usage, access patterns, and cost drivers. Developers must integrate external monitoring tools like CloudWatch, Prometheus, or DataDog to understand performance issues. Issues like hot partitions and throttling aren't automatically resolved, requiring developer expertise to diagnose.

DynamoDB latencies range from under 10 milliseconds to tens of milliseconds and can spike significantly under heavy load or during throttling. Cross-region replication adds additional latency. Applications requiring consistent sub-5ms or sub-1ms latency must use alternative solutions.