Field sensors for a water utility emit high-scale device telemetry with simple key-based access patterns. Architects considered forcing everything into relational RDS. What is the better database choice?
Select an answer to reveal the explanation.
Short Explanation
If the sensors just need fast key lookups at firehose scale, don’t shove them into a relational mold. DynamoDB is the purpose-built fit for that telemetry shape.
Full Explanation
Field sensors for a water utility emitting high-scale device telemetry with simple key-based access patterns fit a purpose-built store such as Amazon DynamoDB rather than forcing relational RDS. DynamoDB scales for high write ingest and key-value or document-style access without the operational overhead of relational joins those patterns do not need. Using RDS for MySQL as the only store even at massive key-value write scale invites connection and storage bottlenecks. A single shared Excel file on EFS updated by every gateway is not a telemetry database. Amazon Redshift as a real-time per-device OLTP key-value path misuses a warehouse. Exam caveat: DynamoDB still needs correct partition keys, capacity modes, and TTL or archival design for sensor sprawl. Operational check: model device-id and time keys, load a burst of telemetry, confirm p99 write latency, and compare cost/ops to an RDS pilot that struggles at the same ingest. In municipal cloud governance, record the owners, success metrics, and rollback or restore contacts beside this technical choice so the next incident, budget review, or audit does not rediscover the decision from scratch under time pressure. In municipal cloud governance, record the owners, success metrics, and rollback or restore contacts beside this technical choice so the next incident, budget review, or audit does not rediscover the decision from scratch under time pressure.