The Database That Began With a Failed Operating System

The uncooperative program was Apache Cassandra. Around 2012, Dor Laor and Avi Kivity were working on an operating system for virtualization workloads, hoping to show that their approach could run applications faster than Linux. Most of their test programs obliged. Cassandra did not. That failure sent two people who knew hypervisors into the database business. The resulting company, ScyllaDB, still carries the fingerprints of that detour: an impatience with wasted hardware, a fascination with low-level scheduling, and a name borrowed from a sea monster.

First, a hypervisor. Then, a monster.

Laor and Kivity had met at Qumranet, where Kivity created KVM, the Linux virtualization technology that became a standard part of cloud infrastructure. After Qumranet was acquired by Red Hat, the pair wanted another hard systems problem. Their first answer was a new operating system. The database test changed the answer. In Laor's telling, Cassandra's distributed design was attractive, but the implementation left room for a different sort of engine. The team built ScyllaDB in C++ on Seastar, an asynchronous framework designed to let modern CPUs and storage do more useful work.

The central trick is called shard-per-core. Give each CPU core its own portion of the work and data, then keep cores from tripping over a shared lock. That is a simplification, but it captures the practical ambition. A customer can ask for enormous throughput; the more revealing request is that the slowest few queries remain acceptably quick while the system is busy. Engineers call that tail latency, often measured at the 99th percentile, or p99. Users call it the app feeling broken only sometimes.

A fast average is charming. A quiet p99 is what lets the on-call engineer sleep.The problem ScyllaDB chose to sell against

Discord provides the hard numbers

Discord's messages database makes a good test because chat is uneven. A tiny server and a stadium-sized server do not send the same number of messages. In its 2023 engineering account, Discord described a Cassandra cluster that had grown from 12 nodes in 2017 to 177 by early 2022, with trillions of messages. Popular channels created hot partitions. Compaction lagged. Garbage-collection pauses caused latency spikes. Operators sometimes took nodes out of service just to let them catch up, a routine they called the “gossip dance.” It is a memorable name for an expensive way to spend a weekend.

Discord switched its messages store in May 2022. Afterward it reported 72 ScyllaDB nodes, down from 177 Cassandra nodes. Historical-message reads moved from a p99 range of 40 to 125 milliseconds to about 15 milliseconds. Insert p99 moved from a variable 5 to 70 milliseconds to about 5. Those are Discord's production measurements, not a promise for anyone else's workload. Its new nodes also had larger disks, and the migration involved work on services around the database. The numbers are useful because the operator published both the before and the after.

The story did not end at the cutover. In 2026, Discord said ScyllaDB held messages, channels, servers and much of its user data across dozens of clusters. Its seven-person persistence team had to build an internal control plane to automate the work of running hundreds of database nodes. That is the honest companion to the migration statistic: a high-performance engine can reduce one kind of toil while scale invents another. Discord has also published an authentication outage involving a ScyllaDB cluster during an operating-system upgrade and a degraded disk. Architecture helps; operations still matter.

The bill has three lines

ScyllaDB fits where Apache Cassandra, Amazon DynamoDB or another operational data store might sit: under messaging, recommendations, user profiles, event data and similar applications that need many predictable reads and writes. It speaks Cassandra's CQL interface and offers a DynamoDB-compatible API called Alternator. Compatibility can spare an application a wholesale rewrite, but the word is not a migration plan. Teams still need to check schemas, drivers, consistency expectations, data movement and the queries that matter most.

The business model is familiar to infrastructure buyers: free adoption below a limit, then paid software, support or managed service. ScyllaDB Cloud pricing depends on provisioned resources, storage and service tier. The free self-managed Enterprise tier is capped at 10 TB of total storage and 50 vCPUs. That detail matters because ScyllaDB changed its license path in 2025. The final planned AGPL open-source line is 6.2.x; newer Enterprise releases are source-available. The code remains visible, but “open source” is no longer an accurate blanket description of the current database release.

The second line of the bill is operator time. The third is the cost of slowing a customer down. Sprig's 2026 customer account is instructive: its visitor data had grown into a 15-billion-row Postgres table, while ClickHouse and Redis handled other traffic. The company reported p99s around 50 milliseconds and projected more writes. After moving the workload to ScyllaDB, it reported latency four to eight times better than its Redis setup. That result belongs to Sprig's architecture; it does not make every Postgres table a candidate for replacement.

A database wants more jobs

The market has moved since the first Cassandra benchmark. ScyllaDB now pitches itself for operational AI workloads as well as conventional real-time applications. Medium described using it for recommendations at roughly one million operations per second. Vector search became generally available in late 2025, and the September 2026 release added full-text search with BM25 scoring, plus a preview of an object-storage backend. These additions try to keep more retrieval work near the operational data. Whether that simplifies a particular stack depends on its search needs and query patterns.

The team's own scaling problem produced another change. Kivity said moving data from very large nodes could once take a day, making expansion before a traffic event a nerve-racking exercise. The newer tablet architecture splits data into smaller units that can be redistributed in parallel; X Cloud packages that with managed autoscaling. The product announcement describes rapid scaling, but a prospective customer should benchmark its own traffic, size its data carefully and price both steady use and spikes. ScyllaDB's advantage is strongest when predictable access paths and high request volume justify that homework. It is less natural for arbitrary joins, ad hoc exploration or transactions spanning many partitions.

The lesson of the origin story is pleasantly unromantic. Laor and Kivity did not discover a market by claiming everything was slow. They found one stubborn workload, followed it down to the hardware, and built around the part that resisted improvement. The trick a reader can copy is the sequence: find the painful tail, measure it in production, model the cost of maintaining it, and test a different architecture against that exact pain. A sea monster is optional.