scylladb is source available, CQL compatible, and fussy about its compiler

The licence file is named for source availability, not open source

The repository root carries a file called LICENSE-ScyllaDB-Source-Available.md, and the licence metadata for the project records NOASSERTION rather than a standard identifier. The README says nothing about licensing at all.

That combination answers the question people arrive with, and not in the way the Apache Cassandra comparison invites. Source available is not the same grant as an OSI approved licence, and the terms that distinguish them, whether they cover commercial use, redistribution or offering the software as a service, live entirely in that one file. Nothing in the documentation summarises them for you.

So the practical sequence is inverted from the usual evaluation. Do not assume compatibility with the Apache Cassandra ecosystem carries the same licence posture, and do not deploy on the strength of a README that does not mention licensing. Read the licence file first, because a deal that closes on performance and fails on terms wastes considerably more time than one that reads one document up front.

Building requires C++23, and the supported answer is a Docker image

The build prerequisites are stated bluntly: Scylla is fairly fussy about its build environment, requiring very recent versions of the C++23 compiler and of many libraries to build. HACKING.md carries the detail for developers.

The escape hatch is the frozen toolchain, a pre-configured Docker image that bundles recent versions of every required compiler, library and build tool. Its stated purpose is to avoid changing anything on your build machine, leaving you needing only Docker or Podman. The build itself is three commands:

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

For an operations team this reframes the requirement. It is not that your CI image needs a bleeding edge compiler, it is that you need a container runtime and disk for the image. Budget for that, and note that a contributor who tries to build natively with a distro toolchain is not taking a shortcut, they are attempting a path the project itself describes as difficult.

developer-mode exists because startup refuses hardware that is not tuned

The run command in the documentation is not the run command you would use in production:

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

The flag is explained directly. It disables the various checks Scylla performs at startup to ensure the machine is configured for maximum performance, and the documentation notes those checks are not relevant on development workstations. Here --smp 1 also allocates a single core and --workdir tmp keeps data files in that directory.

That flag is a diagnostic instrument. The same binary that starts instantly on a laptop is refusing to start because of the machine, not the code, and a development machine will pass checks a production node has to earn. The consequence for you is that a successful local start tells you almost nothing about whether your server configuration will be accepted.

So test early without the flag, on the hardware you intend to use. Discovering at cutover that Scylla will not start on your instance because of a startup check is an avoidable outage, and it is the kind that reads as a mysterious crash rather than a deliberate refusal.

DynamoDB compatibility is opt-in, and its caveats are deferred to the docs

Two compatibility claims appear near each other and they are not equally available. By default Scylla is compatible with Apache Cassandra and its API, CQL, which needs no configuration. Support for the Amazon DynamoDB API exists too, but the documentation is explicit that it needs to be enabled and configured in order to be used.

That layer is Alternator, and it has its own directory at the top of the tree with two dedicated documents behind it. The README defers both how to enable it and, more importantly, what its current compatibility is, plus any Scylla-specific extensions, to those files rather than stating a position.

So treat DynamoDB compatibility as a feature with a compatibility matrix you have not read yet, not as a settled guarantee. The shape of the trap is familiar: a migration target that appears to be a drop-in because the API matches, where the gaps live in extensions and edge behaviour that surface after the data is already moving.

If your plan is CQL only, this does not affect you and the default is exactly what you want. If Alternator is the reason you are considering Scylla, read alternator.md and the getting started guide before sizing the project.

No GitHub releases and a master default branch

The repository publishes no GitHub releases, so there is no release list to pin against and no artefact attached to a tagged version. The default branch is master rather than main.

Neither fact blocks anything on its own, and both together make version tracking your problem rather than the project's. Tools and scripts that enumerate releases will find an empty set. Anyone following the default branch gets whatever is currently at its head, which for a database means unreleased changes rather than a shipped build.

There is a hint about how versioning is handled: the tree contains a file named SCYLLA-VERSION-GEN, which suggests version strings are generated rather than typed into a manifest you can read from the repository root.

If you are pinning Scylla for production, take the version from an installation package or container you have actually deployed, not from the repository. Everything above applies to reading and building the source; running it means picking an artefact from whatever distribution channel you use, since the repository offers you no releases to choose between.

CI tests reproducible builds and nightly clang, so your compiler will drift

Two GitHub Actions workflows are linked from the testing section: one named reproducible-build.yaml and one named clang-nightly.yaml.

Those names say more about the project than the test counts do. A reproducible build check means the project intends the same source to produce the same output, which is a stricter goal than passing tests and depends on pinning the entire toolchain. The nightly clang workflow means the project tracks compiler changes as they land rather than waiting for annual releases, which is the other half of the same commitment.

The consequence for anyone building outside the frozen toolchain is that your compiler and theirs are on different schedules. A version that worked when you wrote your pipeline may break when they pick up a new clang, and you would experience that as an upstream change you did not make.

This is the strongest argument for the frozen toolchain over any custom build you were planning. The container pins the toolchain, so your build stops being a function of when you happened to run it.

Dependencies are vendored into the tree, so submodules are not optional

The first build command is a recursive submodule update, and the top-level listing explains why. Alongside Scylla's own directories for cql3, compaction, auth, audit, data_dictionary, dht, api, debug and the alternator layer, the tree contains vendored third-party code including abseil and c-ares, with .gitmodules and .gitattributes managing them.

This shapes what a checkout costs. The repository is not only Scylla, and a shallow clone or a clone that skips the recursive flag gives you a tree that looks complete and cannot build. The first command in the build sequence is there because without it the remaining two fail in confusing ways.

Two smaller files, ORIGIN and SCYLLA-VERSION-GEN, also sit at the root, alongside a file named .gitorderfile.

For a project of this size, disk and clone time are the practical costs to plan for. Budget for the full recursive checkout rather than discovering the requirement the first time the build fails on a missing header.

Editorial conclusion

ScyllaDB is worth evaluating when CQL compatibility lets you keep existing drivers and models and your workload is throughput bound. Before anything else, read LICENSE-ScyllaDB-Source-Available.md, since the repository does not summarise the terms and the metadata records no standard licence. Then decide whether Alternator matters to you or plain CQL suffices, plan on the frozen toolchain rather than your own compiler, and test --developer-mode off on real hardware early, because that flag is what suppresses the startup checks your laptop never has to pass.

Frequently asked questions

Official sources

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