SevenDB: A high-performance reactive, scalable, in-memory database

SevenDB is a reactive database, building on DiceDB and extending it with a stronger foundation for deterministic subscriptions, bucket-based sharding, and compute scalability.

SevenDB aims to be the foundation for reactive applications at scale — where subscriptions are as reliable as reads and as scalable as writes.

you can run this using make bench , here are the single-machine results on my ryzen-7 5700

SevenDB speaks the same RESP protocol as Redis. That means you can connect to it with any existing Redis client (redis-cli, ioredis, redis-py, etc.) and use standard commands, with extra power from reactive subscriptions.

Clone and build SevenDB:

By default, the server listens on localhost:7379.

Best way to connect to sevenDB is through SevenDB-cli

SevenDB supports familiar Redis-style commands:

Unlike Redis, subscriptions in SevenDB are first-class operations.

Now, when user:1 changes:

Your subscription immediately receives:

Some advanced features, like durable outbox delivery and EMITRECONNECT, require the Emission Contract to be enabled.

• CLI flag:

  sevendb --emission-contract-enabled=true \ --emission-notifier-poll-ms=5 # optional: tune notifier poll interval

• Config (sevendb.yaml):

  emission-contract-enabled: true emission-notifier-poll-ms: 5 # optional

With this enabled, emissions are written to a raft-backed outbox and delivered deterministically by a per-bucket notifier.

If your client disconnects and later reconnects, you can resume emissions without gaps using EMITRECONNECT.

• Purpose: tell SevenDB the last commit index you fully processed for a given subscription, so the notifier can resume from the next index.
• Syntax: EMITRECONNECT key sub_id last_commit_index
• Returns:
  • OK <next_index> on success (resume from this next commit index)
  • STALE_SEQUENCE if the server has compacted past your index
  • INVALID_SEQUENCE if the provided index is invalid for this subscription
  • SUBSCRIPTION_NOT_FOUND if the subscription isn’t active for the key

Example (RESP/CLI style):

Notes:

• sub_id is the subscription identifier associated with your GET.WATCH (the client/fingerprint pair used by the server). If you’re using the official SevenDB client, it will surface this ID for reconnects.
• This feature is available when the Emission Contract is enabled; see the docs below for configuration and operational details.

SevenDB exposes lightweight emission metrics for visibility during development and ops.

• Per-shard/bucket breakdown: metrics are labeled by bucket (the internal shard ID) when the Emission Contract is enabled.
• Aggregate metrics are also exported for quick at-a-glance checks.

Options:

• Enable a Prometheus endpoint (off by default):

  sevendb \ --emission-contract-enabled=true \ --metrics-http-enabled=true \ --metrics-http-addr=":9090"

  Then scrape http://<host>:9090/metrics. Example metric names:

  • sevendb_emission_pending_entries{bucket="a"}
  • sevendb_emission_sends_per_sec{bucket="a"}
  • sevendb_emission_reconnects_total{bucket="a",outcome="ok|stale|invalid|not_found"}

  Config (sevendb.yaml):

  metrics-http-enabled: true metrics-http-addr: ":9090"

• Emit a compact log line every N seconds (off by default):

  sevendb --metrics-log-interval-sec=10

  You’ll see lines like:

  level=INFO msg=emission_metrics pending=0 subs=0 sends_per_sec=0 acks_per_sec=0 lat_ms_avg=0 reconnect_ok=0 reconnect_stale=0

Notes:

• Labeling per bucket enables per-shard analysis but adds minor bookkeeping overhead.
• The /metrics endpoint only includes SevenDB application metrics (no Go runtime by default) to keep output small and stable.

SevenDB's WAL normally buffers writes and flushes/fsyncs on an interval (--wal-buffer-sync-interval-ms). For many workloads this amortizes IO and is sufficient. You can opt a specific SET write into synchronous durability:

1. Enable the feature flag and WAL at startup:

2. Issue a durable write:

Behavior:

• Without DURABLE / SYNC: SevenDB appends the command to the WAL buffer and replies OK (fsync happens later).
• With DURABLE / SYNC: SevenDB flushes and fsyncs the WAL segment before replying OK, ensuring the change is on disk (subject to filesystem semantics) when acknowledged.
• If the WAL is disabled or the feature flag is off, the tokens are ignored and the write behaves as buffered.
• On fsync failure, the server returns an ERR wal sync failed: <reason> instead of OK.

Metrics:

• sevendb_set_durable_sync_total: count of SETs that forced an immediate WAL sync.
• sevendb_set_buffered_total: count of SETs written without a durability request.

Use this for critical keys (e.g., transaction commits, idempotency markers) without globally forcing synchronous writes.

Traditional databases excel at storing and querying, but they treat reactivity as an afterthought. Systems bolt on triggers, changefeeds, or pub/sub layers — often at the cost of correctness, scalability, or painful race conditions.

SevenDB takes a different path: reactivity is core. We extend the excellent work of DiceDB with new primitives that make subscriptions as fundamental as inserts and updates.

View the Design Plan PDF

Additional docs:

• WAL manifest, UWAL1, and integrity preamble
• Raft testing: deterministic and multi-machine
• Emission Contract architecture
• Emission} Contract – operations & config

See docs: Determinism: scope, harness, and how to run

Quick runs:

• Data is partitioned into buckets, each with its own Raft log, subscriptions, and notifier.
• A bucket is the atomic unit of replication, computation, and failover.(Update: Now Shards are the unit of replication , buckets as a raft group were too expensive)
• Subscriptions bind to the buckets that hold their data, ensuring updates are always ordered and consistent.

• Reactive computation is heavy — evaluating deltas and emitting them at scale.
• SevenDB spreads this load by sharding compute across buckets, with two modes:
  • Hot mode: every replica shadow-evaluates for instant failover.
  • Cold mode: only the notifier evaluates, others checkpoint for efficiency.
• This lets us trade failover speed vs CPU cost per bucket.

• SUBSCRIBE / UNSUBSCRIBE are first-class operations, logged like INSERT or UPDATE.
• Every subscription is replayable and deterministic, enforced by plan-hash checks.
• Failovers and replays always converge to the same state, eliminating divergence.

• Emissions aren’t ephemeral.
• Every computed delta is first written as an outbox entry into the bucket log, then sent.
• If a notifier crashes, the next one replays the outbox, guaranteeing no lost updates.
• Clients deduplicate using (sub_id, emit_seq) for “effective-once” delivery.

DiceDB gave us the foundation: a Redis-compatible, reactive engine with subscriptions. SevenDB extends it with:

• Buckets as the core sharding unit (data + compute + subscriptions all scoped per bucket).
• Epoch-aware sequencing (emit_seq) for gap-free ordering across migrations.
• Deterministic query plans and plan-hash logging to prevent drift.
• Notifier leases decoupled from Raft leadership, avoiding leader hotspots.
• Backpressure primitives (ack/window modes, coalescing, priority queues).
• Elasticity: split hot buckets to scale out, merge cold ones to scale in.

In short: DiceDB rethought data reactivity. SevenDB rethinks scalable, correct reactivity.

🚧 Early development — expect rapid iteration.