Close-to-the-metal architecture handles millions of OPS with predictable single-digit millisecond latencies.
Learn MoreClose-to-the-metal architecture handles millions of OPS with predictable single-digit millisecond latencies.
Learn MoreScyllaDB is purpose-built for data-intensive apps that require high throughput & predictable low latency.
Learn MoreLevel up your skills with our free NoSQL database courses.
Take a CourseOur blog keeps you up to date with recent news about the ScyllaDB NoSQL database and related technologies, success stories and developer how-tos.
Read MoreCloud infrastructure is inherently elastic. But most databases don’t take full advantage of that elasticity.
New nodes can be provisioned fast, but there’s a significant lag before they can actually serve traffic – particularly when data distribution is static (e.g., determined exclusively by a hashing function). The new data distribution must be completed and synchronized across the cluster before new nodes can reliably service reads and writes.
Even with “autoscaling,” substantially increasing cluster capacity takes time. In addition, moving massive amounts of data is challenging because it may pin too many compute and IO resources, causing a performance bottleneck.
With ScyllaDB’s new tablets replication architecture, data is dynamically redistributed as the workload and topology evolve. New nodes can be spun up in parallel and start adapting to the load in near real-time. This means teams can quickly scale out in response to traffic spikes – satisfying latency SLAs without needing to overprovision “just in case.”
Adaptive load rebalancing further optimizes efficiency on top of ScyllaDB’s signature shard-per-core architecture, which is known for providing predictable low latency at scale (e.g., workloads exceeding 1M ops/sec).
The path forward is quite clear. Imagine these use cases:
You could be typeless. You won’t have to think about instance type ahead of time. Do you need a volume-based instance like the i3ens, or a throughput-based instance like i4is? What if the volume will vary over time? It won’t matter. The instances will adjust automatically.
You could be sizeless. That means you won’t have to worry about capacity planning when you start off. Start small and evolve from there.
You could also be limitless. You could start off anticipating a high throughput and then reduce it, or you could commit to a base and add on-demand usage if you exceed it.
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.