What Happens at 100K, 1M, and 10M Writes/sec?
Write rate alone cannot select a database: ten million 100-byte idempotent events and ten million 20 KB indexed transactions are different systems by orders of magnitude.
Situation
The labels 100K, 1M, and 10M writes per second are useful stress points, not product boundaries. A defensible design also specifies encoded item size, key distribution, consistency, durability, replication geography, indexes, update-versus-insert ratio, retention, burst shape, and recovery objective.
The Problem
Claims that managed services become uneconomic at a fixed rate, or that self-managed Cassandra becomes cheaper above another fixed rate, are not portable. Cloud prices vary by region and date; self-managed cost depends on utilization, replication, reserved commitments, staff, backups, upgrades, failed-zone headroom, and incident load.
The right question is: what resources does this exact mutation consume, and can the system recover from burst or failure without violating the SLO?
Build the Workload Envelope
logical_bytes_second = writes_second * encoded_item_bytes
base_capacity_units = writes_second * ceil(encoded_item_bytes / unit_bytes)
secondary_units = sum(writes_affecting_index * ceil(projected_bytes / unit_bytes))
network_bytes = logical_bytes_second * replication_and_region_factor
daily_raw_storage = logical_bytes_second * 86400
required_peak_service = peak_arrival_rate / target_utilization
replay_time = queued_writes / post_incident_spare_rate
For DynamoDB provisioned capacity, one WCU represents one standard write per second for an item up to 1 KB; transactional writes use twice the standard write capacity, and affected GSIs add their own consumption. On-demand tables use request units with the same item-size rounding concepts. Ten 1 KB events cannot be compressed by assertion into one 1 KB item; batching API calls reduces round trips, not the bytes or capacity represented by the items. AWS DynamoDB capacity modes.
Architecture Across Three Stress Points
flowchart TD
A["Production-shaped workload definition"] --> B["Durable admission buffer"]
B --> C["Partition-aware bounded writers"]
C --> D["Candidate database"]
D --> E["Tail latency, throttling, storage, and recovery evidence"]
E --> F{"SLO holds under peak and one failure"}
F -->|No| G["Change model, capacity, or requirements"]
F -->|Yes| H["Price the measured configuration"]
100K writes per second
At this level, operational simplicity may dominate, but only if keys distribute and payloads fit service limits. A single hot key can fail while total throughput looks modest. Benchmark a managed service and a self-managed option only if portability, control, or existing platform capability makes the comparison real.
1M writes per second
Queue recovery, network bandwidth, index maintenance, compaction, and failed-zone capacity become first-class. Require partition-level observability and admission control. For DynamoDB on-demand, planned growth must respect warm-throughput behavior; AWS documents immediate accommodation up to twice the previous peak and possible throttling for a larger jump inside 30 minutes. DynamoDB on-demand scaling.
For Bigtable, benchmark row-key distribution and use Key Visualizer or hot-tablet diagnostics. For Cassandra, include compaction, repair, bootstrap, and disk headroom; do not trade durability for a headline by changing commit-log synchronization without an explicit loss budget. For MongoDB, include index maintenance, WiredTiger cache pressure, replication lag, and shard movement.
10M writes per second
At this point, the architecture should assume hierarchical ingestion: regional admission, a durable log, independent writer pools, an operational serving store, and an immutable analytical copy. The design must prove network feasibility, quota approval, blast-radius isolation, backfill and replay, and the time required to restore steady state. The number still does not dictate the vendor.
Transparent TCO
Price only a tested configuration. Record the price-sheet date and region and separate:
- database request or node capacity;
- storage, indexes, backups, and change streams;
- inter-zone and inter-region transfer;
- durable buffer and analytical copy;
- reserved or committed-use terms;
- on-call, patching, repair, upgrade, and capacity engineering;
- spare capacity for a failed zone and replay.
Present a sensitivity table for item size, utilization, replication, and staff assumptions. A single three-year total without those inputs is not engineering evidence.
Required benchmark record
For every candidate, record engine and client versions, region or instance type, storage configuration, partition or shard count, replication, acknowledgement semantics, schema, indexes, serialized payload distribution, key-skew distribution, burst duration, and test duration. Warm the system to a stated condition, then inject a node or zone failure and measure backlog recovery. Report rejected and retried operations separately from accepted throughput. An average rate that hides throttling or counts client retries as new business writes is not a valid result.
In Practice
Vendor documentation establishes billing units, warm-throughput behavior, key-design rules, and service limits. It does not establish a universal buy-versus-build cutover. That decision must follow a reproducible benchmark and cost workbook. Any latency or node-throughput number in the decision record should name the software version, instance, storage, replication, consistency, schema, payload, distribution, and duration.
Where It Breaks
| Hidden variable | Failure if omitted | Required test |
|---|---|---|
| Encoded item size | Capacity and network estimates miss by multiples | Sample serialized production records |
| Key skew | One owner throttles below fleet capacity | Replay skewed production distribution |
| Secondary writes | Cost and tail latency jump after launch | Include every maintained access path |
| Burst duration | Queue cannot drain inside SLO | Measure peak arrival and spare service rate |
| Failure headroom | Zone loss converts redundancy into outage | Load-test with one failure domain removed |
| Durability setting | Benchmark wins by accepting hidden loss | Verify acknowledgement and crash recovery |
What to Do Next
- Problem: Writes per second conceal the variables that determine feasibility and cost.
- Solution: Define the full workload envelope and measure a failure-capable configuration.
- Proof: Reproduce throughput, tail latency, backlog recovery, and cost from recorded inputs.
- Action: Reject any vendor recommendation or TCO estimate that cannot show its formulas and benchmark conditions.
Interactive tools for this topic