DynamoDB and ScyllaDB share many similarities, but DynamoDB is a multi-tenant database, while ScyllaDB is single-tenant
The recent DynamoDB outage is a stark reminder that even the most reliable and mature cloud services can experience downtime.
Amazon DynamoDB remains a strong and proven choice for many workloads, and many teams are satisfied with its latency and cost. However, incidents like this highlight the importance of architecture, control, and flexibility when building for resilience.
DynamoDB and ScyllaDB share many similarities:
- Both are distributed NoSQL databases with the same “ancestor”: the Dynamo paper (although both databases have significantly evolved from the original concept).
- A compatible API: The DynamoDB API is one of two supported APIs in ScyllaDB Cloud.
- Both use multi-zone deployment for higher HA.
- Both support multi-region deployment. DynamoDB uses Global Tablets (See this analysis for more). ScyllaDB can go beyond and allow multi-cloud deployments, or on-prem / hybrid deployments.
- But they also have a major difference: DynamoDB is a multi-tenant database, while ScyllaDB is single-tenant.
Source: https://blog.bytebytego.com/p/a-deep-dive-into-amazon-dynamodb
Multi-tenancy has notable advantages for the vendor:
- Lower infrastructure cost: Since tenants’ peaks don’t align, the vendor can provision for the aggregate average rather than the sum of all peaks, and even safely over-subscribe resources.
- Shared burst capacity: Extra capacity for traffic spikes is pooled across all users.
Multi-tenancy also comes with significant technical challenges and is never perfect. All users still share the same underlying resources (CPU, storage, and network) while the service works hard to preserve the illusion of a dedicated environment for each tenant (e.g., using various isolation mechanisms).
However, sometimes the isolation breaks and the real architecture behind the curtain is revealed. One example is the Noisy Neighbor issue. Another is that when a shared resource breaks, like the DNS endpoint in the latest DynamoDB outage, MANY users are affected. In this case, all DynamoDB users in a region suffer.
ScyllaDB Cloud takes a different approach: all database resources are completely separated from each other. Each ScyllaDB database is running:
- On dedicated VMs
- On a dedicated VPC
- In a dedicated Security Group
- Using a dedicated endpoint and (an optional) dedicated Private Link
- Isolated authorization and authentication (per database)
- Dedicated Monitoring and Administration (ScyllaDB Manager) servers
When using ScyllaDB Cloud Bring Your Own Account (BYOA), the entire deployment is running on the *user* account, often on a dedicated sub-account. This provides additional isolation.
The ScyllaDB Cloud control plane is loosely coupled to the managed databases. Even in the case of a disconnect, the database clusters will continue to serve requests. This design greatly reduces the blast radius of any one issue.
While the single-tenant architecture is more resilient, it does come with a few challenges:
- Scaling: To scale, ScyllaDB needs to allocate new resources (nodes) from EC2, and depend on the EC2 API to allocate them. Tablets and X Cloud have made a great improvement in reducing scaling time.
- Workload Isolation: ScyllaDB allows users to control the resource bandwidth per workload with Workload Prioritization (docs | tech talk | demo)
- Pricing: Using numerous optimization techniques, like shard-per-core, ScyllaDB achieves extreme performance per node, which allows us to provide lower prices than DynamoDB for most use cases.
To conclude: DynamoDB optimizes for multi-tenancy, whereas ScyllaDB favors stronger tenant isolation and a smaller blast radius.
