Lantern’s old server had one PostgreSQL database for everything: events, venues, organisers and every RSVP. During the festival spike, RSVP writes queued up behind a slow report query and the whole site stalled. On AWS you can give each kind of data the database that suits it. The two you will meet first are Amazon RDS and Amazon DynamoDB, and they differ in almost every way that matters.
\nAmazon Relational Database Service runs a relational engine on infrastructure AWS manages. Engines include PostgreSQL, MySQL, MariaDB, Oracle, SQL Server and Db2, plus Amazon Aurora, AWS’s own MySQL- and PostgreSQL-compatible engine.
\nAWS takes on the chores Lantern used to do at 2 a.m.: provisioning, OS and engine patching in a maintenance window you choose, automated backups with point-in-time recovery, and Multi-AZ deployments with a synchronous standby in another Availability Zone that takes over automatically. You still own the schema, indexes, queries, database users, the instance size, and who can connect.
\nHere is how Lantern creates its events database, with the safe choices spelled out:
\naws rds create-db-instance \\\n --db-instance-identifier lantern-events \\\n --engine postgres --db-instance-class db.t4g.micro \\\n --allocated-storage 20 --storage-encrypted \\\n --master-username lantern_admin --manage-master-user-password \\\n --backup-retention-period 7 --multi-az \\\n --no-publicly-accessible--manage-master-user-password stores the admin password in AWS Secrets Manager instead of your shell history. --no-publicly-accessible keeps the database off the internet; next lesson puts it in a private subnet. And because Lantern’s existing app speaks SQL, migrating is a pg_dump and a restore, with the queries unchanged:
SELECT v.name, date_trunc('month', e.starts_at) AS month, count(*) AS events\nFROM events e\nJOIN venues v ON v.id = e.venue_id\nGROUP BY v.name, month\nORDER BY month DESC, events DESC;How RDS bills: per instance-hour (with Savings Plans or reserved instances for steady use), plus storage per GB-month, backups beyond a free allowance, and data transfer. A Multi-AZ deployment roughly doubles the instance cost because there are two instances. Crucially, the instance bills all month whether busy or idle. Aurora Serverless v2 can scale capacity with load and pause when idle, which suits spiky or development databases.
\nDynamoDB is a serverless key-value and document database. There is no instance to size: you create a table, choose a primary key, and read and write items (JSON-like documents) with consistent single-digit-millisecond latency, at ten requests a day or tens of thousands a second.
\nThe catch is that you design the keys around the questions you will ask. For RSVPs, Lantern’s questions are “who is coming to event X?” and “has this person already RSVPed to X?”. That gives a partition key of eventId and a sort key of email:
aws dynamodb create-table --table-name lantern-rsvps \\\n --attribute-definitions AttributeName=eventId,AttributeType=S \\\n AttributeName=email,AttributeType=S \\\n --key-schema AttributeName=eventId,KeyType=HASH \\\n AttributeName=email,KeyType=RANGE \\\n --billing-mode PAY_PER_REQUESTCounting the RSVPs for one event is then a cheap Query:
\naws dynamodb query --table-name lantern-rsvps \\\n --key-condition-expression \"eventId = :e\" \\\n --expression-attribute-values '{\":e\": {\"S\": \"evt-2026-street-food\"}}' \\\n --select COUNTHow DynamoDB bills: in on-demand mode (PAY_PER_REQUEST), per read and write request plus storage per GB-month, and nothing for idle time. Provisioned mode, with auto scaling, can be cheaper for steady, predictable traffic. Start on-demand; switch only when the bill shows steady load. Point-in-time recovery is a setting you turn on per table, and you should.
| Question | \nRDS | \nDynamoDB | \n
|---|---|---|
| Are the questions varied or ad hoc? | \nYes: SQL handles new ones | \nNo: keys answer known ones | \n
| Need joins and multi-table constraints? | \nYes | \nRarely; you denormalise | \n
| Traffic spiky, with idle time? | \nPays for idle hours | \nPays per request | \n
| Existing SQL code to keep? | \nKeep it | \nRewrite data access | \n
| Ops you still do | \nSizing, connections, upgrades | \nKey design | \n
Lantern ends up with both: events, venues and organisers in RDS for PostgreSQL, where reports and the existing admin pages work unchanged; RSVPs in DynamoDB, where a viral event’s write spike costs a few cents of requests instead of stalling the shared database.
\n\nThe database is private, but private from what? Next lesson builds the network Lantern’s pieces live in.
\n","toc":[{"id":"sec-1","text":"Amazon RDS: your SQL database, run for you","level":2},{"id":"sec-2","text":"Amazon DynamoDB: design the keys, get speed at any scale","level":2},{"id":"sec-3","text":"Choosing","level":2}],"takeaways":["Amazon RDS runs a relational engine such as PostgreSQL for you, handling patching, backups and Multi-AZ failover, while you own the schema, queries and connections.","Amazon DynamoDB is a serverless key-value and document database where you design the keys around the questions you will ask.","RDS bills mostly per instance-hour, whether busy or idle; DynamoDB on-demand bills per request and per gigabyte stored.","Use a DynamoDB Query on keys for hot paths, because a Scan reads and bills the whole table.","Many real systems use both, relational data in RDS and high-volume simple lookups in DynamoDB."],"further":[{"title":"What is Amazon RDS?","url":"https://docs.aws.amazon.com/AmazonRDS/latest/UserGuide/Welcome.html"},{"title":"What is Amazon DynamoDB?","url":"https://docs.aws.amazon.com/amazondynamodb/latest/developerguide/Introduction.html"},{"title":"DynamoDB throughput capacity (on-demand and provisioned)","url":"https://docs.aws.amazon.com/amazondynamodb/latest/developerguide/capacity-mode.html"},{"title":"Configuring and managing a Multi-AZ deployment for Amazon RDS","url":"https://docs.aws.amazon.com/AmazonRDS/latest/UserGuide/Concepts.MultiAZ.html"}],"quiz":[{"q":"Lantern’s treasurer wants ad-hoc reports such as “events per venue per month, with organiser names”, and the questions change every quarter. Which database fits?
","options":[{"text":"DynamoDB, because it is serverless and scales automatically.","why":"Scaling is not the problem here. DynamoDB answers questions you designed keys for; new ad-hoc joins mean new indexes or exports each time."},{"text":"RDS for PostgreSQL, because SQL joins and aggregates answer new questions without redesigning the data.","why":"Correct. Relational databases shine when the questions are varied and change over time."},{"text":"S3 Standard, because reports are files.","why":"The report output can live in S3, but S3 is not a database and cannot join or aggregate rows on its own."}],"answer":1},{"q":"The RSVP table’s partition key is eventId and sort key is email. Which call returns every RSVP for one event efficiently?
eventId.","why":"A Scan reads every item in the table and applies the filter afterwards, so you pay for reading the whole table."},{"text":"A GetItem with only eventId.","why":"GetItem needs the full primary key, partition key and sort key, and returns a single item."},{"text":"A Query with the key condition eventId = :e.","why":"Correct. A Query reads only the items under that partition key, so cost grows with the RSVPs for that event, not the table."}],"answer":2},{"q":"Which RDS setting protects Lantern’s events database from the loss of one Availability Zone?
","options":[{"text":"A Multi-AZ deployment, which keeps a standby in another AZ and fails over automatically.","why":"Correct. RDS replicates to the standby synchronously and switches over when the primary’s AZ has a problem."},{"text":"Automated backups with a seven-day retention period.","why":"Backups let you restore to a point in time, but restoring creates a new instance and takes a while. They are not automatic failover."},{"text":"A larger instance class.","why":"More CPU and memory help with load, but a bigger instance in one AZ still goes down with that AZ."},{"text":"Storage encryption.","why":"Encryption protects data at rest from being read. It does nothing for availability."}],"answer":0}],"exercise":{"kind":"choice","multiple":true,"options":["rsvps","reports","ticket-lookup","relational-admin","rate-limit"],"correct":["rsvps","ticket-lookup","rate-limit"],"title":"Which data belongs in DynamoDB?","prompt":"Lantern is splitting its single PostgreSQL database. For each feature, decide whether Amazon DynamoDB is a good fit. Select every feature that should use DynamoDB; the rest stay in Amazon RDS for PostgreSQL.
\n","hints":["DynamoDB is strongest when you can say in advance exactly which key every request will use.","Varied, changing questions and joins across several tables point to SQL.","Features with short-lived data can use DynamoDB’s Time to Live (TTL) to delete items automatically at no extra cost."],"explanation":"RSVPs, ticket lookups and rate-limit counters all have one known access pattern each, keyed by an ID, and they see sudden bursts of traffic, which is where DynamoDB’s per-request pricing and consistent latency shine. Rate-limit counters also expire, and TTL deletes them for you (usually within a day or two of expiry, so the code still compares the expiry time itself). The treasurer’s reports ask new questions every quarter with joins and aggregates, and the admin pages rely on foreign keys across organisers, venues and events; both are relational work that the existing SQL already does well in RDS.
\n","checkLabels":{},"optionText":{"rsvps":{"text":"RSVPs: write one per person per event, list them by event, check for a duplicate.","why":"Good fit. Every request useseventId, plus email for the duplicate check, and writes spike when an event goes viral."},"reports":{"text":"Quarterly reports that the treasurer redesigns each time, joining events, venues and organisers.","why":"Not a good fit. Ad-hoc questions with joins are exactly what SQL handles and DynamoDB keys do not."},"ticket-lookup":{"text":"Checking a ticket by its ticket ID at the festival gate, thousands of times per minute.","why":"Good fit. A single-key GetItem at high volume with low latency is DynamoDB’s core strength."},"relational-admin":{"text":"The admin pages, which edit organisers, venues and events with foreign keys between them.","why":"Not a good fit. Multi-table relationships and constraints are relational work, and the existing SQL code keeps working in RDS."},"rate-limit":{"text":"Per-IP counters that limit RSVP spam, each expiring after ten minutes.","why":"Good fit. One key per IP address, very frequent small writes, and TTL removes expired counters automatically."}}},"words":708,"readMinutes":3}