Shashank Sati

I've been building SevenDB for most of this year and I wanted to share what we're working on and get genuine feedback from people who are interested in databases and distributed systems.

> what problem we're trying to solve

A lot of modern applications need live data: dashboards that should update instantly, tickers and feeds, systems reacting to rapidly changing state.

Today, most systems handle this by polling—clients repeatedly asking the database “has this changed yet?”. That wastes CPU, bandwidth, and introduces latency and complexity. Triggers do help a lot here, but as soon as multiple machines and low latency applications enter, they get dicey.

Scaling databases horizontally introduces another set of problems:

• Nondeterministic behavior under failures
• Subtle bugs during retries, reconnects, crashes, and leader changes
• Difficulty reasoning about correctness

SevenDB is our attempt to tackle both of these issues together.

> 1. reactive by design

Instead of clients polling, clients can subscribe to values or queries. When the underlying data changes, updates are pushed automatically.

“Tell me whenever this value changes” instead of “polling every few milliseconds”

This reduces wasted work (compute, network and even latency) and makes real-time systems simpler and cheaper to run.

> 2. deterministic execution

The same sequence of logical operations always produces the same state.

Why this matters:

• Crash recovery becomes predictable
• Retries don't cause weird edge cases
• Multi-replica behavior stays consistent
• Bugs become reproducible instead of probabilistic nightmares

We explicitly test determinism by running randomized workloads hundreds of times across scenarios like:

• Crash before send / after send
• Reconnects (OK, stale, invalid)
• WAL rotation and pruning
• 3-node replica symmetry with elections

If behavior diverges, that's a bug.

> 3. raft-based replication

We use Raft for consensus and replication, but layer deterministic execution on top so that replicas don't just agree—they behave identically.

The goal is to make distributed behavior boring and predictable.

> the interesting part

We're an in-memory KV store. One of the fun challenges in SevenDB was making emissions fully deterministic. We do that by pushing them into the state machine itself. No async “surprises,” no node deciding to emit something on its own. If the Raft log commits the command, the state machine produces the exact same emission on every node. Determinism by construction.

But this compromises speed significantly, so what we do to get the best of both worlds is:

On the durability side: a SET is considered successful only after the Raft cluster commits it—meaning it's replicated into the in-memory WAL buffers of a quorum. Not necessarily flushed to disk when the client sees “OK.”

Why keep it like this? Because we're taking a deliberate bet that plays extremely well in practice:

• Redundancy buys durability — In Raft mode, our real durability is replication. Once a command is in the memory of a majority, you can lose a minority of nodes and the data is still intact.
• Fsync is the throughput killer — Physical disk syncs (fsync) are orders slower than memory or network replication. Forcing the leader to fsync every write would tank performance.
• Disk issues shouldn't stall a cluster — If one node's storage is slow or semi-dying, synchronous fsyncs would make the whole system crawl. By relying on quorum-memory replication, the cluster stays healthy as long as most nodes are healthy.

So the tradeoff is small: yes, there's a narrow window where a simultaneous majority crash could lose in-flight commands. But the payoff is huge: predictable performance, high availability, and a deterministic state machine where emissions behave exactly the same on every node.

In distributed systems, you often bet on the failure mode you're willing to accept. This is ours.

> benchmarks

SevenDB benchmark — GETSET
Target: localhost:7379, conns=16, workers=16
keyspace=100000, valueSize=16B, mix=GET:50/SET:50
Warmup: 5s, Duration: 30s

Ops:        total=3,695,354  success=3,695,354  failed=0
Throughput: 123,178 ops/s
Latency:    p50=0.111ms  p95=0.226ms  p99=0.349ms  max=15.663ms
Reactive:   p50=0.145ms  p95=0.358ms  p99=0.988ms  max=7.979ms