Bigtable vs MongoDB: Sorted Keyspace or Indexed Documents
Bigtable is not MongoDB with fewer query operators, and MongoDB is not Bigtable with richer JSON: their distribution keys turn different questions into local work.
Situation
Telemetry, profiles, catalogs, and event histories can be represented in either system. Bigtable stores sparse rows ordered by a byte-string row key. MongoDB stores BSON documents, maintains secondary indexes, and can distribute a collection by ranged or hashed shard keys.
This leads to a tempting but weak rule: choose Bigtable above some write-rate threshold and MongoDB below it. There is no universal threshold. Payload size, key skew, update shape, query fan-out, indexes, durability, replication, cache, and hardware all change the boundary.
The Problem
Assume a device platform writes 1 KB measurements, reads recent history by device, looks up devices by customer and firmware version, and occasionally runs fleet-wide analysis. The workload contains large customers and synchronized device reconnects. These assumptions make the tradeoff visible; they are not benchmark results.
Recent history maps naturally to an ordered device-and-time key. Customer and firmware predicates map naturally to document indexes. Fleet-wide analysis fits neither primary operational path without isolation. The question is: which access path deserves to shape the primary store, and how will the system serve the others without destabilizing ingestion?
Locality Before Throughput
flowchart TD
A["Device measurement"] --> B{"Primary locality"}
B -->|Device time range| C["Bigtable row-key range"]
B -->|Document predicates| D["MongoDB indexed document"]
C --> E["Alternate rows or materialized view"]
D --> F["Compound indexes and shard routing"]
E --> G["Isolated analytical path"]
F --> G
G --> H["Validate skew, freshness, and recovery"]
Bigtable: Design the Sort Order Around the Read
Bigtable’s efficient reads use an exact row key, prefix, or bounded range. A key such as tenant#device#reverse_timestamp can make recent device history contiguous while spreading writes across many device prefixes. A timestamp-first key is unsafe because sequential writes can heat one range.
Rows are atomic; multi-row transactions are not the general programming model. Google recommends keeping rows under 100 MB and enforces a 256 MB maximum, so an unbounded “one row per device forever” design is unsafe. Use time buckets when history could grow beyond tested row-size and contention limits.
Bigtable supports filters, but filtering a broad key range does not turn it into a selective secondary-index query. Google’s schema guidance recommends redesigning data around row-key reads when filters scan too much. A continuous materialized view can maintain a query-oriented representation, subject to its documented limitations and release status; otherwise the application or pipeline maintains duplicate rows.
Bigtable Data Boost provides serverless compute for supported read jobs so analytical work does not consume the provisioned cluster’s serving nodes. It is not a promise that any arbitrary query has zero effect or a substitute for validating storage, replication, quotas, and job behavior.
MongoDB: Query Richness Has a Physical Plan
MongoDB keeps related fields in a BSON document and can index nested fields. A compound index such as {customerId: 1, firmwareVersion: 1, lastSeen: -1} can support equality predicates plus sorting when its prefix and field order fit the query. The ESR guideline is a starting point, not a guarantee; explain must confirm the winning plan and work performed.
Every index adds storage, cache demand, and mutation work. There is no defensible universal maximum index count or cache ratio. Track query frequency, keys and documents examined, index size and use, WiredTiger cache pressure, write latency, and storage behavior. A flexible schema does not mean ungoverned fields or indexes.
For a sharded collection, the shard key determines placement and routing. Queries that include the shard key or a usable prefix can target shards. Others may broadcast. A hashed device key can distribute synchronized writers but loses device-key range locality; a compound key can balance distribution and targeting if its leading fields have enough cardinality. Ranged sharding preserves locality but can create a moving hotspot when the leading key is monotonic.
MongoDB can reshard a collection starting in 5.0, and MongoDB 8.0 adds redistribution capabilities on the same key in specified cases. Resharding is a planned production operation with version, storage, capacity, and concurrency implications—not evidence that the original key is inconsequential.
Consistency and Failure Boundaries
Bigtable’s single-row operations can be atomic. With replication and multi-cluster routing, replication between clusters is eventual; single-cluster routing changes the consistency and availability profile. App profiles therefore belong in the application architecture.
MongoDB write concern and read concern define acknowledgement and visibility. A replica set provides failover within a shard; a sharded cluster adds routers, config servers, balancing, and range migrations. Multi-document transactions are supported, but cross-shard transactions cost more. Read concern snapshot provides a consistent view of majority-committed data at one point in time across shards when its documented transaction and majority-write conditions are met.
The correct comparison names the exact invariant. “A device sees its latest acknowledged configuration” needs a routing, write concern, and read concern design. “A measurement is eventually visible in a fleet index” needs a bounded-lag and replay design. Product labels do not supply either contract.
In Practice
The documented pattern is to test the distribution key using production-shaped skew. Google recommends iterating on Bigtable row-key design with Key Visualizer and hottest-node metrics. MongoDB provides analyzeShardKey, targeted-query behavior, and explain output to evaluate distribution and routing.
For the assumed device platform, replay synchronized reconnects from the largest customer. In Bigtable, inspect the heatmap, hottest-node CPU, request latency, and row growth. In MongoDB, inspect per-shard operations, chunk distribution, cache, replication lag, and whether the firmware query is targeted or broadcast. Run the fleet-wide analysis through the proposed isolated path while ingestion remains at peak.
The result should identify a workload envelope, not declare that one database “breaks” at a round number. Bigtable is favored when ordered key ranges dominate and alternate views are few and deliberate. MongoDB is favored when document predicates and evolving indexed queries dominate and the team can operate or buy a sharded document platform. The learning is that secondary-query flexibility and primary-write locality must be budgeted together.
Version and Safety Boundary
MongoDB behavior in this article targets currently supported releases and calls out 8.0-specific capabilities explicitly. Older advice about automatic chunk splitting is version-sensitive: MongoDB’s sharding reference states that automatic chunk splitting is not performed starting in 6.0.3. Validate balancing and resharding procedures against the exact minor release and deployment type.
Where It Breaks
| Choice | Failure mode | Required control |
|---|---|---|
| Bigtable | Required predicates cannot bound a row-key range | Maintained alternate representation or separate search system |
| Bigtable | Timestamp-first or low-cardinality prefix heats a tablet | Key Visualizer evidence and a distributing prefix |
| Bigtable | One row grows without bound | Time bucket and tested row-size budget |
| MongoDB | Common query omits the shard key | explain evidence and an explicit scatter budget |
| MongoDB | Indexes overwhelm cache or write capacity | Per-index usage, size, cache, and latency review |
| MongoDB | Ranged key concentrates monotonically increasing writes | Hashed or compound alternative validated with query routing |
| Either | Operational analytics competes with serving traffic | Isolated, rate-limited analytical path with freshness SLO |
What to Do Next
- Problem: A throughput headline ignores locality, skew, and query amplification.
- Solution: Choose the primary model from the dominant access path and design every alternate path explicitly.
- Proof: Replay real key distributions, observe hotspot and routing evidence, and test analytics isolation plus restore.
- Action: Record the row or shard key, consistency contract, index budget, version boundary, and migration plan in the architecture decision.