Auntie Akos runs the busiest chop bar in Osu. Every dish has a story. Some are made fresh on order, some are pre-cooked and lined up on a buffet counter, and some are just raw ingredients sitting in the storeroom. Three ways of serving food. Three ways of storing data.
Step into the kitchenAuntie Akos doesn't serve food the same way to everyone. When a customer wants something specific — like waakye with the EXACT toppings they like — she calls the master chef and he cooks it from scratch.
When 50 hungry workers arrive at lunchtime, she doesn't make them wait. She has a big buffet counter where common dishes are pre-arranged — they grab and go.
And in the back, behind a locked door, is the storeroom where she keeps the bags of rice, the crates of tomatoes, the dried fish — the raw ingredients that haven't been touched yet.
Three places to keep food. Three different jobs. Same idea applies to your data in AWS.
The master chef cooks each meal carefully, by recipe, from scratch. He follows strict steps: chop the onions FIRST, then add the tomatoes, then the spice — never out of order. If you ask for waakye, he gives you waakye made the right way.
You can ask him complicated questions: "Make me waakye, but with extra wele, no shito, and add a boiled egg, but only if there's egg in stock." He understands. He follows the recipe. He gives you exactly what you asked for.
But he's only one person. He can serve maybe 30 customers an hour. If 100 people show up at once, you'll wait. And if he gets sick, the kitchen slows down badly.
RDSRDS = Relational Database Service. Manages SQL databases like MySQL, PostgreSQL, MariaDB, and Oracle. Uses tables with rows and columns and supports complex queries and joins. is exactly this. It's a relational database — structured tables, strict rules, complex queries. Perfect for things like banking transactions, where every relationship matters: customer → account → transaction → balance.
Use RDS when: you need precise relationships, complex queries (JOINs), and ACID guarantees — like an HR system, a banking app, or a hospital records system.
Now picture the buffet at lunchtime. 200 people pour in. Auntie doesn't ask questions. You walk up, point to the dish you want, she scoops it onto your plate, NEXT.
It's fast. It's predictable. Every plate you serve takes about 2 seconds, no matter how many people are in line. Need more capacity? Add another buffet counter — they all work in parallel.
But here's the thing: the buffet doesn't do custom orders. You can't say "give me the jollof, but with the okro from the second tray, mixed with sauce from the first." Each dish stands alone. No mixing. No relationships.
DynamoDBDynamoDB is a NoSQL key-value and document database. It delivers single-digit millisecond performance at any scale, perfect for high-traffic applications. works the same way. You ask for one thing by its key (the dish name), and it gives it back in milliseconds. Doesn't matter if you have 10 users or 10 million.
Use DynamoDB when: you need lightning-fast lookups by ID, massive scale, and your data doesn't need complex joins — like a shopping cart, a leaderboard, a user session, or a chat app.
Behind the kitchen, there's a giant locked storeroom. Sacks of rice. Crates of tomatoes. Frozen tilapia. Tubs of oil. Cleaning supplies. Old menus from 2018. Wedding photos from when Auntie opened the bar.
Anything goes in. Anything. No structure required. No recipe needed. Just a label slapped on it: "rice-50kg-bag-3" or "wedding-photo-2018.jpg."
It's CHEAP. The storeroom holds tons of stuff for almost nothing. You don't pay for the chef's time — you just pay for the floor space.
But it's slow. To get something out, someone has to walk back, find the box, carry it forward. Not the kind of place you grab from while a customer waits.
S3S3 = Simple Storage Service. Object storage for any type of file. 99.999999999% durability. Scales to virtually unlimited size at very low cost per GB. is the storeroom of AWS. Files. Photos. Videos. Backups. Logs. Big CSV exports. Anything you want to keep but don't need to query in real-time.
Use S3 when: you need to store FILES — images, videos, backups, logs, static website content, machine learning datasets, anything you'd put in a folder on a hard drive.
Most beginners get this wrong. They reach for RDS for everything because that's what they learned in school — tables, rows, SQL. But most modern apps use ALL THREE. Try the picker below — see which one fits each scenario:
When you're designing your next app and someone asks "where should this data live?" — picture Auntie Akos's chop bar. Is it custom-cooked, ready-to-grab, or raw stored?
SQL databases. Structured data. Complex queries. Used for relationships and transactions.
NoSQL key-value. Lightning-fast lookups. Massive scale. Used for sessions, carts, leaderboards.
Object storage. Anything goes in. Cheap, durable. Used for files, backups, media, datasets.
"You don't pick a database. You pick the right tool for the job — like Auntie Akos picks the right pot for each dish."
Read the story again