LiteDb.Distributed is production-candidate software for small local-first clusters, branch/edge systems, and durable replicated cache/document workloads.
- Replace default
Auth:RootApiKey. - Replace default
Node:ReplicationApiKey. - Use a stable unique
Node:NodeIdper node. - Ensure only one process owns each LiteDB database file.
- Configure durable storage for
Node:DataDirectory. - Run the samples against a realistic multi-node setup.
- Monitor
/api/replication/status. - Decide backup/restore procedure before enabling aggressive pruning.
The server does not block startup when development defaults are still configured. Treat default API keys as local-development conveniences only, and rotate them before exposing a node outside a trusted developer machine.
Each logical database is stored as a single LiteDB file per node. Do not point multiple running node processes at the same database file.
Operation-log pruning is enabled by default. It keeps recent operations and removes older payloads only after active peer checkpoints have moved past them. Compact receipts are retained longer for duplicate suppression.
If a node falls behind the retained log window, replication status reports:
TooOldNeedsSnapshot
That node needs a restore/clone workflow before it can safely catch up.
- write latency
- replication pending operations
- peer checkpoint progress
TooOldNeedsSnapshot- pruning results
- operation receipt growth
- LiteDB file lock/open errors
- cache replication visibility latency
Run a three-node cluster, then use:
dotnet run --project .\Samples\ClusterSoakTest\ClusterSoakTest.csprojFor cache replication visibility:
dotnet run --project .\Samples\DistributedCacheProbe\DistributedCacheProbe.csprojGood first target: sustained writes for 15-60 minutes with no replication timeouts and stable pending-operation counts.