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 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
Comments URL: https://news.ycombinator.com/item?id=45784331
Points: 1
# Comments: 0
Source: unisondb.io
