nokv / docs
Documentation
To your tools and agents, NoKV looks like a filesystem: paths, folders, files — mountable, listable, readable. Underneath, file bodies live as immutable blocks in your S3-compatible object store, and NoKV's built-in metadata engine keeps the namespace — what exists, where, in which version — transactional, queryable, and snapshot-able. No separate database to run.
Status single-node today · no HA · POSIX surface incomplete · distributed metadata on the roadmap
Core
What NoKV is, how it is built, and the surface agents speak.
Architecture
How NoKV's pieces fit together: clients, the metadata service, the Holt engine, object storage, disaster recovery, and the planned distributed direction.
Product Design
What NoKV owns versus what it delegates: the product boundary, Holt's role, the target architecture, and the version plan.
Agent Interface
Reference for the seven-verb agent namespace surface: parameters, hard limits, request/response shapes, evidence URIs, and the canonical workflow.
Storage
How namespace records and file bodies are laid out and kept honest.
Metadata Schema
The inode/dentry record families that form canonical namespace truth, the MetadataCommand boundary, and the target schema families.
Object Layout
How file bodies become immutable object blocks: chunk layout, body descriptors, the staged publish rule, and snapshot-aware GC.
RustFS Backend
Running NoKV against a local RustFS deployment through the S3-compatible object backend, from server start to benchmark runs.
Operations
Publishing checkpoints atomically and measuring the system.
Atomic Publish & Checkpoints
The atomic publish primitive behind checkpoints, the semantics that ship today, and the explicit failure-handling contract.
Benchmarks
NoKV's benchmark surface: the nokv-bench workloads and profiles, the boundary-labeled L2 NoKV-vs-JuiceFS matrix, and how to read the results.