ScyllaDB: C++ NoSQL Database Compatible with Cassandra and DynamoDB

What ScyllaDB Replaces and Who It Is For

ScyllaDB is a wide-column NoSQL database designed to replace Apache Cassandra in deployments where Cassandra's Java Virtual Machine overhead is the limiting factor. The README describes the core proposition as a shared-nothing approach that increases throughput and storage capacity to realize order-of-magnitude performance improvements and reduce hardware costs. This means ScyllaDB accepts the same Cassandra Query Language queries, the same drivers, and the same topology configurations that existing Cassandra applications already use.

The target audience is engineering teams running high-write, low-latency workloads: time-series data, event logs, sensor streams, and similar patterns that fit the wide-column model. Teams already on Cassandra are the clearest fit because ScyllaDB's CQL compatibility reduces migration risk to the application layer. A team starting a new project is a secondary audience, but only if the wide-column model matches the intended access patterns.

ScyllaDB also provides an optional DynamoDB-compatible API called Alternator, aimed at teams migrating workloads off Amazon DynamoDB. The README points to docs/alternator/alternator.md for compatibility details and to docs/alternator/getting-started.md for setup instructions. Alternator is not enabled by default and must be configured explicitly before it accepts connections.

How Seastar's Shared-Nothing Reactor Eliminates Lock Contention

The performance difference between ScyllaDB and Apache Cassandra originates in the Seastar framework's reactor model. Seastar assigns each CPU core its own event loop, its own memory partition, and its own I/O queues. A request that arrives on core 0 is processed entirely by core 0: it reads from core 0's memory arena, queues disk I/O on core 0's scheduler, and sends its response through core 0's network path. No lock is needed to coordinate with another core during a typical operation.

Apache Cassandra runs on the JVM with shared heap memory. Threads accessing the same in-memory data structure must synchronize, and the garbage collector periodically pauses all application threads. Both behaviors introduce latency spikes at the tail percentiles that ScyllaDB's architecture avoids by design.

The consequence is that ScyllaDB's throughput scales with the number of CPU cores on a node. Adding a core gives Scylla roughly one additional worker. On a JVM-based system, adding a core may increase contention on shared data structures rather than adding proportional capacity.

The trade-off is that Seastar's model requires the C++ implementation to route work to the correct core rather than relying on the OS scheduler. This makes the codebase more complex than a thread-per-request design, and it means that a hot partition (one whose data all maps to a single shard) will saturate one core while leaving others idle. This limitation is shared with Apache Cassandra; the mitigation, designing partition keys to distribute load evenly, is the same.

Building and Running ScyllaDB with the Frozen Toolchain

ScyllaDB requires a C++23 compiler and precise library versions documented in HACKING.md. Rather than asking developers to match these versions manually, the project provides dbuild: a wrapper that runs the build environment inside a pre-configured Docker image called the frozen toolchain. A developer needs Docker or Podman installed; the image supplies the compiler, libraries, and build tools.

The build sequence from the README:

$ git submodule update --init --force --recursive
$ ./tools/toolchain/dbuild ./configure.py
$ ./tools/toolchain/dbuild ninja build/release/scylla

The first command fetches the Seastar submodule and other dependencies. The second runs the Python configuration script inside the Docker image. The third compiles the release binary with Ninja, also inside the image.

Starting a single-node development server:

$ ./tools/toolchain/dbuild ./build/release/scylla --workdir tmp --smp 1 --developer-mode 1

The --smp 1 flag limits ScyllaDB to one CPU shard. The --developer-mode 1 flag disables startup checks that verify production-grade machine configuration: CPU frequency governors, disk scheduler settings, and network tuning. The README notes these checks are appropriate to skip on development workstations; they exist to enforce the hardware requirements for the shared-nothing architecture to deliver its promised throughput in production. To inspect all available startup options:

$ ./tools/toolchain/dbuild ./build/release/scylla --help

A developer who built ScyllaDB with dbuild must also run it with dbuild, because the binary is linked against the toolchain image's libraries rather than the host system's libraries.

Cassandra CQL Compatibility and the Alternator DynamoDB Layer

ScyllaDB's default wire protocol is CQL, the same protocol Apache Cassandra exposes. Any driver written for Cassandra connects to ScyllaDB without modification. Keyspace management, replication factors, compaction strategies, and consistency levels follow the same semantics. A team migrating from Cassandra to ScyllaDB typically changes nothing in application code; the operational differences belong to the database administrators and platform engineers.

