So far we have talked about relational databases (tables, rows, columns, SQL). But there is another big world: NoSQL databases. The most important one in AWS is DynamoDB. Understanding what it is and when to use it gives you a powerful tool for cases where relational databases don’t fit well.

Remember: a relational database (like RDS) organizes data in tables with a fixed schema (defined columns) and relates them to each other. It’s great when data has a clear and consistent structure.

A NoSQL database (like DynamoDB) is more flexible: it doesn’t require a rigid schema and is designed to scale to enormous amounts of data and requests with consistent speed.

Analogy:

• A relational database is like a perfectly organized filing cabinet with labeled folders: everything has its exact place and relationships are well defined. Ideal for order and complex queries.
• A key-value NoSQL database is like a huge locker room: you give a locker number (the key) and get what’s inside (the value), instantly, no matter how many lockers there are. Super fast for “give me this specific thing,” but not for “find me everything that meets these five conditions.”

DynamoDB is AWS’s fully managed NoSQL database. Its distinctive features:

• Key-value and document model: you store items identified by a key, and each item can contain flexible data (JSON-like documents).
• Fully managed and serverless: there are no servers to manage at all. You don’t choose instance size or patch anything. You just create a table and use it.
• Consistent performance at any scale: responds in milliseconds whether you have a thousand items or billions.
• Virtually infinite scale: handles millions of requests per second effortlessly.

Why it’s so special: DynamoDB was designed to solve the scaling problems of Amazon.com (e-commerce). When millions of people shop at once on Black Friday, you need a database that doesn’t slow down no matter how much load it has. DynamoDB is that database.

• Table: the container for your data (like a table, but without a rigid schema).
• Item: each record (equivalent to a row).
• Attributes: the fields of each item (they can vary between items: one can have fields that another does not).
• Partition key: the main key by which each item is identified and located. Choosing it well is the most important part of the design.

DynamoDB shines when you need:

• Massive scale and consistent performance: millions of users, huge spikes, millisecond latency.
• Access by known key: “give me user user#123,” “give me the cart for customer X.” Direct and fast lookups.
• Flexible structure: data that doesn’t fit a fixed schema or changes frequently.
• Zero administration: you don’t want to manage anything about the database.

Real-world examples ideal for DynamoDB:

• Shopping carts for an e-commerce site (access by user id, huge scale).
• Player profiles in a video game with millions of users.
• Sessions for app users.
• Catalogs of products with variable attributes.
• IoT: data from millions of sensors constantly sending information.

DynamoDB is not the answer for everything. Avoid it when:

• You need complex queries with many conditions, joins between tables, and rich relationships → for that, a relational database (RDS/Aurora).
• Your data has many relationships between them that you query in various ways.
• Your application is small and the relational model feels more natural to you.

Mental rule: If your queries are like “give me this specific item by its key” at large scale → DynamoDB. If they’re like “give me all orders from customers in Madrid who bought in March and spent more than €100” → relational database (SQL).

• DynamoDB Streams: emits an “event” every time something changes in the table. Used to trigger automatic actions (we’ll see this with Lambda in Chapter 14 and in event-driven architectures in Chapter 28).
• On-demand vs provisioned: you can pay for actual usage (on-demand) or reserve capacity. On-demand is great for unpredictable workloads.
• DAX: an in-memory cache for DynamoDB that makes it even faster (microseconds).
• Global tables: replicas in multiple regions for users all over the world.

• DynamoDB is AWS’s NoSQL database, fully managed and serverless (zero administration).
• Uses a flexible key-value / document model and offers consistent millisecond performance at any scale.
• It’s ideal for massive scale and known-key access (carts, profiles, sessions, IoT…), with flexible structure.
• It’s not good for complex queries, relationships, and joins: for that use a relational database (RDS/Aurora).
• Mental rule: “give me this item by its key” → DynamoDB; “find me everything that meets several conditions” → SQL.

In the next subchapter we’ll look at ElastiCache, for storing data in memory and speeding up your applications.