Purpose

Show (1) how DynamoDB wins when you know access patterns and (2) how Aurora DSQL wins when you need the database to compute relationships at runtime.

Through-line

• DynamoDB → The devil you know: Design-time composition for predictable performance
• Aurora DSQL → The devil you don’t: Runtime computation for flexible queries

Setup & Prereqs

Env Vars

• AWS_REGION=us-east-1 (or your region)
• DSQL_ENDPOINT=<your-dsql-endpoint-hostname> (no protocol)

Install deps

npm i @aws-sdk/client-dynamodb @aws-sdk/lib-dynamodb @aws-sdk/dsql-signer pg dotenv

Run

node scripts/demo.js   # or your entry file

The demo prints scenario headers, timings, and small summaries you can read aloud in Notion.

Warmup (Realistic Latency)

We warm both systems so the first “cold” call doesn’t skew your story.

// DynamoDB: tiny GSI query to prime connection and IAM
await dynamodb.send(new QueryCommand({
  TableName: TABLE_NAME,
  IndexName: 'StatusIndex',
  KeyConditionExpression: '#status = :status',
  ExpressionAttributeNames: { '#status': 'status' },
  ExpressionAttributeValues: { ':status': 'Bound' },
  Limit: 1
}));

// DSQL: trivial count to prime TLS + IAM token usage
await this.dsqlClient.query('SELECT COUNT(*) FROM soul_contracts LIMIT 1');

“We’re warming engines. Same as production—connections, TLS, IAM, caches.”