Documentation

Hyphae is a single-node, offline-first data engine that runs as one Rust process owning one data directory. Inside that directory, a bounded relational core, a native keyspace engine, and an integrated lexical/vector search engine all execute over the same transaction log, the same multi-version concurrency control, and the same catalog. A committed cross-engine transaction becomes visible at exactly one commit sequence number in every engine, or in none of them. Every eligible read can carry a proof a third party verifies offline, without trusting the machine that produced it.

The mental model

Five facts explain nearly everything else in this documentation.

One process owns one directory

Opening live state takes an exclusive operating-system lock. A second process trying to open the same directory fails with data_directory_locked. To share one directory across several local processes, run the daemon and have the others connect as clients.

One commit, one CSN

SQL, structures, and search share one catalog, one write-ahead log, one MVCC commit sequence, and one commit scheduler. A transaction that mixes a SQL insert, a structure mutation, and a search document write publishes all of it under one commit sequence number (CSN) or none of it. Readers never combine roots from two different generations. Isolation is snapshot isolation with first-committer-wins over logical write identities — Hyphae does not implement serializable execution, and no document in this site claims it does.

Everything is bounded

Every public operation carries explicit count, byte, depth, work, and deadline limits. A request that would exceed a limit fails closed before it stages a partial mutation, rather than degrading silently or running unbounded. hyphae capabilities reports the effective limits of the running build. This is the same philosophy behind the bounded SQL grammar (SQL) and the fail-closed search filters (Search).

Three durability classes, never a universal latency promise

Every write chooses Strict (acknowledged after this transaction's own WAL fsync), Group (acknowledged after a shared cohort fsync), or Memory (acknowledged with no fsync at all — an acknowledged Memory commit can be lost on crash, but never torn). None of them come with a universal sub-millisecond promise; see Transactions and proofs for what each class actually guarantees.

Evidence is first-class

Every commit returns a receipt with a CSN, an LSN, a WAL block digest, and a transaction identity. Eligible reads — catalog lookups, SQL, and product reads — can additionally emit a canonical proof and witness that anyone verifies completely offline against an independently supplied anchor. Self-consistency is not trust: verification never opens your data directory or contacts your machine. Details in Transactions and proofs.

Map of this section

What Hyphae is not

This documentation is precise about boundaries because Hyphae's design is bounded on purpose. Hyphae is not:

• a universal SQL database — the relational core admits a closed, versioned set of grammar shapes, not arbitrary SQL;
• a Redis-compatible cache — the native structure engine shares Hyphae's own transactions and TTL semantics and speaks no RESP protocol;
• a full-text search platform with Lucene-class query surface — search is bounded lexical and vector retrieval with typed filters, not an open query language;
• distributed, replicated, or highly available — it is single-node and single-writer by design, with no clustering and no consensus;
• serializable — isolation is snapshot isolation with first-committer-wins, and write skew is admissible exactly as in any snapshot-isolation system;
• a hosted service, an embedding provider, or an LLM — Hyphae embeds none of these; your application supplies vectors and models.

Wording matters here. This site follows Hyphae's own canonical claims document — measured, bounded language over broad ones, and a receipt behind every number that has one.