Seastar: the shard per core C++ framework under ScyllaDB, Redpanda and Ceph Crimson

Every operation that takes time is a future, and coroutines chain them

Seastar represents everything that can take time with one abstraction, the future: reading from the network, writing to disk, waiting on a timer, running a function on another core, even a long CPU bound computation. Because they share a type, these operations compose. C++ coroutines with co_await are the recommended way to write new code, and they interoperate with functions that return futures.

The catch is that co_await runs operations one after another. To overlap independent work, you fork and join explicitly:

#include <seastar/core/seastar.hh>
#include <seastar/coroutine/all.hh>
#include <seastar/coroutine/parallel_for_each.hh>

seastar::future<int> fetch(int key);

seastar::future<int> sum_two(int k1, int k2) {
    // Both fetches run concurrently.
    auto [a, b] = co_await seastar::coroutine::all(
        [&] { return fetch(k1); },
        [&] { return fetch(k2); });
    co_return a + b;
}

Code that awaits sequentially by habit gives up concurrency silently. Reviewers have to look for coroutine::all, parallel_for_each and max_concurrent_for_each where parallelism was intended.

Data belongs to one shard, so work travels to it

Seastar runs one thread per core, called a shard, and partitions memory between them. Each piece of data is owned by a single shard. Instead of locking data and touching it from whichever core needs it, you send the operation to the owning shard. On the fast path there are no locks, no contended atomics and no cache line bouncing. seastar::sharded<T> instantiates a service on every core and lets you call one, some or all shards, or map-reduce across them:

// Route each key to the shard that owns it.
seastar::future<> record(seastar::sharded<counter>& c, uint64_t key) {
    co_await c.invoke_on(key % seastar::this_smp_shard_count(), [] (counter& local) {
        local.hit();
    });
}

The consequence is a design constraint, not a library choice. Shared mutable state across threads, the default in many C++ servers, has no place here. Existing code built around a global cache or a locked map has to be restructured into per shard ownership before it can run on Seastar, and passing ownership between shards goes through foreign pointers.

No network threads or worker pools, so a blocking call stalls a whole shard

Seastar's architecture is symmetric. There are no dedicated network threads, I/O threads or worker pools. Every shard runs the full stack, networking, storage, application logic and a cooperative scheduler, for its own slice of the data. Adding cores adds capacity uniformly.

Cooperative scheduling means code has to yield. A function that blocks or computes for a long time without reaching a suspension point holds up every connection and every task on that shard. Seastar ships a reactor stall detector with backtraces to find these spots, and scheduling groups with configurable shares to isolate components such as background compaction from request handling. Semaphores bound how much concurrency any one component uses. None of this removes the obligation: third party libraries that make blocking system calls cannot be called directly on a shard without stalling it.

Disk I/O goes through io_uring or Linux AIO, tuned by iotune

File I/O in Seastar is DMA based and zero copy, using io_uring or Linux AIO. A disk I/O scheduler models the disk's capabilities, as measured by the iotune tool, to keep latency low while maximizing throughput. A per shard memory allocator avoids cross core contention on the allocation side.

Both named I/O backends are Linux interfaces, and the README names no alternative for other operating systems. Teams that develop on macOS or Windows should plan on Linux machines, containers or virtual machines for building and running Seastar code; the repository includes docker/ and kvm/ directories. The I/O scheduler also depends on iotune measurements of the target disk, so a deployment needs that measurement step for each class of storage it runs on.

Kernel bypass with DPDK is optional and documented on its own

Networking defaults to the POSIX stack, with TCP, UDP, SCTP and Unix domain sockets, plus TLS. Optionally, Seastar can run a native userspace TCP/IP stack over DPDK for kernel bypass. That path has its own documentation in doc/native-stack.md, doc/building-dpdk.md and README-DPDK.md, and the repository carries a dpdk entry alongside a .gitmodules file.

On top of the network layer sit an HTTP server and client, WebSocket, an RPC framework with streaming and compression, DNS resolution and JSON. The README's echo server example starts a listener on every core, with each shard accepting its own connections on the same port and serving each in a lightweight fiber. Choosing DPDK adds a separate build and hardware setup that the POSIX stack avoids, so it is a decision to make only after the default stack has been measured.

C++23 and C++26 only sets a high bar for toolchains

Seastar is written in modern C++ and supports C++23 and C++26. Projects pinned to an older language standard or an older compiler cannot consume it. The README itself carries no build commands; building and using Seastar in your own project goes through BUILD.md.

The top level of the repository shows how many build paths exist: CMakeLists.txt with a cmake/ directory, configure.py, a checked in build.ninja, cooking.sh with cooking_recipe.cmake, seastar_cmake.py, install-dependencies.sh and a pkgconfig/ directory. HACKING.md and coding-style.md cover contribution, and test.py drives tests. For testing your own code, SEASTAR_TEST_CASE integrates with Boost.Test for asynchronous unit tests, alongside a microbenchmark framework and allocation failure injection. Prometheus metrics, a structured logger and I/O tracing handle observability.

No GitHub releases, so consumers build from master

The repository publishes no GitHub releases. Development lands on the master branch, and the last push was on October 29, 2026. There is no tagged version to depend on, no release notes to read before upgrading, and no semantic version to signal an API break.

Seastar powers ScyllaDB, Redpanda and Ceph Crimson, but a new consumer gets no packaged version to install. You have to work from source: vendor or submodule a specific commit, record it, and move forward deliberately. The consequence of tracking master without a pin is that an upstream change to an API your code depends on arrives without warning in your next build. Read the commit history between your pinned commit and the new one before every bump.

Editorial conclusion

Seastar fits teams writing a server in C++ that must use every core of a machine and are prepared to design around shard owned data, cooperative scheduling and futures from the start. It does not fit a project that wants to drop a library into an existing thread pool design, or one that needs tagged releases and older compilers. Before committing, read BUILD.md, confirm your toolchain handles C++23, and decide how you will pin a master commit.

Frequently asked questions

Official sources

1. Issues
2. License: Apache-2.0
3. Project website
4. README
5. scylladb/seastar on GitHub