The expensive NoSQL mistake is not choosing the database with the lowest benchmark latency. It is choosing a data model whose failure boundary, consistency contract, or operating model conflicts with the application.

Situation

Bigtable, DynamoDB, Cassandra, and MongoDB can all distribute data and serve high request volumes, but they expose different abstractions. Bigtable orders rows lexicographically. DynamoDB routes items by partition key and optionally orders them by sort key. Cassandra distributes CQL partitions across a peer-to-peer cluster. MongoDB stores BSON documents and can distribute collections by ranged or hashed shard keys.

Those are not implementation details to compare after a vendor shortlist. They determine which queries are local, which writes contend, which guarantees cross a region, and which failure modes the team must own.

The Problem

Selection exercises often begin with an imprecise target such as “one million writes per second.” That number is insufficient. A 200-byte append with uniform keys is not equivalent to a 20 KB conditional update concentrated on one tenant. The same average rate can require radically different capacity when bursts, indexes, replication, item size, and skew are included.

Before choosing a service, define a workload envelope:

RequirementEvidence to collect
Access pathsEvery latency-sensitive read and write, including administrative and repair paths
DistributionKey cardinality, hottest-key share, tenant skew, and time correlation
Object shapeP50 and P99 item or partition size, update frequency, and retention
CorrectnessAtomicity boundary, conditional-write needs, read consistency, and conflict policy
GeographyWriter locations, failover topology, residency, and measured replication lag tolerance
DemandSustained and burst rates by operation, payload size, and index fan-out
OperationsUpgrade, repair, rebalance, backup, restore, and incident ownership
EconomicsRegional prices, replicas, indexes, storage growth, headroom, egress, and labor

The core question is therefore: which system makes the required access paths and correctness boundaries native while leaving an operating model the organization can verify?

A Constraint-First Decision Framework

Start with disqualifiers, not scores. A weighted spreadsheet can hide a fatal mismatch by averaging it with minor advantages.

flowchart TD
    A["Document the workload envelope"] --> B{"Need rich document predicates and evolving indexes?"}
    B -->|Yes| C["Evaluate MongoDB and its shard-key implications"]
    B -->|No| D{"Need ordered prefix or range scans at very large scale?"}
    D -->|Yes| E["Evaluate Bigtable and row-key hotspot controls"]
    D -->|No| F{"Need an AWS-managed key-value service?"}
    F -->|Yes| G["Evaluate DynamoDB partition and index capacity"]
    F -->|No| H{"Can the team own repair, compaction, and upgrades?"}
    H -->|Yes| I["Evaluate Cassandra for topology control"]
    H -->|No| J["Revisit managed services or reduce requirements"]
    C --> K["Prototype hottest and rarest access paths"]
    E --> K
    G --> K
    I --> K

This tree identifies a starting point, not a winner. Each candidate must still pass correctness, resilience, and cost tests.

Bigtable: Ordered Access Is the Primary Design Lever

Bigtable is strongest when reads can be expressed as a row-key lookup, prefix scan, or contiguous range scan. Rows are ordered lexicographically, and transactions are limited to a single row. Google recommends designing row keys from planned reads, keeping related rows contiguous, and avoiding timestamp-first or monotonically increasing keys that concentrate traffic.

That makes Bigtable a natural candidate for high-volume telemetry, event histories, and entity-plus-time access. It is a poor default for arbitrary predicates or multi-row transactional invariants. Secondary access requires another representation, such as a continuous materialized view where supported, and must be included in the write and recovery model.

DynamoDB: Partition-Key Locality and Explicit Access Paths

DynamoDB is strongest when operations are expressible as item access or a query within a partition key. A composite key can order related items by sort key. Global secondary indexes provide alternative keys, but they are separate replicated structures: their capacity, propagation, projection size, and hot keys are part of the system design.

AWS documents a design ceiling of 1,000 write units and 3,000 read units per second for a physical partition. Adaptive capacity helps uneven workloads, but it does not remove the need for high-cardinality keys or protect an unbounded hot item. Item size also changes consumed capacity, so “requests per second” alone is not a capacity model.

Cassandra: Topology Control Comes with Repair Ownership

