However, while users are finding it easy to start with DynamoDB, they soon find themselves in
vendor lock-in, because this API is only supported on Amazon. And when it quickly gets very
expensive (see for example this post), one cannot install their own setup of DynamoDB, let
alone move the application using the DynamoDB to another cloud or a private data center.
The goal of this proposal is to provide a DynamoDB implementation on top of Scylla. The
benefits to the users are avoiding vendor lock-in (Scylla is open-source and can be installed on
any cloud) and reduced cost because of Scylla’s world-famous efficiency and avoiding
Amazon’s cut. The reduced cost will be relevant even for users who choose to stay with
Amazon: In our blog post from several months ago, we demonstrated that Scylla is at least 7
times cheaper than DynamoDB (considering all costs, including VMs and even a commercial
Scylla license). So even if a DynamoDB front-end will add some overhead (and surely it will), we
expect to still have a significant cost advantage over DynamoDB. The biggest risk for the
performance (or cost) advantage of Scylla will be the need to accurately implement
DynamoDB’s query isolation guarantees, such as concurrent conditional writes, which may
require us to use LWT which may be slower than Scylla’s traditional read and write operations.
We’ll go into the concurrency issue in more detail below.
The goal of this document is to provide a detailed overview of DynamoDB and all its features,
with a focus on how it differs from Scylla and what we need to implement to provide DynamoDB
API support to Scylla, and which features are missing in Scylla for complete DynamoDB
support. Our understanding of DynamoDB stems from Amazon’s public documentation (we’ll
include links below) and public presentations made by Amazon engineers (notably this AWS