DynamoDB Cost Optimization Masterclass: ScyllaDB as a DynamoDB Alternative

How to assess whether ScyllaDB is a good fit and what a migration typically involves.

1. ScyllaDB as a DynamoDB
Alternative
Felipe Cardeneti Mendes

2. Felipe Cardeneti Mendes
●Technical Director at ScyllaDB
●Linux and Open Source enthusiast
●ScyllaDB Passionate

3. ScyllaDB and
DynamoDB

4. When is ScyllaDB an overkill?
■ScyllaDB is a distributed leaderless database
○3 nodes at least
○NVMe flash storage:
■Faster
■Less Expensive than EBS
■Primary dimensions to watch out:
○Low Throughput – Infrastructure underutilization;
○Storage Growth – High density tables → Infrastructure overhead
■Did you know DynamoDB charges you for RAW uncompressed data? :-)
■Secondary dimensions:
○Dependency on AWS ecosystem – Requires considerable refactoring effort
○Feature set – Expiration Events, Accounting/Capping, Multi-item transactions

5. Comparison
Overview (and gotchas)

6. ScyllaDB Specific Considerations (and Features)
■Workload Prioritization
○Helps with workload consolidation
○Adaptability to Changing Conditions
○Addresses the "too many tables" problem
■Excess capacity is shared
■Enhanced infrastructure utilization

7. ScyllaDB Specific Considerations (and Features)
■Specialized Cache
○Read-through – No consistency
concerns
○Built-in
○Simplified operations

8. ScyllaDB Specific Considerations (and Features)
■Elasticity
○Tablets are here! :-)
○Still no "autoscaling" – but easily
achievable
○Instant request serving

9. DynamoDB: When to
Move Out?

10. Reason 1: You Keep Throwing Money at it
You know how much you pay, very little about why?
■Writes are considerably more expensive than Reads
■Single table design → More indexes → Higher price/ops
■Global Tables, Dynamo Streams, S3, DAX, Streams… Woot!

11. Reason 2: Throttling
Also known as ProvisionedThroughputExceededException :
■Force you to back-off, introducing a latency penalty
■Far easy to hit
■Non-tunable load shedding mechanics

12. Reason 3: You know what DAX stands for
… and now you have two different animals to manage! :-)
■Doesn't sustain single-digit millisecond latencies at scale
■Cache helps, but comes with its own nuances:
○Write to DDB → Read from cache → Stale read!
○Writes are still synchronous
○No tightly coupling: Strongly consistent reads still require Dynamo
■Adds latency!

13. Reason 4: Limits, Troubleshooting & Observability
Common blockers:
■400KB Item size limit
■Local Secondary Indexes require… Re-creating the table?
■Developer Flexibility: DynamoDB Local?
■Little integration off AWS ecosystem
■Single-table organization & Querying inflexibility

14. Reason 5: Auto-scaling
No silver bullet, and still requires thorough planning:
■Avoids provisioning for peak capacity, BUT;
■Works best for gradual increases or decreases in traffic
■Burst capacity handles occasional spikes
AWS DynamoDB Auto Scaling is not a magic bullet

15. DynamoDB: How to
Move Out?

16. Query Language
Supported protocols:
■CQL – Binary protocol
○Native load balancing
○Parallel Request Multiplexing
○Prepared statements, token/shard awareness…
■DynamoDB API – JSON over HTTP(S)
○Requires a load balancer
○Drivers tend to need to open more connections
○No notion of prepared statements nor consistent hashing

17. Migration Nutshell
Client
Writes / Reads
Enable DynamoDB
Streams
Reads Writes
Consume Changes
Sync Changes
Writes / Reads
ScyllaDB Migrator

18. What Else?

19. Keep in touch!
Felipe Mendes
Technical Director
ScyllaDB

[email protected]
LinkedIn