quiverdb-server 0.28.0

The Quiver daemon: gRPC + REST with auth, RBAC, audit, and metrics.
Documentation

The Quiver daemon: gRPC and REST over the embeddable [Database], with API-key auth and secure-by-default configuration.

Both transports are thin shells over the same shared engine operations; the engine is synchronous and CPU/fsync-bound, so every call is offloaded with spawn_blocking. Access is guarded by a reader–writer lock (ADR-0057): reads take the shared lock and run concurrently, writes take the exclusive lock, and the single-writer model is unchanged (ADR-0002/0006). A read that finds a collection's index stale (a prior write deferred its rebuild) serves the prior snapshot and schedules an off-lock rebuild (ADR-0062): the index is rebuilt under the shared lock and swapped in under a brief write lock, so a rebuild never stalls concurrent readers.

Auth is by scoped API key (Bearer / gRPC authorization metadata) with default-deny RBAC: each key carries a role (read ⊆ write ⊆ admin) and a collection scope, enforced on every operation at the shared op layer (ADR-0011/0013, the auth module). Encryption-at-rest is on by default (ADR-0010): unless insecure is set, an encryption_key is required and the engine is opened through quiver-crypto's AEAD codec; payloads may also be client-side-encrypted (ADR-0012). TLS-in-transit uses rustls over the audited ring provider — REST via axum-server, gRPC via tonic's tls-ring — and a non-loopback bind requires it; setting a client CA additionally requires mutual TLS. Mutating and administrative operations, and every access-control denial, are recorded to an append-only audit log (ADR-0011, the audit module) when audit_log is set. Per-request cost limits bound the work any single authenticated request can demand (ADR-0040, the [Limits] type), and an opt-in per-key token-bucket rate limiter bounds the request rate (ADR-0049, the [RateLimiter] type); per-tenant engine partitioning is a later phase. Design: docs/api/rest-grpc.md.