Show HN: UnisonDB – Log-native KV database that replicates like a message bus

For the past few months, I’ve been building UnisonDB — a log-native database where the Write-Ahead Log (WAL) is the database, not just a recovery mechanism.

I started this because every time I needed data to flow — from core to edge, or between datacenters — I ended up gluing together a KV database + CDC + Kafka.

It worked, but it always felt like overkill: too many moving parts for even small workloads, and too little determinism.

What is it?

UnisonDB unifies storage and streaming into a single log-based core. Every write is: • Durable (appended to the WAL), • Ordered (globally sequenced for safety), • Streamable (available to any follower in real time).

It combines B+Tree storage (predictable reads, no LSM compaction storms) with WAL-based replication (sub-second fan-out to 100+ nodes).

Key Ideas

1. Storage + Streaming = One System — no CDC, no Kafka, no sidecar pipelines

2. B+Tree-Backed — predictable reads, zero compaction overhead

3. Multi-Model — KV, wide-column, and large objects (LOB) in one atomic transaction

4. Replication-Native — WAL streams via gRPC; followers tail in real time

5. Reactive by Design — every write emits a ZeroMQ notification

6. Edge-Friendly — replicas can go offline and resync instantly

Performance & Tradeoffs 1. Write throughput is lower than pure LSM stores (e.g. BadgerDB) — because writes are globally ordered for replication safety. Deliberate tradeoff: consistency > raw write speed.

2. Still ~2× faster than BoltDB with replication enabled.

Tech Details

Written in Go

FlatBuffers for zero-copy serialization

gRPC for streaming replication

GitHub: https://github.com/ankur-anand/unisondb