Monster Scale Summit

Summary: Guilherme Nogueira and Nadav Har’El presented a deep dive into Scylla DB’s DynamoDB-compatible API, Alternator. They discussed reasons for migrating from DynamoDB, citing high and unpredictable costs, latency issues, and inflexibility. A use case analysis revealed a one-petabyte dataset with 1k ops/sec reads and 400k ops/sec writes, costing $500 million annually on DynamoDB on-demand. Scylla DB offers a 50% cost reduction, achieving similar performance with lower latency. Alternator supports DynamoDB APIs, enabling migration without application changes. The migration path involves dual writes and potential ETL processes. Scylla DB’s on-prem solution costs $24 million annually, 11 times lower than DynamoDB’s provisioned mode.

Topics discussed

• Why customers move off DynamoDB due to unpredictable cost, throttling, tail latency, and AWS lock-in.
• How ScyllaDB (via Alternator) delivers DynamoDB API compatibility, lower cost, and stable low latency on any cloud, on-prem, or Kubernetes.
• How ScyllaDB outperforms DynamoDB in Zipfian and uniform benchmarks and avoids throttling issues.
• What drives DynamoDB cost: on-demand vs provisioned capacity, global tables, item size, RCU/WCU multipliers.
• How Alternator implements the API inside ScyllaDB: HTTP/JSON, shared product, materialized views for GSIs/LSIs, JSON storage for non-key attributes, Prometheus/Grafana monitoring.
• How load balancing works: server-side LB, coordinator-only nodes, and preferred client-side wrappers around AWS SDKs to pick the right node/AZ.
• How to migrate: dual writes, DynamoDB Streams + Lambda, S3 exports, Spark/Kafka connectors, Scylla Migrator, ETL for CQL schema, shard-aware and rack-aware drivers.
• When tablets help resize clusters quickly and keep scaling smooth.

Takeaways

• Use client-side load balancing around the AWS SDK to learn live nodes, choose the right AZ, and hit the owning shard; it removes extra hops, cuts latency, and saves network cost compared to generic server LBs.
• Migrate safely with dual writes or DynamoDB Streams to avoid throttling production tables. Exporting via S3 or Spark works, but watch RCUs/WCUs and JSON type mismatches; plan ETL if you move to CQL’s typed schema.
• For CQL, redesign tables and use Scylla’s shard-aware, rack-aware drivers (and Spark/Kafka connectors) to keep requests local and predictable. Expect to handle schema evolution explicitly since DynamoDB was schema-less.
• Cost modeling matters: global tables, large 10 KB items, and daily overwrites explode DynamoDB bills ($500M on-demand, $250M provisioned). The same workload ran on ScyllaDB on-prem for $24M, with a 50% cost-cut guarantee if your savings fall short.

Top takeaway:  Run your DynamoDB workload on ScyllaDB through Alternator and use client-side load balancing to keep single-digit millisecond latency at about 11–24× lower cost than the DynamoDB deployment shown.