NoSQL capacity and cost

Bytes per row = payload + row overhead + cells × cell overhead; per partition = key + partition overhead. Defaults: 3 bytes per cell, 6 per row, 32 per partition, for the SSTable format of Cassandra 3.0 and later, which stores timestamps, TTLs and lengths as variable-length deltas (Storage engine). The pre-3.0 rule of thumb was 15 bytes per column and 23 per row; enter that for a conservative figure.

On disk = raw × compressed fraction × RF.

Free space by compaction strategy (Compaction): size-tiered 50% (a compaction may rewrite the largest tier, in the worst case all the data), leveled 10% (small fixed-size SSTables, ~90% of data in the last level), time-window 1 ÷ windows retained (one window is compacted at a time), at least 5%. Plus the operational headroom you set (snapshots, streaming, growth).

Nodes = max(⌈total ÷ usable disk per node⌉, ⌈total ÷ target density⌉, RF), rounded up to a multiple of the racks.

Replacing a node streams its data at the aggregate rate you give. Each sender is throttled by stream_throughput_outbound (24 MiB/s by default in Cassandra 4) and the total by the network and the new node’s disk; with vnodes many nodes send at once.

A full repair cycle (nodetool repair -pr on every node) reads each node’s primary ranges on its RF replicas at once to build Merkle trees: nodes × (data per node ÷ RF) ÷ validation rate ÷ parallel repairs, plus the out-of-sync fraction streamed. It should finish inside gc_grace_seconds (864,000 s, 10 days, by default), or deleted data can reappear (Repair).

ScyllaDB uses the same file format family and compaction strategies; it streams and compacts per CPU shard, so the rates and density to enter are higher (ScyllaDB system requirements).

Per key: a 24-byte dictEntry; one 8-byte bucket pointer per slot, slots being the next power of two at or above the key count; the key as an SDS string (3-byte header below 256 bytes, 5 below 64 KB, plus the bytes and a NUL); the value; and for keys with a TTL a second entry in the expires dict. Every allocation is rounded up to a jemalloc size class (8, 16, 24, 32, 40, 48, 56, 64, 80, 96, 112, 128, 160…). This gives 56 bytes for an empty key with an empty value, as MEMORY USAGE reports.

Strings: integers are kept in the object (0–9999 are shared); up to 44 bytes, embstr (object and string in one allocation); longer, raw (a 16-byte object plus the SDS).

Collections (Memory optimisation; defaults from redis.conf): a hash stays a listpack while it has at most 128 fields (hash-max-listpack-entries) and every field and value is at most 64 bytes (hash-max-listpack-value); a sorted set the same (zset-max-listpack-entries 128, zset-max-listpack-value 64); a set of integers is an intset up to 512 members (set-max-intset-entries), otherwise a listpack up to 128 members of up to 64 bytes (set-max-listpack-entries, Redis 7.2); lists are quicklists of listpacks of up to 8 KB (list-max-listpack-size -2). A listpack entry is a 1–5-byte header, the bytes and a 1–5-byte back-length; a listpack has a 6-byte header and an end byte. Past the limits: a hashtable (a dict entry, bucket and SDS strings per element) or, for a sorted set, a skiplist plus a dict (a node of 24 + 16 bytes per level, levels drawn with p = ¼). Sorted-set scores in a listpack are taken as 5-byte integers.

used_memory adds ~1 MB for an empty instance. RSS ≈ used × mem_fragmentation_ratio (INFO memory).

Host RAM ≥ maxmemory × fragmentation + repl-backlog-size + replicas × 256 MB (the hard limit of client-output-buffer-limit replica 256mb 64mb 60) + the pages rewritten while a forked snapshot or AOF rewrite runs (copy-on-write).

Eviction policies (Key eviction): allkeys-lru for a pure cache, allkeys-lfu for a skewed long-lived hot set, volatile-lru when cache keys with TTLs share the instance with keys that must stay, volatile-ttl when TTLs say what is worth keeping, noeviction for a primary store, queue or locks.

Working set = documents × size × hot fraction + Σ indexes × hot fraction, with an index taken as documents × (key bytes + 12 bytes for the RecordId and key format). The cache holds pages uncompressed, so the uncompressed (BSON) size is used. Prefix compression often makes real indexes smaller: check db.collection.stats().indexSizes.

WiredTiger’s default cache is the larger of 50% of (RAM − 1 GB) and 256 MB (WiredTiger storage engine), so RAM ≥ 2 × working set + 1 GB, plus about 1 MB per connection. The rest of RAM serves the filesystem cache of compressed data.

The default oplog is 5% of free disk, at least 990 MB and at most 50 GB, on 64-bit Linux and Windows (Replica set oplog). Each write adds its change plus ~100 bytes of entry fields; window = oplog size ÷ bytes per hour.

Microsoft’s published examples (Request Units in Azure Cosmos DB): a point read costs 1 RU at 1 KB, 1.3 RU at 4 KB and 10 RU at 64 KB; a write about 5, 7 and 48 RU, with the default policy of indexing every property. Between those sizes the page interpolates on log(size); above 64 KB in proportion.

Strong and bounded-staleness reads cost twice as much (Consistency levels).

Writes scale with the number of indexed properties (Indexing policies); the page’s factors for selective (× 0.75) and no indexing (× 0.6) are rough assumptions — measure.

Query RU depend on the query: measure the x-ms-request-charge header and enter it.

A physical partition serves up to 10,000 RU/s and 50 GB; a logical partition (one partition-key value) holds at most 20 GB (Partitioning). Index storage is taken as 20% of item bytes.

Cost: RU/s ÷ 100 × the price per 100 RU/s-hour × 730 hours × regions. The default price ($0.008) is a placeholder for standard provisioned throughput: use your region’s price. Autoscale bills the highest RU/s of each hour at 1.5× the rate, between 10% and 100% of the maximum. Check the result with the Cosmos DB capacity calculator.

Zipf(s): the key of rank i gets 1/i^s ÷ H(N, s), where H(N, s) = Σ 1/i^s; so the top key’s share is 1 ÷ H(N, s). Keys are hashed with FNV-1a and the murmur3 finaliser.

Per-partition limits: Cosmos DB 10,000 RU/s per physical partition; DynamoDB 3,000 read and 1,000 write capacity units per partition (partition key design); Cassandra has no fixed limit — a partition is served by its RF replicas, so enter what one node sustains for you (20,000 ops/s is only a placeholder).

The shards a hot key needs = ⌈key load ÷ limit⌉.

No growth over time: enter the data size at the horizon you are planning for.

Cassandra: no materialised views or secondary indexes (add their tables as rows), no tombstone accumulation, a single data centre; ScyllaDB’s incremental compaction strategy is not modelled.

Redis: no modules, streams or Redis Cluster slot overhead; the value is the same for every key; listpack integers other than sorted-set scores are treated as strings; Redis 7.0 still calls listpacks ziplists in some configuration names, and Valkey 8’s embedded keys are smaller than this.

MongoDB: no sharded-cluster config servers or mongos; the hot fraction is your judgement — check the cache’s pages read into cache and eviction counters.

Cosmos DB: NoSQL API only; no serverless, reserved capacity or multi-region-write pricing differences; RU figures are published examples, not a model of the engine.

The hot-partition checker assumes partitions are fixed and keys hashed; range-partitioned stores (Bigtable, HBase) split hot ranges, but a single hot row still cannot be split.