I’ve been building UnisonDB for the past several months—a database inspired by DynamoDB’s architecture, but designed specifically for edge computing scenarios where you need 100+ replicas running at different locations.

GitHub: https://github.com/ankur-anand/unisondb

UnisonDB treats the Write-Ahead Log as the source of truth (not just a recovery mechanism). This unifies storage and streaming in one system.

Every write is:

Durable and ordered (WAL-first architecture) 1.

Streamable via gRPC to replicas in real time 1.

Queryable through B+Trees for predictable reads

This removes the need for external CDC or brokers — replication and propagation are built into the core engine.

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 1.

Peer-to-Peer – for regional datacenters that replicate changes between each other 1.

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.

Upcoming Roadmap:

Namespace-Segmented HA System — independent high-availability clusters per namespace 1.

Backup and Recovery — WAL + B+Tree snapshots for fast recovery and replica bootstrap (no full resync needed)

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.