If you’ve ever tried to pick a database for your project, you’ve probably stumbled across a storm of buzzwords: relational, NoSQL, document, key-value… and then services like Amazon DynamoDB and Amazon DocumentDB pop up to make things even more confusing. Let’s clear the air.
Relational Databases (the classics)
Think of a relational database like a really strict spreadsheet. Every row has to match the schema, every column has a defined type, and relationships are neatly managed with keys.
-
Examples: MySQL, PostgreSQL, Oracle
-
Strengths: reliable transactions, rich SQL queries, perfect when your data is tidy and structured
-
Downsides: scaling across lots of servers can get messy, and schema changes are often painful
NoSQL Databases (the flexible ones)
“NoSQL” is kind of a catch-all label for databases that don’t play by the strict relational rules. Instead, they’re designed for flexibility and scale.
Different “flavors” of NoSQL include:
-
Key-value stores (like DynamoDB or Redis)
-
Document stores (like MongoDB or Amazon DocumentDB)
-
Column-family stores (like Cassandra)
-
Graph databases (like Neo4j or Amazon Neptune)
In short: NoSQL gives up some of the rigid structure in exchange for speed, flexibility, and easier scaling.
So… what about DynamoDB?
Amazon DynamoDB is best described as a key-value database (with some wide-column flavor). Every item needs a primary key (partition key, and sometimes a sort key), but beyond that you can throw in whatever attributes you like: strings, numbers, sets, even nested maps and lists.
That’s why some people say DynamoDB feels a little “document-like.” And yes, it does let you store JSON-style structures. But technically, DynamoDB is not a document database in the same sense as MongoDB or Amazon DocumentDB.
Think of DynamoDB as:
A highly scalable, predictable NoSQL key-value store that also happens to let you nest data like a document.
DynamoDB vs Amazon DocumentDB
-
DynamoDB: Built for scale and speed. Perfect when you know your access patterns (like fetching shopping carts, storing IoT events, or handling game leaderboards).
-
DocumentDB: Built for flexibility. Each record is a JSON-like document that can look completely different from the next. Great when you need ad-hoc queries and don’t want to worry about every record matching a schema.
Are “NoSQL” and “Document” the same thing?
Not quite. A document database is one type of NoSQL — just like key-value or graph databases are.
Easiest way to remember it:
All document databases are NoSQL, but not all NoSQL databases are document databases.
The Bottom Line
-
Reach for a relational DB when you want strict schemas, joins, and powerful SQL.
-
Choose DynamoDB when you care about scale, performance, and predictable access patterns.
-
Use a document DB when you want the freedom of JSON-like documents and flexible queries.
DynamoDB isn’t a pure document database — it’s a NoSQL key-value store with some document-style powers. And that’s exactly why it’s so popular: you get scalability and flexibility without giving up predictability.
