Stop 08 · Serverless & Event-Driven ArchitectureTopics · 7/9

Serverless Databases (DynamoDB On-Demand)

In short

A Lambda that scales from zero to thousands is wasted if your database sits on one fixed-size server. On-demand databases scale and bill per request too, so the whole stack moves together.

Database options that scale automatically with usage and charge based on actual read/write activity rather than provisioned capacity — pairing naturally with serverless compute for fully consumption-based architectures.

The blob character collects a stack of copies from a photocopy machine at a shop counter.

Think of it like this

The college photocopy shop

You don't buy a photocopier for your notes. You pay per page at the shop by the gate. The night before exams, the queue is long but the shop just runs more machines. On-demand capacity is paying per page.

Watch it happen

Reads and writes, billed per request

Lambda

DynamoDB

Bill meter

PutItem order#7

1/6A write. No capacity was reserved; the table simply accepts it.

The big ideas

What you need to know

Two billing modes

On-demand bills per request. Provisioned means you set read and write capacity, cheaper for steady, predictable load.

Design for keys

Serverless doesn't fix bad keys. Pick partition keys with many distinct values so load spreads out.

No connection pool

DynamoDB is an HTTPS API, so thousands of functions don't exhaust connections like they can with Postgres.

Other options

Aurora Serverless v2, Firestore and Cosmos DB serverless also scale with use, each with its own trade-offs.

See it in code

Walk through the code

bash

1aws dynamodb create-table \2  --table-name Orders \3  --attribute-definitions AttributeName=userId,AttributeType=S \4                          AttributeName=orderId,AttributeType=S \5  --key-schema AttributeName=userId,KeyType=HASH \6               AttributeName=orderId,KeyType=RANGE \7  --billing-mode PAY_PER_REQUEST

1/3Declare only the key attributes. Other fields are free-form per item.

PAY_PER_REQUEST is on-demand mode. No --provisioned-throughput needed.

Save yourself the pain

Common mistakes

Oops

Running a big Scan from a Lambda on every request.

Do this instead

Scans read the whole table and bill for all of it. Query by key or add a secondary index.

Oops

Picking on-demand forever for a table with flat, high traffic.

Do this instead

Review the bill. Steady load is often cheaper on provisioned capacity with auto scaling.

Your mission

Pay-per-page table

~25 min

Quick check

Why does DynamoDB pair well with Lambda compared to a classic relational database?

Go deeper

1Create a DynamoDB table (or equivalent) in on-demand mode and perform basic operations.
2Learn the difference between on-demand and provisioned capacity pricing models.
3Understand why this pairing (serverless compute + serverless database) minimizes idle-resource cost.