UnisonDB

Hi HN,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 Ideas1. Storage + Streaming = One System — no CDC, no Kafka, no sidecar pipelines2. B+Tree-Backed — predictable reads, zero compaction overhead3. Multi-Model — KV, wide-column, and large objects (LOB) in one atomic transaction4. Replication-Native — WAL streams via gRPC; followers tail in real time5. Reactive by Design — every write emits a ZeroMQ notification6. Edge-Friendly — replicas can go offline and resync instantlyPerformance & 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 DetailsWritten in GoFlatBuffers for zero-copy serializationgRPC for streaming replicationGitHub: https://github.com/ankur-anand/unisondb