ScyllaDB

Best for

• ·Write-intensive workloads where predictable p99 latency is required: eliminating JVM GC pauses is the primary reason to choose ScyllaDB over Cassandra
• ·Time-series and IoT ingestion at millions of writes/second where partition key design enables even distribution across nodes
• ·Message storage systems (Discord's architecture) where wide rows within a partition store ordered messages and reads access recent data
• ·Activity feeds and audit logs where append-only write patterns suit the LSM-tree storage model
• ·Multi-datacenter deployments requiring tunable consistency and local reads without cross-region latency

Excels when

• ·Write throughput exceeds what any single-node relational database can handle and horizontal write scaling is required
• ·Access patterns are known at design time and can be encoded in the partition key + clustering key schema
• ·Workload is predominantly writes with simple point reads by partition key: the LSM-tree model is optimized for this pattern
• ·Latency variance (p99/p50 ratio) is more important than absolute throughput: ScyllaDB's shard-per-core model delivers tight p99 bounds

Avoid when

• ·Workload requires ACID transactions, multi-partition transactional writes, or complex joins: ScyllaDB's data model does not support these
• ·Access patterns are not known at design time: ad-hoc queries without a defined partition key require ALLOW FILTERING and cause full partition scans
• ·Team does not have Cassandra/CQL data modeling expertise: partition key design mistakes are operational failures, not query optimization problems
• ·Data volume is modest enough to fit on a single PostgreSQL primary: the operational overhead of a distributed NoSQL cluster is not justified below millions of writes/day

Read scalability

Known failure modes

• ·Hot partition overload: a single partition key receiving disproportionate writes saturates the shard owning that partition while other shards are idle: partition key cardinality design is critical
• ·Large partition degradation: partitions exceeding 100MB cause compaction and repair operations to take excessive time; queries on large partitions scan more sstables and slow down
• ·Tombstone accumulation: frequent deletes generate tombstone markers that persist until compaction; reads that scan tombstone-heavy ranges incur tombstone GC overhead and latency spikes
• ·Repair lag: ScyllaDB relies on periodic repair operations (anti-entropy) to ensure consistency across replicas; falling behind on repair means replicas can serve divergent data indefinitely
• ·Compaction pressure: write-heavy workloads generate sstables faster than compaction can merge them; unbounded sstable proliferation degrades read performance as more files must be checked
• ·Coordinator timeout cascade: a slow or overloaded node causes coordinator timeouts to cascade: the client receives a timeout even if the mutation was applied on a quorum of replicas, leading to application-level retry storms

Bottlenecks

• ·Hot partition: a single high-cardinality partition key receiving all writes saturates the owning shard; distributing writes requires key design changes
• ·Read path tombstone scanning: deleted data leaves tombstones that must be scanned and discarded on reads until compacted: high delete rates cause read amplification
• ·Compaction I/O: SizeTieredCompactionStrategy merges sstables in bursts; on write-heavy nodes, compaction can consume significant I/O bandwidth and compete with client reads
• ·Cross-datacenter replication adds write latency for clients using cross-DC consistency levels; LOCAL_QUORUM avoids this at the cost of cross-DC divergence risk
• ·Schema migrations (adding columns) on large clusters require rolling restarts and can block on Paxos-based schema agreement across all nodes

Degradation patterns

• ·Write amplification during compaction on write-heavy nodes causes periodic I/O saturation; monitoring compaction pending tasks is the leading indicator before client latency degrades
• ·Replica divergence accumulates silently without repair: reads with consistency level ONE can return stale data indefinitely; repairs are the only mechanism to force reconciliation
• ·A slow node in a multi-DC cluster causes LOCAL_QUORUM writes to occasionally route to the slow node as a replica, elevating p99 latency; hinted handoff accumulates on the slow node

Common topology roles