Why ScyllaDB is an Excellent DynamoDB Alternative
ScyllaDB’s DynamoDB-compatible API provides five key benefits to DynamoDB users:
1. Lower TCO: Compared to ScyllaDB, DynamoDB is very expensive at scale. Companies spend a great deal of time and engineering effort in their attempts to reduce their DynamoDB costs. DynamoDB charges separately at different rates for read and write transactions (RCUs and WRUs), global tables, and an external cache (DynamoDB Accelerator, DAX) – all of which are proprietary. ScyllaDB’s design efficiency allows developers to use significantly fewer resources for the same task or workload. According to our ScyllaDB vs DynamoDB benchmark, users can expect to save 80% – 93% overall to support the same workload (5x-14x less expensive). Because of its highly performant design ScyllaDB also eliminates the cost of any in-memory cache (such as DAX).
2. Performance: 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” architecture, allowing it to take full advantage of underlying modern multi-core, multi-CPU NUMA hardware. While both DynamoDB and ScyllaDB have the capability to scale, we believe in giving you the most efficient performance possible, getting the highest utility of the underlying infrastructure you’re running on.
3. Scalability: Many DynamoDB users are torn between provisioned and far more expensive OnDemand options. Provisioned may be less costly upfront, but bursty or spiky workloads cause bounces between under-provisioning and over-provisioning, oscillating between throttling and wasted budget. The result with both OnDemand and Provisioning DynamoDB is often “Bill Shock.” ScyllaDB uses a combination of Tablets and Raft consensus algorithms for rapid and safe topology changes (provisioning, expanding, and contracting clusters and their requisite nodes) in parallel, rapidly delivering the ability to feed in and query data – critical to handling variable workloads. For more on how ScyllaDB has been designed for elastic scalability, see the ScyllaDB architecture overview.
4. No Vendor Lock-in: You can now run your DynamoDB workloads on any cluster: on-premises, on your favorite public cloud, a hybrid cloud deployment, or using our ScyllaDB Cloud Database as a Service (NoSQL DBaaS) on AWS or Google Cloud. Our DynamoDB-compatible API interface is an excellent DynamoDB source alternative.
5. Openness: Operationally, ScyllaDB can run on any suitable server cluster regardless of location (on-premises, in any private or public cloud, or on our own DBaaS, ScyllaDB Cloud) or deployment method (bare metal, containerized, virtualized, or deployed in pods via Kubernetes). This contributes to the user’s lower TCO by allowing deployment flexibility in line with their existing operations. ScyllaDB also uses popular projects for its monitoring stack (Grafana, Prometheus) making it easy to use in or out of AWS, or to integrate to a 3rd party monitoring system like DataDog.
ScyllaDB as a Platform for a DynamoDB-compatible API
Due to their different data access methods, switching between ScyllaDB and DynamoDB had been non-trivial to users. That’s because ScyllaDB initially used the Cassandra Query Language (CQL), which is syntactically akin to Structured Query Language (SQL), while DynamoDB data types require Javascript Object Notation (JSON) format for queries. (Learn more about the differences here.)
Based on ScyllaDB’s extensive experience in making API-compatible databases, a design principle for this project was that no Amazon DynamoDB API calls should need to be altered from the developer’s perspective. Instead, the database system needs to accept input from the client application in DynamoDB-compatible API format, and transparently translate it into appropriate calls to the underlying database.
Resultant data from queries would also need to be returned to users in the DynamoDB-compatible format. All users need to do is deploy ScyllaDB, enable our DynamoDB-compatible API in scylla.yaml, and then point their current DynamoDB client applications to the ScyllaDB cluster. Additionally, we offer ScyllaDB Migrator, an Apache Spark™-based streaming solution for DynamoDB data migration into ScyllaDB.
Using ScyllaDB’s DynamoDB-Compatible API, Alternator
Our DynamoDB-compatible API solution is available in self-hosted and fully-managed deployment modesls. Our alternator.md and design doc provide detailed information of what’s supported and not yet supported today. In short, most standard applications will just work. ScyllaDB supports the same client SDKs, data modeling and queries as DynamoDB. Simply redirect HTTP/HTTPS port streams. With Alternator enabled on port 8000 (for example), every Scylla node listens for DynamoDB API requests on this port. These requests, in JSON format over HTTP, are parsed and result in calls to internal Scylla C++ functions – there is no CQL generation or parsing involved. Core functionality such as Key Table and Item Operations, Scans, and Filters are implemented. All attribute types, including nested documents implemented. The key difference is that you will be able to run your DynamoDB applications anywhere on any cloud or on-premise, using any VM, container, or bare metal configuration of your choosing.
However, there are some differences due to the ScyllaDB design for portability and dedicated operations – most notably in provisioning, scan ordering, load balancing, and write isolation policies. In most cases, DynamoDB apps and their users will not be aware of or impacted by these underlying differences. But there are exceptions; for example, DynamoDB app users would need to configure the client library for load balancing (still, no external component with an additional cost is needed), provisioning for DynamoDB as a shared cloud service is quite different than provisioning for a dedicated service like ScyllaDB where you need to consider the number and size of your cluster and its nodes rather than throughput. For more on the differences, see the ScyllaDB Alternator documentation.
DynamoDB-compatible API on ScyllaDB Cloud — Our Managed Cloud Service
For many lean organizations, one of the most attractive features of DynamoDB is utilizing it as a completely managed Database as a Service (DBaaS). ScyllaDB Cloud (NoSQL DBaaS)
uses the robust ScyllaDB Enterprise release. It currently runs on AWS and Google Cloud, and you can utilize your own account to keep your existing AWS terms and discounts (also known as Bring Your Own Account, BYOA). Future updates to ScyllaDB Cloud will run on Azure as well. Try it today!
Kubernetes Operator
We have a production-ready version of ScyllaDB Operator so you can fully deploy and manage a ScyllaDB Alternator for DynamoDB-compatible database wherever you wish.
Simplified ScyllaDB to DynamoDB Migration!
To make the switch as easy as possible we’ve extended our online DynanmoDB migration tools to be relatively simple: just start streaming the changes from DynamoDB plus run a full scan. The ScyllaDB Spark Migrator project has been enhanced to support the ScyllaDb Alternator for DynamoDB-compatible API.
Contributing to the Open Source DynamoDB-Compatible API Project
ScyllaDB and the ScyllaDBAlternator for DynamDB-compatible API interface are true open source projects. We encourage those looking to contribute to review the source code and any known defects, and read our guidelines on how to add their own contributions. Developers looking to become open source contributors to the project are further encouraged to join the scylladb-dev mailing list, or to visit ScyllaDB’s Slack.
