What is Amazon DynamoDB? A plain-English explainer
Amazon DynamoDB is a fully managed, serverless NoSQL database: it stores key-value and document data, scales automatically as demand changes, and returns results at low latency no matter how large the table grows. There is no database server to provision, patch or resize — you create a table, define how items are keyed, and DynamoDB handles the infrastructure and scaling behind it. That combination of “NoSQL” and “serverless” is what sets it apart from a service like Amazon RDS: DynamoDB is built for a different kind of workload, one where access patterns are simple and predictable but the scale or speed requirements are demanding. Here is what NoSQL means in practice, when DynamoDB is the right fit, and where it genuinely isn’t.
What “NoSQL, key-value and document” means
A relational database like RDS organises data into tables with fixed columns and relationships enforced between them, queried with SQL. DynamoDB works differently: each table stores items identified by a key, and each item can hold whatever attributes it needs without a fixed schema shared across every row. That is the key-value and document model — you look items up by their key, or by a small set of query patterns you designed the table around, rather than writing arbitrary joins across tables.
Our relational-vs-nosql-databases explainer covers this distinction in more depth — including why NoSQL trades some of the flexibility of SQL querying for scale and speed on the access patterns it is built for. DynamoDB is AWS’s primary example of that trade-off in action.
Fully managed and serverless
DynamoDB is serverless in the same sense as AWS Lambda: there is no database instance for you to size, patch or keep running. You create a table, and DynamoDB provisions and manages whatever infrastructure is needed to serve it, scaling automatically as your read and write traffic grows or shrinks. This removes an entire category of operational work that a self-managed or even a managed-but-instance-based database like RDS still carries — there is genuinely no server-level capacity planning to do.
That does not mean there are no limits at all — there is a limit to how a single item or request can be sized and shaped, and DynamoDB’s performance depends on designing your table and keys around how you will actually query the data. Check AWS’s DynamoDB documentation for the current specifics rather than treating any number as fixed; the design principles behind good key selection are the part worth learning properly.
When to use DynamoDB
DynamoDB suits applications with high-scale, predictable access patterns — looking up a user profile by user ID, retrieving a shopping cart by session, storing an event as it happens — where the query is almost always “give me the item(s) for this key”, rather than an open-ended report across many relationships. It is a common backend for serverless applications generally, because a Lambda function and a DynamoDB table both scale automatically with no server for either side to manage, making the whole application serverless end to end.
It is a weaker fit when your application genuinely needs complex, ad hoc queries across multiple related entities, multi-item transactions across very different data shapes, or reporting that was not anticipated when the table was designed — those are strengths of a relational database, not of DynamoDB’s access-pattern-first model.
DynamoDB is not a drop-in replacement for SQL
It is worth saying plainly: NoSQL suits specific access patterns, and DynamoDB is not simply “a database without the downsides of SQL”. Designing a DynamoDB table well means deciding upfront how the data will be queried and shaping the keys around that — a very different discipline from a relational schema, where you can largely defer query design and rely on joins later. Teams that treat DynamoDB like a relational database with different syntax tend to run into trouble once their access patterns grow beyond what the table was designed for.
How DynamoDB is priced
DynamoDB follows a pay-for-use model: broadly, you pay for the reads, writes and storage your tables actually consume, with options for how that capacity is managed, rather than paying for a database server’s uptime regardless of traffic. Specific pricing options and rates change over time, so this article does not quote them — AWS’s DynamoDB pricing page is the accurate source. The concept to take away is that, like Lambda, DynamoDB cost tracks actual usage rather than provisioned server capacity.
Where DynamoDB appears in certification study
DynamoDB is a strong focus on AWS Certified Developer – Associate, which tests designing tables and keys, and integrating DynamoDB into serverless applications, and it appears on AWS Certified Data Engineer – Associate as one of the NoSQL options in a broader data architecture. AWS Certified Solutions Architect – Associate tests when to choose DynamoDB over a relational database like RDS for a given architecture. Our /revision study library covers that syllabus depth lesson by lesson.
Original practice questions, timed mock exams and revision notes. No card, nothing to pay.