Features

There are six engines: hash, b-tree, FIFO, LIFO, heap and blob. You pick one when you create a bucket.

You cannot change a bucket's engine in v1.0. It is planned for v1.1, and indexes remain declared when you create a bucket.

Evidence: cli/store_types.go:storeTypes· cli/unsupported_features.go:errAlterBucket

Each engine reads back in its own order: a hash by key, a b-tree in key order, a FIFO queue oldest first, a LIFO stack newest first, a heap by priority, a blob as raw bytes.

Evidence: cli/store_types.go:storeTypes· store/heap.go:PopItem

Placement is a consistent hash ring keyed by xxHash64. A bucket is placed by its database and its name together, so app/users and analytics/users are placed independently, like any two buckets. Membership is declarative — there are no elections and no arbiters.

No elections is the same fact as no automatic promotion: losing a node needs an operator. Placing by database and name together means a cluster that already holds data moves most buckets once, on upgrade ([replication.md](replication.md)).

Evidence: ring/ring.go:Owner· ring/ring.go:AddNode· ring/hasher.go:Sum64· server/placement.go:placementOf· TestPlacementKeyIsTheFrozenEncoding· docs/user/replication.md

The database is a single binary, with no sidecar and no separate indexer to run.

The CLI is a second binary, and it is a client rather than a component of the database.

Evidence: Makefile:build-server· cmd/server/main.go:main

hoardDB-server starts with no arguments and no configuration file.

Evidence: config/config.go:DefaultConfig· TestNoArgumentStartPathInTempDir

On first start it generates a self-signed TLS keypair and serves over TLS.

The certificate is self-signed: a first client connection trusts it on first use and records its fingerprint. It is not a CA-issued certificate.

Evidence: transport/transport.go:LoadOrCreateKeys· transport/transport.go:GenerateEd25519Keys

Authentication is always required. There is no flag that turns it off.

The CLI's -insecure flag is a client-side TLS verification bypass. It is not a server authentication switch, and there is no server-side equivalent.

Evidence: server/auth.go:NewCredential· server/authz.go:authorize

The first start also creates a root password and saves it to ./data/root.password, readable only by the user who started the server (mode 0600).

Evidence: server/authkey.go:LoadOrCreateRootPassword· proof/five-minute-path.out

Passwords are hashed with Argon2id.

Evidence: server/auth.go:NewCredential

Replication is in the binary and free: replication factor, write-ahead log, and a write concern of one, majority or all.

hoardDB never promotes or removes a node automatically. Losing a node needs an operator. Replication is off until a replication factor above one is configured.

Off by default Evidence: config/config.go:ReplicationFactor· storage/wal.go:WAL· server/write_concern.go:WriteConcernLevel· docs/user/limitations.md#cluster

Audit logging is in the server and free.

It is off by default — turn it on in the configuration.

Off by default Evidence: server/audit.go:AuditLogger· config/config.go:AuditConfig

Users, roles and per-database grants are persisted and enforced.

A role change applies at the next authentication, not to a connection that is already open.

Evidence: server/authz.go:roleSatisfies· server/users.go:LoadUsersConfig

dump and restore write ordinary BSON that other tools can read.

Blob payloads and user accounts are not included in a dump.

Evidence: cli/dump.go:RunDumpCommand· cli/dump.go:RunRestoreCommand

hoardDB is not wire-compatible with any other database and does not aim to be. HQL is inspired by JSON syntax; it is a different language from every other query language.

Evidence: cli/parser.go:ParseCommand

hoardDB is pre-1.0. Expect breaking changes.

Evidence: docs/user/limitations.md

HQL's literals and command forms are JSON.

The wire format is BSON, not JSON: this claim is about what you write, not what travels.

Evidence: cli/documents.go:parseDocument

A node can join or leave a running cluster, and the buckets it served move to the nodes that now own them.

The move is automatic once a change is committed — but the change itself is operator-initiated: no node promotes or removes another by itself.

Evidence: server/cluster_join.go:handleClusterAdd· server/migrate.go:sweep