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