Thanks! The idea is to build a highly replicated KV/column store for the edge: small Raft core for ordering, lots of async replicas. I have it running on a 30-node fanout in test/staging and am focusing on hardening (crash/recovery, backpressure) before production.
UnisonDB is a log-native database that combines storage and streaming into one system — no CDC, no Kafka, no separate message bus.
It uses WAL-based replication with B+Tree storage to fan out writes to 100+ edge nodes in sub-second latency. Every write is durable, queryable, and instantly available as a replication stream.
Built for Edge AI and distributed systems where data needs to live close to computation. Supports:
- Multi-model storage (KV, Wide-Column, LOB)
- Atomic multi-key transactions
- Real-time change notifications
- Namespace isolation for multi-tenancy
We benchmarked it against BadgerDB and BoltDB using redis-benchmark — results in the README show competitive write/read throughput with consistent replication performance even at 100+ concurrent relayers.
I’ve been experimenting with an idea that combines a database and a message bus into one system — built specifically for Edge AI and real-time applications that need to scale across 100+ nodes.
Most databases write to a WAL (Write-Ahead Log) for recovery.
UnisonDB treats the log as the database itself — making replication, streaming, and durability all part of the same mechanism.
Every write is:
* Stored durably (WAL-first design)
* Streamed instantly (no separate CDC or Kafka)
* Synced globally across replicas
It’s built in Go and uses a B+Tree storage engine on top of a streaming WAL, so edge nodes can read locally while syncing in real time with upstream hubs.
No external brokers, no double-pipeline — just a single source of truth that streams.
Writes on one node replicate like a message bus, yet remain queryable like a database — instantly and durably.
GitHub: github.com/ankur-anand/unisondb
Deployment Topologies
UnisonDB supports multiple replication setups out of the box:
* Hub-and-Spoke – for edge rollouts where a central hub fans out data to 100+ edge nodes
* Peer-to-Peer – for regional datacenters that replicate changes between each other
* Follower/Relay – for read-only replicas that tail logs directly for analytics or caching
Each node maintains its own offset in the WAL, so replicas can catch up from any position without re-syncing the entire dataset.
UnisonDB’s goal is to make log-native databases practical for both the core and the edge — combining replication, storage, and event propagation in one Go-based system.
I’m still exploring how far this log-native approach can go. Would love to hear your thoughts, feedback, or any edge cases you think might be interesting to test.
I recently wrote about optimizing cache expiration for millions of TTL-based entries without melting the CPU.
The naive approach — scanning every key every second — works fine at small scale but collapses once you hit millions of entries.
So I implemented a Timing Wheel in Go — the same idea used in Kafka, Netty, and the Linux kernel — replacing the O(n) scan loop with an O(1) tick-based expiration model.
Here’s what I found when comparing both approaches at 10 million keys:
``` writer -> gRPC stream -> replica ```
A writable node owns the WAL. A replica connects over gRPC. The writer streams log records. The replica applies them in order.
We have added a a second replication path inside the Unisondb:
``` writer -> blob store -> replica ```
Project Repo: https://github.com/ankur-anand/unisondb
Looking forward to feedback and suggestions.