Give each user a stack of photos, each post a queue of comments, each job list a priority queue. You choose the data structure when you create the bucket, and hoardDB hands the data back in that order: newest photo first, oldest comment first, most urgent job first.
Claims ledger
Every sentence this site asserts, with its source. This is the same file the build's checker reads: a claim whose evidence stops resolving fails the build, and a claim with no evidence cannot be added at all.
How to read this
- Built — true of the code in the commit this site was built from.
- Planned — not built. These appear on the roadmap and nowhere else; the build fails if one reaches a page in the present tense.
- Off by default — the feature exists but ships disabled, and the claim may not be rendered without saying so.
- But: — the caveat. It is part of the claim rather than a footnote, and the two are one component.
Claims that are written but blocked — a measurement not yet taken, a feature not yet built — are in the manifest with their blocker and are deliberately absent from this page. They render nowhere until the blocker closes.
The five-minute capture
The home page's five-minute path is not written by hand. A script builds the server and the CLI from the commit below, runs every step against them, and records both the lines it typed and what the binaries printed; the page renders that record. The build refuses to publish a capture taken before the last change to the server, the CLI or their entry points.
Built
Run one node or several. Buckets are spread across the nodes by a consistent hash ring.
No node is promoted or removed automatically, so losing a node needs an operator.
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.
hoardDB-server starts with no arguments and no configuration file.
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.
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.
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).
Passwords are hashed with Argon2id.
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.
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)).
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.
Audit logging is in the server and free.
It is off by default — turn it on in the configuration.
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.
dump and restore write ordinary BSON that other tools can read.
Blob payloads and user accounts are not included in a dump.
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.
hoardDB is pre-1.0. Expect breaking changes.
The documentation on this site is the documentation in the repository. There is no second copy.
Free to self-host, including commercially and in production.
The one thing the licence does not grant is offering hoardDB itself as a database service to third parties. For that, talk to Boeger IT Sh.p.k, Tirana, Albania.
Client libraries live under clients/ and are Apache-2.0, so a driver you link into your own program carries no usage restriction.
This is a statement about the licence of a directory. clients/ holds a LICENSE and nothing else today; no client library has shipped.
The Business Source License is not an Open Source licence, and it says so itself. The Licensed Work converts to the Apache License 2.0 on the Change Date, or on the fourth anniversary of a version's first public distribution, whichever comes first.
Source-available is not the same as open source. Developers check this, so the site states it rather than leaving it to be discovered.
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.
The model is one bucket per user, per post, per job list: many small buckets rather than a few big ones.
How many buckets one node can hold has not been measured. No figure appears on this site until it has.
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.
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.
Building from source is the only install path today; there are no release binaries. The repository is not public yet, so there is nothing to clone.
Planned
Listed here with the same evidence discipline. Every one is in the future tense, on this page and on the roadmap only.
Encryption at rest is not built. It is planned in four stages, and none of them has landed.
Until it lands, treat the data directory as plaintext on disk. The users.json file is sealed separately and that is not encryption at rest for your data.
Client libraries are planned for after 1.0. None has shipped, and this site carries no code sample in any language other than HQL.
Server-side grouping and multi-document atomicity are not planned for 1.0.
A published benchmark is planned. There is no head-to-head measurement in the repository today, so this site publishes no performance number at all.
The source will be published when hoardDB reaches v1.0.
The repository is not public yet: the history is being prepared for publication first, so until it is there is nothing to clone.
Changing a bucket's engine after it is created is not built. It is planned for v1.1.
Until it lands, pick the engine you want when you create the bucket: changing it is not possible today, so a wrong choice means dropping and recreating the bucket.