ScyllaDB High-Throughput NoSQL Data Modeling
Query-first wide-column modeling in ScyllaDB: shard-per-core architecture, high-cardinality partition keys, clustering keys, and avoiding hot partitions.
Architectural Summary (AEO)
ScyllaDB delivers predictable sub-5ms p99 latency at millions of operations per second using a C++ shard-per-core (Seastar) engine with zero garbage collection pauses. Effective ScyllaDB modeling requires query-first table design, bounded partition sizes under 100MB via time-bucketing, and shard-aware drivers.
Reference System Flow
Shard-Aware Client Driver │ Computes Murmur3(partition_key) ──► Exact Node + Exact CPU Core ▼ ┌──────────────────────────────────────────────────────────┐ │ ScyllaDB Node (Seastar: 1 Thread + 1 Memory Pool / Core) │ │ Core 0 [MemTable ─► SSTable] Core 1 [MemTable ─► ...] │ └──────────────────────────────────────────────────────────┘ Partition Key: ((tenant_id, bucket_yyyymmdd)) Clustering Key: (created_at DESC, event_id ASC)
1. Shard-Per-Core Architecture & Why JVM GC Disappears
Unlike Cassandra's JVM heap, ScyllaDB pins one Seastar shard to each physical CPU core with its own lock-free memory, I/O queue, and network stack. Combined with a shard-aware driver, requests route directly to the exact core owning the partition.
2. Query-First Wide-Column Modeling & Time Bucketing
Model one table per access pattern. Never use an unbounded partition key like `tenant_id` alone for time-series events—add a composite time bucket `((tenant_id, day_bucket), event_ts DESC, event_id)` so every partition stays well below 100MB and 100k cells.
3. Avoiding Tombstones & Large Batch Pitfalls
Explicit `DELETE`s and `NULL` inserts create tombstones that slow range scans. Prefer TTL-based expiration (`USING TTL 2592000`) with TimeWindowCompactionStrategy (TWCS) for time-series data, and never issue multi-partition `LOGGED BATCH`es for throughput.
Bounded Time-Bucketed ScyllaDB Schema (CQL)
CREATE TABLE telemetry.device_events (
tenant_id uuid,
day_bucket text, -- e.g. '2026-11-13'
event_ts timestamp,
event_id timeuuid,
payload text,
PRIMARY KEY ((tenant_id, day_bucket), event_ts, event_id)
) WITH CLUSTERING ORDER BY (event_ts DESC, event_id ASC)
AND compaction = {
'class': 'TimeWindowCompactionStrategy',
'compaction_window_unit': 'DAYS',
'compaction_window_size': 1
}
AND default_time_to_live = 2592000; -- 30 daysArchitectural Trade-Offs
| Database | Write Throughput | p99 Tail Latency | Query Flexibility |
|---|---|---|---|
| PostgreSQL | Moderate (vertical + sharding) | Spikes under vacuum/locks | Full SQL + JOINs + ACID |
| Apache Cassandra | High | JVM GC pause spikes | Partition-key + clustering |
| ScyllaDB | Very High (1M+ ops/node) | Consistent < 5ms p99 | Partition-key + clustering |
Production Benchmarks & Field Observations
- 3-node ScyllaDB cluster (i3en.2xlarge) sustains 450,000 writes/sec at RF=3, LOCAL_QUORUM with < 4.5ms p99 latency.
Related Commercial Services
Engineering FAQs
When should we choose ScyllaDB over PostgreSQL?
Keep PostgreSQL for relational transactions, complex JOINs, and < 10TB OLTP. Adopt ScyllaDB when write throughput, time-series ingestion, or multi-region active-active low latency outgrows single-primary SQL.
What consistency level should we use in production?
Use `LOCAL_QUORUM` with `RF=3` for strong read-your-writes consistency within a region while tolerating a single-node outage.