ankur-anand/unisondb

UnisonDB – A Log‑Native Real‑Time Database for Edge AI

What it is – UnisonDB is an open‑source, multi‑model database written in Go that treats its write‑ahead log (WAL) as the primary data source. Every write is persisted to a B+‑Tree store and streamed instantly to any number of replicas via gRPC or object‑store‑backed replication. The design targets edge‑first workloads where data must stay close to compute and be propagated to thousands of nodes with sub‑second latency.

Core ideas

• Log‑native: the WAL (implemented as the WALFS subsystem) is memory‑mapped, segmented and readable in real time. Replicas tail the log directly, so the same data that is stored is also the replication stream.
• Raft‑based writes: optional quorum writes give strong consistency and durability for primary nodes.
• Blob fan‑out: WAL segments can be uploaded once to S3/MinIO/GCS/Azure and any number of edge readers poll them, eliminating the need for a permanent gRPC connection to every replica.
• Multi‑model API: key‑value, wide‑column and large‑object (LOB) access patterns are all supported through a single HTTP/JSON interface.
• Zero‑mq notifications: side‑car processes push change events with sub‑millisecond latency for reactive applications.

Why it matters for AI / Edge Computing

• AI inference pipelines at the edge often need state (model versions, feature caches, sensor readings) that must be both queryable and instantly broadcast to other devices.
• Traditional stacks combine a database + a message broker (Kafka, Pub/Sub, CDC) which adds operational complexity and latency. UnisonDB collapses those two layers into one engine.
• The replication model scales to 10 000+ nodes in a few seconds, making it suitable for fleets of IoT devices, autonomous robots, or distributed inference services.

Key features (as listed in the repo)

Feature	What it provides
High‑availability writes	Raft quorum on primary nodes, ISR‑style replicas
Streaming replication	WAL over gRPC or object‑store‑backed fan‑out
Blob fan‑out	Publish immutable WAL segments to S3/MinIO/etc.; unlimited readers
Multi‑modal storage	KV, wide‑column, large objects
Real‑time notifications	ZeroMQ side‑car, sub‑ms latency
Durable B+Tree engine	ACID‑compliant storage via BoltDB or LMDB backends
Namespace isolation	Multi‑tenant support via logical namespaces

Performance highlights (from the README)

• Throughput: 60 k–80 k SET ops / sec (1 KB values) on an Apple M2 Pro while propagating to >10 000 nodes.
• Latency: sub‑millisecond change notifications; replication latency measured in the low‑hundreds of milliseconds across two‑hop topologies.
• Benchmarks: Redis‑compatible benchmark shows UnisonDB competitive with BadgerDB, BoltDB and LMDB for both GET and SET workloads.

Quick start

git clone https://github.com/ankur-anand/unisondb && cd unisondb
go build -o unisondb ./cmd/unisondb
./unisondb server --config config.toml   # start primary
curl -X PUT http://localhost:4000/api/v1/default/kv/mykey \
  -H "Content-Type: application/json" \
  -d '{"value":"bXl2YWx1ZQ=="}'

Documentation & ecosystem

• Getting‑started guide, configuration reference, architecture overview, HTTP API docs, backup/restore, deployment topologies – all hosted at unisondb.io.
• Pluggable storage backends: BoltDB (single‑file) or LMDB (memory‑mapped) for the B+Tree layer.
• Example replication via MinIO (cmd/examples/blobstore-minio).

Status – Marked Alpha; active CI (Go tests, coverage), open roadmap on the GitHub wiki.

Who might use it

• Teams deploying AI inference models on edge devices that need a shared, consistent state.
• Applications that require both durable storage and real‑time event streams without a separate message broker.
• Distributed sensor networks, robotics fleets, or any system where low‑latency fan‑out of state changes is critical.

---

All information above is taken directly from the repository’s README; no additional features have been inferred.