Cassandra is strongest when a team needs control of placement, hardware, replication factor, and per-operation consistency. Its partitions are distributed by consistent hashing; replicas accept mutations, and consistency levels determine how many replicas must acknowledge a read or write before the coordinator responds. Cassandra still sends writes to all replicas for the partition regardless of the acknowledgement level. Correctness depends on replication, consistency levels, clock discipline, repair, and data model—not simply on the label “masterless.”

Cassandra’s local LSM engine turns updates and deletes into new immutable SSTable entries. Compaction and repair are correctness and capacity activities, not optional housekeeping. Cassandra 5.0 recommends Unified Compaction Strategy for most new workloads, but workload validation is still required, especially for TTL-heavy or unusually read-heavy tables.

MongoDB: Query Flexibility Still Requires a Distribution Key

MongoDB is strongest when the document aggregate matches application ownership and evolving queries require multiple indexes. Within a sharded collection, the shard key determines placement and routing. Queries containing the shard key or its prefix can be targeted; other queries may be broadcast. Hashed sharding improves distribution for monotonically changing values but weakens range locality.

Indexes are not free flexibility. They consume storage and cache, add write work, and can create a second scaling constraint. Sharding also changes uniqueness rules: unless _id is the shard key, MongoDB does not enforce _id uniqueness across the entire sharded cluster. These constraints belong in application design reviews.

In Practice

The documented pattern across all four systems is query-first modeling:

  • Bigtable’s schema guidance says to rank planned queries and validate row keys with Key Visualizer and monitoring.
  • DynamoDB’s partition-key guidance says to design for uniform activity across base-table and index keys and to calculate capacity with item size.
  • Cassandra’s documentation ties visibility of acknowledged writes to quorum intersection—commonly expressed as W + R > RF within the applicable replica set—with repair required to guarantee eventual replica convergence.
  • MongoDB’s sharding documentation says the shard key controls distribution and whether a query can target shards rather than broadcast.

This is CARL evidence derived from documented behavior, not a claim that one product wins every workload. The engineering action is to turn production traces into a replayable candidate test. The result to seek is not a peak throughput number; it is bounded latency and correct results under skew, node or zone loss, index fan-out, and recovery. The learning is that a database decision remains provisional until those boundaries are exercised.

Architecture Review Gate

A principal-level review should require answers to these questions:

  1. What percentage of production operations are single-key, prefix/range, or secondary-predicate queries?
  2. Can the hottest tenant or key exceed a physical partition’s serviceable capacity?
  3. Which invariants require compare-and-set, multi-document, multi-row, or multi-region coordination?
  4. What happens to reads during replication lag or regional isolation?
  5. How many physical writes does one logical write create across indexes, replicas, streams, and materialized views?
  6. Can a restore reproduce the base data and every derived access path to the same recovery point?
  7. Which team owns shard-key migration, repair, compaction, or service quota management?
  8. Has the cost model been replayed against P50, P95, and failure-mode demand rather than averages?

Where It Breaks

ChoiceMismatch that should stop adoptionProof required before approval
BigtableCritical queries cannot use a row key, prefix, or bounded rangeTrace replay plus scan-volume and hottest-node metrics
DynamoDBA single hot key must exceed its partition budget or transactional scope is broader than supportedKey-frequency histogram and correctness tests under throttling
CassandraNo team owns repair, compaction, upgrades, capacity, and clock healthFailure drill, repair SLO, restore test, and staffing plan
MongoDBRequired queries scatter across shards or index working set exceeds the memory planexplain evidence, shard targeting, cache metrics, and rebalance test

No fixed throughput threshold belongs in this table. The rejection boundary must be calculated from the workload, current service limits, and measured behavior.

What to Do Next

  • Problem: Product categories hide the physical work behind each request.
  • Solution: Define the workload envelope and eliminate candidates that violate a hard correctness or operational constraint.
  • Proof: Replay representative and adversarial traffic, including hot keys, index fan-out, failover, repair, and restore.
  • Action: Record the decision as an ADR with source versions, assumptions, test artifacts, rejection reasons, and a date for revalidation.

Sources