DynamoDB is Amazon’s fully managed NoSQL database service offered on AWS. Here’s a breakdown for you:
🔹 Key Points
- Type: NoSQL, key–value and document database.
- Managed by AWS: You don’t need to manage servers, scaling, replication, or backups.
- Scalable: Can handle millions of requests per second with automatic scaling.
- Fast: Low latency (single-digit milliseconds) for both reads and writes.
- Flexible schema: Unlike relational DBs (Postgres/MySQL), DynamoDB does not require fixed schemas—each item in a table can have different attributes.
🔹 Core Concepts
- Table → Collection of items (like a relational table, but schema-less).
- Item → A single record (like a row).
- Attribute → A field within an item (like a column).
-
Primary key → Uniquely identifies each item. Can be:
- Partition key (hash key)
- Partition key + sort key (composite key)
🔹 Features
- Global tables → Multi-region replication for high availability.
- On-demand or provisioned capacity → Pay-per-request or pre-allocate read/write capacity.
- Streams → Capture changes in real-time for event-driven apps.
- TTL (Time-to-Live) → Auto-delete expired data.
- Integrates well with AWS Lambda, API Gateway, etc. (often used in serverless apps).
🔹 When to Use
- Applications needing high scalability and low latency.
- E-commerce (product catalogs, shopping carts).
- Social media apps (user activity, followers, likes).
- IoT (sensor data, telemetry).
- Gaming (leaderboards, session data).
👉 Think of it as AWS’s alternative to MongoDB, but fully managed, auto-scaled, and tightly integrated with AWS services.
🔹 DynamoDB vs PostgreSQL/MySQL
| Feature | DynamoDB (NoSQL) | PostgreSQL / MySQL (Relational SQL) |
|---|---|---|
| Data Model | Key–Value + Document (flexible schema, items can differ) | Tables with rows & fixed schema (columns defined upfront) |
| Schema | Schema-less (dynamic attributes per item) | Strict schema (tables/columns must be predefined) |
| Querying | Key-based lookups, indexes (LSI, GSI), limited querying | Rich querying with SQL (joins, group by, aggregations, complex filters) |
| Transactions | Supports ACID transactions, but limited compared to RDBMS | Strong ACID compliance, complex multi-row transactions |
| Scaling | Horizontal scaling built-in (auto-sharding, partitions) | Vertical scaling mostly (bigger server) or manual sharding/replication |
| Performance | Ultra-low latency (single-digit ms), predictable | Slower under massive scale (depends on hardware and optimization) |
| Joins | Not supported (must denormalize or manage manually) | Fully supported (inner, outer, cross joins, etc.) |
| Best For | High-scale apps with simple access patterns (e.g., user sessions, IoT, shopping cart, social feeds) | Applications needing rich queries, relationships, and data consistency (banking, ERP, analytics) |
| Hosting | Managed by AWS (no server mgmt, auto scaling, backups, HA) | Can be self-hosted or managed (AWS RDS, Cloud SQL, etc.) |
| Cost Model | Pay-per-request or provisioned throughput (depends on read/write ops) | Pay for compute & storage (usually instance-based) |
🔹 When to Choose
-
DynamoDB (NoSQL) ✅ You need massive scalability (millions of req/sec). ✅ Data access is mostly key-value lookups (e.g.,
userId → userProfile). ✅ You want serverless & auto-scaling with little ops overhead. ✅ Use cases: Social media feeds, IoT, gaming leaderboards, shopping carts. -
PostgreSQL/MySQL (SQL) ✅ You need complex queries, joins, reporting. ✅ Relationships between entities matter (e.g., orders ↔ customers ↔ products). ✅ Strong transactional consistency is required (e.g., banking, payments). ✅ Use cases: Finance, ERP, analytics dashboards, HRMS, CRM.
👉 Simple rule of thumb:
- If your data is highly relational and needs joins → PostgreSQL/MySQL.
- If your data is huge scale, simple access patterns, low latency → DynamoDB.