DynamoDB and RDS
Choose a database around the feedback system's data model and queries.
The workshop selects DynamoDB for processed feedback metadata and compares it with a relational database on RDS.
DynamoDB
DynamoDB is a managed key-value and document database. Items can have different non-key attributes, which suits results produced from different feedback formats. It offers on-demand and provisioned capacity modes, secondary indexes, and multi-region replication through global tables.
Start by listing the access patterns: retrieving a result by its identifier, listing feedback for an event, or finding jobs by processing status. Design keys and indexes for those queries instead of relying on full table scans. Flexible attributes do not remove the need for a deliberate data model.
RDS
RDS manages relational database engines such as MySQL and PostgreSQL. Relational schemas, SQL joins, and transactions fit applications with strongly connected data and complex queries. Backup, Multi-AZ, and read-replica options depend on the selected engine and deployment.
Compare by workload
| Decision | DynamoDB | RDS |
|---|---|---|
| Data model | Key-value and document items | Relational tables |
| Queries | Design keys and indexes for access patterns | SQL, including joins |
| Capacity | On-demand or provisioned throughput | Engine and deployment capacity choices |
| Cost | Capacity, storage, and enabled features | Database deployment, storage, and enabled features |
| Replication | Global tables for multi-region needs | Engine-specific replicas and availability options |
| Example fit | Feedback records queried by event, user, or status | Data requiring relational joins and transactions |
DynamoDB fits the example’s varying feedback metadata and defined lookup patterns. RDS may be a better fit when relational querying becomes a central requirement. Neither is automatically cheaper or faster for every workload.