hoardDB stores data the way your app reads it.
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.
You have been building stacks out of tables
A newest-first list of photos for each user usually means a table, a user
column and a timestamp column, an index over the two, and
ORDER BY … DESC LIMIT 20 on every read. A comment thread is
the same list the other way round. Each one is a data structure you
assembled out of rows and an index.
In hoardDB, the data structure is the thing you create.
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.
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.
From source to a working stack in five minutes
Build it, start it, give one user a stack of photos, and read it back.
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.
Build it and start it. No flags, no configuration file.
$ go build -o hoardDB-server ./cmd/server $ go build -o hoardDB-cli ./cmd/cli $ ./hoardDB-serverWhat the server prints on its first start
{"time":"2026-09-26T16:36:49.374117246Z","level":"INFO","msg":"hoardDB server starting","node_id":"<this machine>","listen":"0.0.0.0:4433","version":"version=devel commit= build_date="} {"time":"2026-09-26T16:36:49.374272998Z","level":"INFO","msg":"cluster token generated (first start)","token":"<cluster token — yours will differ>","saved_to":"data/cluster.token"} === CLUSTER TOKEN (save this!) === <cluster token — yours will differ> ================================ {"time":"2026-09-26T16:36:49.375387666Z","level":"INFO","msg":"auth signing key ready","kid":"f240a1a0","source":"loaded from data/auth.token.key"} badger 2026/09/26 16:36:49 INFO: All 0 tables opened in 0s badger 2026/09/26 16:36:49 INFO: Discard stats nextEmptySlot: 0 badger 2026/09/26 16:36:49 INFO: Set nextTxnTs to 0 {"time":"2026-09-26T16:36:49.377198747Z","level":"INFO","msg":"capacity gauges are not exported (HOARDB_METRICS_ENABLED is false); capacity warnings still go to this log and to hoardDB status"} {"time":"2026-09-26T16:36:49.377212083Z","level":"INFO","msg":"encryption at rest","mode":"off"} {"time":"2026-09-26T16:36:49.377223556Z","level":"INFO","msg":"catalog loaded","databases":0,"buckets":0} === ROOT CREDENTIALS (shown only on first start) === export HOARDB_ROOT_USER=admin export HOARDB_ROOT_PASSWORD='<root password — yours will differ>' Saved to data/root.password at 0600. Set HOARDB_ROOT_PASSWORD to choose your own at the next start, or rotate it with: hoardDB-server -reset-password admin which also removes this file once the new password is written. ===================================================== {"time":"2026-09-26T16:36:49.379524917Z","level":"INFO","msg":"memory limit is the host's MemTotal (28.7 GiB): no cgroup memory limit is set on this process's cgroup or any ancestor it can see","limit_bytes":30786129920} {"time":"2026-09-26T16:36:49.419376261Z","level":"INFO","msg":"root user seeded","username":"admin","roles":["root"]} {"time":"2026-09-26T16:36:49.419580475Z","level":"INFO","msg":"root user bootstrapped into users.json","username":"admin","path":"data/users.json"} {"time":"2026-09-26T16:36:49.419760755Z","level":"INFO","msg":"TCP driver listener listening","address":"[::]:7433","fingerprint":"SHA256:ef7d940ff308ccbe888c3dc91f59c83f91a64f4a86cf72de015407968cefe62b","node_id":"<this machine>","alpn":"hoarddb/1"} {"time":"2026-09-26T16:36:49.419782397Z","level":"INFO","msg":"internode TCP listener listening","address":"0.0.0.0:4434","alpn":"hoarddb/1"} {"time":"2026-09-26T16:36:49.419793478Z","level":"INFO","msg":"metrics server disabled"}$ stat -c '%a %n' data/root.password600 data/root.passwordConnect. The CLI reads the password the server just wrote.
$ ./hoardDB-cli -address 127.0.0.1:7433 -insecureGive one user a stack of photos, and one photo a queue of comments.
create database app use app create bucket photos_ada { type: lifo } db.photos_ada.push({file: "beach.jpg"}) db.photos_ada.push({file: "dinner.jpg"}) db.photos_ada.push({file: "sunset.jpg"}) create bucket comments_photo1 { type: fifo } db.comments_photo1.push({by: "lin", text: "Where was this?"}) db.comments_photo1.push({by: "ada", text: "Albania, last June."})WARNING: TLS certificate verification is disabled (--insecure); the connection to 127.0.0.1:7433 cannot be trusted and may be intercepted. Use this only against a local development server. 2026/09/26 16:36:49 WARN TLS certificate verification disabled by an explicit insecure trust policy host=127.0.0.1:7433 reason="--insecure flag" Authenticated as admin Connected to 127.0.0.1:7433 hoardDB CLI devel Type 'help' for help, 'exit' to quit. OK created database app Next: use app Then: create bucket <name> {type: hash | btree | fifo | lifo | heap | blob} (hash is the default) Switched to database 'app' OK created bucket app.photos_ada (type lifo) OK id=01a0de93-98c8-77a5-9578-92ec3278a2a5 OK id=01a0de93-98c8-7b11-9706-65fb300d14da OK id=01a0de93-98c8-7f09-8d99-baac5b947b7a OK created bucket app.comments_photo1 (type fifo) OK id=01a0de93-98c9-7321-8f06-291a7c08750c OK id=01a0de93-98c9-7430-b2b6-430c95097093 Goodbye.Read them back. The stack gives the newest photo; the queue gives the oldest comment.
use app db.photos_ada.peek() db.comments_photo1.peek() db.photos_ada.length()WARNING: TLS certificate verification is disabled (--insecure); the connection to 127.0.0.1:7433 cannot be trusted and may be intercepted. Use this only against a local development server. 2026/09/26 16:36:50 WARN TLS certificate verification disabled by an explicit insecure trust policy host=127.0.0.1:7433 reason="--insecure flag" Authenticated as admin Connected to 127.0.0.1:7433 hoardDB CLI devel Type 'help' for help, 'exit' to quit. Switched to database 'app' {"_id_": "01a0de93-98c8-7f09-8d99-baac5b947b7a", "file": "sunset.jpg"} {"_id_": "01a0de93-98c9-7321-8f06-291a7c08750c", "by": "lin", "text": "Where was this?"} 3 Goodbye.
Captured 2026-09-26T16:36:49Z from commit 195a7db684c4
on linux/amd64. Replaced before publishing: the root password, the cluster token and the machine name; nothing else is edited.
How this is captured →
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.
TLS and a password before you configure anything
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).
One binary. Yours to run.
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.
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.
Free to self-host, including commercially and in production.
Check it against the code
The documentation on this site is the documentation in the repository. There is no second copy.
Read the claims ledger What it does not do yet What is planned