ScyllaDB vs. DynamoDB: 5 Minute Demo

This demo compares ScyllaDB and DynamoDB in terms of elasticity, latency, and cost efficiency. It highlights how ScyllaDB scales faster, eliminates the need for external caching, avoids per-table capacity management, and enables workload prioritization—all while running on any cloud or on-prem.

***

Alright, so how do ScyllaDB and DynamoDB compare? Let's talk about that. 

What we are looking at here is the ScyllaDB Monitoring showing we have a 3-node cluster sustaining about 500K OPS. Unlike DynamoDB, where they provision individual tables and manage different capacity settings for each, in ScyllaDB you simply provision a single cluster, and a single cluster is able to service traffic for multiple tables at once. So in ScyllaDB, there's no such thing as managing on-demand or provisioned capacity on a per table basis. And what we are seeing now is that each CPU assigned to the ScyllaDB cluster was handling over 5K OPS.

Because a ScyllaDB deployment runs dedicated to you, we also never throttle you down, which means that you can scale pretty much indefinitely as much as you need. However, what about elasticity? After all, we know server resources are limited. Well, DynamoDB users often rely on autoscaling to automatically adjust traffic patterns to accommodate gradual traffic growth. And, as we are seeing now on the screen, ScyllaDB scales even faster than DynamoDB. So just like that, in just a minute, we doubled your existing cluster capacity, and we are now free to double traffic. 

What about latencies? We are going to see about that shortly, but you can see that the database worked really nicely and very fast to balance out the incoming workload across the new replicas, which just joined the cluster. And latencies were kept steadily low. Right after the scaling operation, they went back to nominal levels. 

Here's another plus ScyllaDB has compared to DynamoDB: we have our own cache implementation. You no longer need to worry about using ElastiCache or DynamoDB Accelerator to keep your latencies under control. Just ditch your cache and enjoy all the cost savings and simplified application development for once and for all. 

ScyllaDB is also smart enough to prefer replicas with a hot cache over colder replicas. This, of course, helps with ensuring that your tail latencies are kept under control. 

After the scaling is complete, we can see now that our cluster is pretty idle. So let's create a bit more noise here. I scaled our traffic, and we are going to try to reach 1M OPS since we've doubled our cluster capacity. As we are seeing, traffic starts to ramp up and boom,  that's it: 1M OPS. That's simple. 

And so here’s a question to you, how much would such a workload cost in AWS DynamoDB? I highly encourage you to check out AWS’s own calculator and run the numbers by yourself. And of course, you may say: Well, Felipe, 1M requests per second is a bit insane. I don't have anything like that. And that's fine, as with ScyllaDB you can pretty much scale as you go, start small and then add capacity as needed. 

This is also the perfect time for me to talk about workload prioritization. So now what we've done here is we started a secondary workload in parallel to the one which is consuming 1M OPS. Oftentimes, your organization may have tens, hundreds, even thousands of DynamoDB tables, each with varying characteristics. Workload prioritization allows you to define different priorities on a per-workload basis. If there is resource contention, the database will prioritize your requests according to the levels you defined upfront. 

So what are we seeing here in the ScyllaDB Advanced dashboard? We have a real-time workload and a secondary one. The real time workload is receiving 10X more CPU capacity than our secondary workload. 

Our next and final step is, of course, let's scale our workload back down. After we reached 1M OPS, our workload will then get back to its steady state of 500K OPS, and then we are, of course, going to remove nodes from the cluster. So, of course, the opposite process will take place in under just a few minutes. 

And this is pretty much what I wanted to show you. As a reminder. ScyllaDB is also cloud-agnostic, so you may run it pretty much anywhere, even across multiple clouds and even on-prem, which, of course, is something you are unable to do with DynamoDB. And as you can see, boom, just like that, we are scaled down and are back to steady state. 

So if you are interested in learning more about ScyllaDB and how we can help you reduce your DynamoDB spend, please reach out to us at ScyllaDB.com,