Amazon DynamoDB is the serverless NoSQL database from AWS: a distributed, fully managed store designed to respond in single-digit milliseconds at any scale. It supports both key-value and document data models, and it is built for the operational workloads that carry an application day to day.
Put simply: it is the database you choose when the business needs the response to be just as fast with ten thousand users as with ten million, and without a dedicated team operating database servers.
What problem does DynamoDB solve?
Many applications grow to a point where the database stops keeping up. Traffic becomes hard to predict, campaigns generate spikes that last a few hours, and sustaining performance demands sizing servers, planning maintenance windows and anticipating how much capacity the next quarter will require.
DynamoDB was built precisely to leave that conversation behind. AWS handles setup, maintenance, high availability, hardware provisioning, security and backups. There are no major or minor versions to upgrade and no maintenance windows to coordinate: the table is production-ready the moment you create it.
For the business that translates into two concrete things. The first is predictability: response time stays stable even as volume multiplies. The second is that the technical team spends its time on the product rather than on sustaining infrastructure.
How does DynamoDB work?
Three design decisions explain its behavior:
- Genuinely serverless: there are no servers to provision, patch or manage. DynamoDB offers two capacity modes. In on-demand mode, capacity adjusts instantly to traffic and scales down to zero when the table receives no requests, with no cold starts; in provisioned mode the team defines read and write capacity up front, which fits workloads that are steady and predictable.
- A NoSQL model organized around access patterns: DynamoDB does not support the JOIN operation. The AWS recommendation is to denormalize the model to reduce database round trips and the processing needed to answer queries. Design starts from the questions the application will ask, not from the theoretical structure of the data.
- Native distribution: data is replicated by default across three Availability Zones, which sustains durability and availability with no extra work from the team.
That combination is what keeps performance consistent as the table grows: there is no practical limit on the size of a table, either in number of items or in bytes.
Capabilities that usually settle the conversation
| Capability | What it solves |
|---|---|
| Global tables | Multi-active cross-Region replication, with no primary table and no failover to run |
| ACID transactions | Coordinated all-or-nothing changes across one or more items, within or across tables |
| DynamoDB Streams | A time-ordered record of every change, for event-driven architectures |
| Secondary indexes | Queries on attributes other than the primary key, with local and global indexes |
| Point-in-time recovery | Restore with per-second granularity within a configurable window of 1 to 35 days |
| DynamoDB Accelerator (DAX) | Managed in-memory cache that takes responses from milliseconds to microseconds |
On indexes it helps to keep the order of magnitude in mind: you can define up to 5 local secondary indexes per table, and the default quota is 20 global secondary indexes per table.
How DynamoDB fits into an AWS architecture
DynamoDB rarely works in isolation. It is the operational data layer of modern applications, and it connects natively with the rest of the ecosystem:
- AWS Lambda: lets you create triggers that automatically run code on every change recorded in DynamoDB Streams. This is the foundation of event-driven architectures.
- Amazon API Gateway and AWS AppSync: expose the data as REST or GraphQL APIs with no intermediate servers to operate. We cover this in our guide to REST versus GraphQL.
- Amazon S3: full or incremental table imports and exports, for analytics and machine learning.
- Zero-ETL integration with Amazon Redshift and Amazon OpenSearch Service: lets you run complex analytics and advanced search over table data, with no impact on production workloads.
That last point deserves attention: zero-ETL integration avoids building and maintaining the ETL pipelines that were traditionally required to move operational data into the analytical warehouse.
Security and compliance
DynamoDB encrypts all data at rest by default, with keys managed in AWS Key Management Service. Access is controlled through AWS Identity and Access Management, which removes database-specific usernames and passwords and with them the associated rotation policies. IAM also enables fine-grained access control at the attribute level.
On compliance, DynamoDB adheres to standards including HIPAA, PCI DSS and GDPR, a relevant point for financial services and healthcare organizations operating under regulatory requirements.
DynamoDB or a relational database?
This is the question that comes up most, and the honest answer is that it is not either/or. Most mature architectures combine both: a relational database for the transactional core with many relationships, and DynamoDB for catalogs, sessions, profiles and high-volume events.
The practical reading is this. When access patterns are known and the requirement is consistent latency at scale, DynamoDB fits. When queries are exploratory, changing and rely on traversing relationships, a relational database is the better fit — the kind you run on Amazon RDS or Amazon Aurora. If you want to go deeper on the relational side, review our comparison of PostgreSQL and MySQL.
DynamoDB within a data strategy
Adopting DynamoDB is an architecture decision, not a tool choice. It performs when the data model is designed around the application’s real access patterns, and it disappoints when treated as a relational database without a schema. That difference is settled in design, before the first line of code.
At Caleidos we design and implement these architectures within our cloud-native applications and Data Engineering on AWS practices, and we sustain them with Caleidos Lens©, our 24×7 service desk. You can see how we apply it in our success stories.
Frequently asked questions
What is DynamoDB in simple terms? The serverless NoSQL database from AWS: fully managed, distributed, and responding in single-digit milliseconds at any scale.
Does it replace a relational database? Not necessarily. It fits when access patterns are known and the requirement is scale with consistent latency; relational remains better for exploratory queries and models with many relationships.
How does it recover from an incident? With continuous backups that restore to any second within a configurable window of 1 to 35 days, on-demand backups for long retention, and global tables for multi-Region resilience.
Evaluating DynamoDB for your application?
Let’s talk about your case and we will give you a concrete reading on whether your workload fits better in DynamoDB, in a relational database, or in an architecture that combines both.
