ScyllaDB delivers lower latencies at 50% of the cost of DynamoDB. Our close-to-the-metal architecture squeezes every ounce of power from the hardware for impressive price-performance. With the ScyllaDB Alternator, a native DynamoDB-compatible API, you can run your DynamoDB workloads anywhere – without code changes.
Save 50% or more – especially for write-heavy workloads, multi DC, or on-demand DynamoDB usage.
“Our overall cost is a combination of the efficiency that ScyllaDB provides in terms of the reduction in the number of nodes we use, and the cost structure that ScyllaDB provides. Together, this has given us a 5x improvement in cost.”
Sustain millions of OPS with single-digit ms P99 latencies – and no throttling.
“Time to handle index events went from ~80ms with DynamoDB to ~3ms with ScyllaDB. That meant one-eighth the infrastructure usage for writes. The solution further reduced complexity for iFood, resulting in 40% less code.”
Run your DynamoDB applications on any cloud, bare metal or hybrid.
“This workload is quite performance sensitive, so getting quick responses from our database is key. Moving from DynamoDB to ScyllaDB saves us plenty of headaches, and it performs really well.”
ScyllaDB provides far better and more consistent performance than DynamoDB, with extremely low latencies and better handling of hot partitions, and no read or write limitations based on provisioned cost. While DynamoDB offers throughput guarantees, its latencies, especially p99 latencies, suffer in comparison to ScyllaDB. That’s because ScyllaDB is designed around asynchronous communications and a “shared nothing” shard-per-core architecture, allowing it to take full advantage of underlying modern multi-core, multi-CPU NUMA hardware.
ScyllaDB Cloud can be deployed either as Provisioned capacity or On Demand pricing models, allowing users flexibility to tackle workload changes across the year. High volume events, such as Holidays or sporting events, can be breezed through by scaling the cluster to adjust to those expected workloads.
Cost estimated only by server size and data egress charges. No hidden fees for features. Repairs and backups are included by default and can be adjusted to your needs, such as increasing or decreasing backup frequency and/or retention, or changing repairs’ pace.
Instead of focusing on autoscaling based on changing workloads, ScyllaDB allows for extreme scalability by rapidly scaling horizontally or vertically. Adding nodes to the cluster takes minutes with the Tablets technology. The scaling process incrementally adds compute resources to the cluster, increasing its computing power and ensuring lower latencies throughout the process.
ScyllaDB leverages a server-based deployment model, allowing users to understand the capacity of the cluster and adjust according to business needs. It also means the cluster is dedicated to the user’s workload, removing noisy neighbours and other concerns of shared environments. All computing resources are utilized to their full potential by ScyllaDB, efficiently using CPU, memory, disk and network resources.
Save on compute and storage costs by aggregating multiple tables/workloads on the same cluster. As multiple workloads are combined, you can reduce overall TCO with more efficient computing
With Workload Prioritization you can run concurrent applications at varying levels of priority and achieve maximum performance out of the system. You can run OLAP and OLTP workloads concurrently on the same table without interfering with critical path latency.
ScyllaDB compresses datasets by default but also supports multiple compression algorithms with tunable parameters to make compression more efficient for workload specific datasets. As a benefit from compression, disk storage savings are translated to cost savings as the overall storage utilization is decreased.
ScyllaDB implements an extremely efficient in-memory cache by default, for all workloads. It leverages OS-level memory to provide an efficient and integrated caching layer.
No separate API or developer/DBA intervention or external cache is required. Eliminate costs of ever-expanding cache layers in favor of ScyllaDB’s built-in cache.
The built-in cache removes any need for an external cache. Eliminate DAX, Memstore, Redis and any other caching layer in favor of ScyllaDB’s efficient built-in cache.
Run on any Public Cloud (AWS, GCP, Azure and others), Hybrid Cloud environments or On-prem. ScyllaDB will leverage the hardware it’s deployed on to its maximum capacity. Run on small to huge sized servers, adequate to your workload.
DynamoDB-API and CQL compatible. The DynamoDB API compatibility covers the vast majority of API calls. For the full list, check out the documentation.
Although ScyllaDB is a standalone deployment, it can integrate with serverless applications (such as AWS Lambda functions), k8s management layers (such as GCP’s GKE) and storage buckets for backups. You can also use AWS CloudFormation templates to deploy ScyllaDB on your own hardware.
In ScyllaDB, there are no separate charges for global tables, each individually configurable for global or local replication. With tunable Consistency Levels, applications can read/write to local or global consistency levels. Data egress and storage fees apply according to the workload and Replication Factor of the dataset.
With Consistency Levels, operations on tables can be Region-local (called LOCAL_QUORUM on ScyllaDB) or Global, similar to DynamoDB Multi-Region strong consistency (MRSC). This gives ScyllaDB users flexibility on choosing the consistency of queries, assessing tradeoffs at the statement level, at both read and write paths. Read global and write local, or vise-versa, you choose!
ScyllaDB handles intra-region failures gracefully by replicating data to multi Availability Zones within each Region. This grants 100% uptime even in the unlikely event of losing an AZ. Users have visibility into which Zones the clusters are deployed to, and can leverage Zone-aware drivers to route requests to local AZs to reduce network costs.
Yieldmo processes hundreds of billions of ad requests daily with subsecond latency. They adopted DynamoDB for its simplicity and stability, but faced rising costs, suboptimal latencies, and cloud provider lock-in. Hear why and how they migrated with ScyllaDB’s DynamoDB-compatible API.
GE Healthcare needed to take their AWS-based AI platform on-premises to run within hospitals’ networks. By moving from DynamoDB to ScyllaDB and leveraging ScyllaDB Alternator, they accomplished this without changing their application.
Zee, a leading media and entertainment company that serves nearly 1.3 billion viewers in 190 countries, moved from DynamoDB to ScyllaDB so they can handle an increased volume of database traffic faster and at significantly lower costs.
Digital Turbine, a mobile app provider, recently entered into a strategic partnership with Google for their Android ecosystem. ScyllaDB enables them to move their DynamoDB workloads as part of this ambitious cloud migration. Digital Turbine used ScyllaDB Alternator to migrate their DynamoDB apps without moving away from the DynamoDB API.
In this DynamoDB Cost Optimization masterclass, you learn about practical strategies and AWS alternatives from distributed database experts.
Use Alternator when:
For example, you would want to use Alternator:
ScyllaDB is not a pure “drop-in replacement” for DynamoDB because:
It’s better to think of ScyllaDB as a “near drop-in replacement.” All database migrations require some changes, but minimal work is required here. For example: Digital Turbine switched from DynamoDB to ScyllaDB in just two weeks.
Also, note that while DynamoDB uses a single endpoint (dynamodb.<region_name>.amazonaws.com). With ScyllaDB Alternator, you can use one of our load balancing libraries or implement a server-side load balancer.
Autoscaling has two main drawbacks:
Autoscaling usually is not required. A small ScyllaDB cluster can handle 10,000-100,000 operations per second. A medium-sized cluster can exceed 1 million operations per second. Instead of autoscaling, it’s best to provision your cluster to handle your peak load. And ScyllaDB’s “tablets” replication to enable fast scaling when necessary.
ScyllaDB uses a row-based cache that matches DAX’s speed but works differently in two key ways:
These differences give ScyllaDB:
Migration is usually straightforward:
There’s also a Spark-based ScyllaDB Migrator to facilitate end-to-end migrations.
If you move to CQL, code refactoring is required. If you use ScyllaDB Alternator, you don’t need to transform data during the migration or change application code.
The ScyllaDB Alternator Compatibility page provides a detailed look at which DynamoDB features aren’t yet available. Remember: Even if a feature isn’t in the DynamoDB API, ScyllaDB might offer another way to do the same thing. If you need a specific missing feature for your project, let us know!
Apache® and Apache Cassandra® are either registered trademarks or trademarks of the Apache Software Foundation in the United States and/or other countries. Amazon DynamoDB® and Dynamo Accelerator® are trademarks of Amazon.com, Inc. No endorsements by The Apache Software Foundation or Amazon.com, Inc. are implied by the use of these marks.
