Skip to content

Database

A hub keeps a little metadata separate from your files: accounts, projects, orgs, invites, shares, devices, read buckets, and apps with their keys.

File content and the sync journals always live in the object store. The database never holds them as the truth. The one derived copy it holds is the data index, for projects that turn Data on. The index stores their JSON documents and Markdown frontmatter in the tables data_items and data_projects. With the file driver it uses its own SQLite file instead, data-index.db, which sits next to projects.json. Losing the index costs a rebuild, never data.

"database": { "driver": "file" } // default — JSON under BDRIVE_HOME
"database": { "driver": "sqlite", "dsn": "/var/lib/bdrive/hub.db" }
"database": { "driver": "postgres", "dsn": "postgres://…@…pooler.supabase.com:6543/postgres" }
  • file (default) — zero dependencies, human-readable JSON. Right for a laptop or a small self-hosted hub.
  • sqlite — one embedded database file. A real database locally, with no server to run. The hub runs it in WAL mode, so hub.db-wal and hub.db-shm sit beside it while the hub is up: back up all three with the hub stopped, or run sqlite3 hub.db ".backup /path/to/copy.db" while it runs.
  • postgres — a managed Postgres such as Supabase for production. Point dsn at its connection string; use the transaction pooler when you expect many connections. Since Supabase is Postgres, this stays fully open source with no managed-only lock-in.

file and sqlite are single-writer — run one hub instance. Postgres is transactional and can back more than one.

Both SQL drivers are pure Go, so the binary stays a CGO-free static build.