Relational database
ACID transactions, joins and flexible queries over structured data.
Problem it solves: Most business data needs integrity constraints and transactions.
Where it sits: Behind services (and their cache).
When to use
- Default for OLTP data with relationships and transactions.
When not to use
- Write volumes beyond one primary without a sharding plan.
Failure modes
- Primary saturation on writes.
- Replication lag causes stale reads on replicas.
- Primary failure without automated failover.
Metrics to watch
- Read/write QPS
- CPU (%)
- Replication lag (s)
- Slow queries
Alternatives
- Key-value / wide-column store
- NewSQL
Configuration in Labs (illustrative defaults)
- Capacity per instance (req/s) = 5000 — Maximum requests one instance completes per second before it saturates.
- Write capacity (primary) (writes/s) = 2000 — Writes the single primary can absorb per shard. Replicas do not add write capacity.
- Read replicas (count) = 1 — Each replica adds one instance of read capacity. Replication lag is not modelled numerically.
- Shards (count) = 1 — Partitions; each multiplies read and write capacity assuming keys spread evenly (no hot key).
- Base service time (ms) = 5 — Processing time per request at zero load. Queueing adds to this as utilisation rises.
Vendor examples (pattern only): PostgreSQL, MySQL, Aurora
In the guide
- Ch. 6 · Databases and Storage p. 1
- Figures: 15, 16, 17