The Alternator layer is a separate code path that accepts DynamoDB API requests. The README states that Alternator needs to be enabled and configured before it accepts connections. The configuration details and current compatibility surface are documented in docs/alternator/alternator.md. The README also mentions ScyllaDB-specific extensions to the DynamoDB API that have no direct equivalent in Amazon's implementation.

Both APIs can coexist on a single ScyllaDB node, but the README does not document a supported configuration where some nodes in a cluster handle only CQL traffic and others handle only Alternator traffic. Teams planning a partial migration from DynamoDB or Cassandra to ScyllaDB should verify the current documentation at docs.scylladb.com before committing to a mixed-API architecture.

Cases Where ScyllaDB Is the Wrong Database

The shared-nothing architecture improves average throughput, but it does not protect against hot partitions. When a single partition key receives a disproportionate share of requests, all of that traffic routes to one CPU shard. That shard becomes the bottleneck while other cores remain idle. Because each shard runs independently with its own queue, a saturated shard cannot borrow capacity from neighboring shards the way a thread pool can reassign idle threads.

Building from source requires Docker or Podman. A team without containerization in its build pipeline must install it before using the frozen toolchain. The repository does provide documentation for building Docker images in dist/docker/redhat/README.md, but that path is also Docker-dependent.

ScyllaDB is not the right database for workloads that require multi-partition ACID transactions, SQL joins, or flexible document schemas. The CQL data model requires designing tables around specific query patterns at schema creation time. A table that needs to support a query pattern that was not anticipated at design time requires adding another table or a schema change, both of which carry compaction and I/O costs on a large cluster.

Teams building greenfield applications that do not have an existing Cassandra or DynamoDB dependency should evaluate whether the wide-column model is actually the best fit for their access patterns before choosing ScyllaDB.

ScyllaDB vs Apache Cassandra: the Operational Difference

The comparison is direct because ScyllaDB positions itself explicitly as a Cassandra replacement. The central implementation difference is runtime: Apache Cassandra runs on the JVM; ScyllaDB runs as a native C++ process. The JVM brings managed memory and garbage collection; ScyllaDB relies on the Seastar runtime and the developer to manage memory without pauses.

For operations teams, the day-to-day tooling difference is significant. Diagnosing a Cassandra performance problem involves JVM profilers, heap dumps, and GC logs. Diagnosing a ScyllaDB performance problem involves Linux perf, gdb, and Seastar's own diagnostic tools. The skill sets required are different, and a Cassandra operations team migrating to ScyllaDB should plan for this transition.

For application developers, the migration cost is low because the CQL wire protocol is identical. The same schema, the same driver configuration, and the same query patterns apply. The operational differences show up only at the infrastructure layer.

License, Maintenance, and Upgrade Cost

The license file in the repository root is named LICENSE-ScyllaDB-Source-Available.md. That name indicates a source-available license rather than a standard Open Source Initiative-approved license. The terms that govern which uses are permitted, which require a commercial agreement, and what obligations apply to modifications are documented at scylladb.com rather than in the repository itself. A team evaluating ScyllaDB for production deployment should read those terms before integrating it.

The last push to the repository was on 2026-09-27. The repository is not archived. The project has no GitHub releases; ScyllaDB uses a separate release process documented on the ScyllaDB website.

Upgrading ScyllaDB involves a dependency on the frozen toolchain Docker image. The toolchain image version is pinned in the repository; upgrading the compiler or changing the base operating system requires waiting for an updated toolchain image before rebuilding. A team running ScyllaDB in production should track the toolchain image version as a dependency and account for its update cadence in upgrade planning.

Editorial conclusion

Teams running Apache Cassandra who need higher throughput per node without changing application code have a clear migration path in ScyllaDB: the CQL compatibility means most Cassandra drivers connect without modification. Teams that need ACID transactions across multiple partitions, relational joins, or a document model should choose a different database. Before adopting ScyllaDB in production, verify the license terms at scylladb.com: the license file in the repository is named source-available, which is not an Open Source Initiative-approved license, and the permitted uses differ by deployment scenario.

Frequently asked questions

Official sources

1. Issues
2. Project website
3. README
4. scylladb/scylladb on GitHub