ffsdb
workspace package 0.5.0 / v1 in progress
Built for software that scans typed records, traverses graph relationships, searches vectors, derives facts, and writes results back under load without splitting the hot path across separate stores.
Current posture: private preview, 920 verified tests, reproducible comparator evals, and the v1 storage convergence under way — the whole read surface can now serve from the on-disk engine at ~3x of in-memory speed, behind default-off flags.
ffsdfocused pages, not anchors
the stack tax is real
Modern workloads scan dense columns, walk relationships, compare embeddings, derive facts, update indexes, and write state back. The usual answer is a relational database, graph database, vector database, queue/log, and application glue.
FFS puts typed records, relationship tables, embedding indexes, provenance, MVCC, WAL, and recovery on one storage substrate instead of separate services with duplicated caches.
Graph updates, vector updates, typed facts, derived state, and provenance links should commit or fail together. That is why the project keeps one WAL and one transaction boundary.
The repo keeps an eval harness for both faster and slower paths. The point is not one heroic number; it is a repeatable map of where the engine shape removes stack overhead.
apps and agents first
Run the shared data path for thousands of apps and hundreds of thousands of agents: app state, agent memory, tenant context, graph relationships, vector retrieval, provenance, query history, and durable write-back in one engine.
Serve runtime reads for large agent fleets asking what an app knows, which entities are connected, what changed, which source produced it, and what should be retrieved next.
Power ERP.ai-style workflows where approvals, disputes, procurement, finance, customer records, tool calls, and model outputs continuously read, derive, index, and write back state.
measured, with caveats
| Signal | Current fact | Where to read more |
|---|---|---|
| Tests | 920 passing across storage, schema, indexes, execution, planner, Cypher, WAL, transactions, vector, GNN/provenance, ffsd, Python, bridge, bench, and simulation crates. | Engine page |
| Vector evals | Local README run shows FFS HNSW faster than pgvector and LanceDB on the measured paths. | Evals page |
| Disk read path | The full read surface serves from the on-disk engine at ~3x of in-memory — point reads ~1.6M ops/sec on the 20k-node overlay-read bench, up from ~448 before the page cache and direct seek. | Engine page |
| Comparable products | DuckDB, ClickHouse, Postgres, Kuzu, Neo4j, LanceDB, Qdrant, pgvector, RocksDB, sled, and TigerBeetle are treated as bars to clear, not clone targets. | Comparisons page |
| Release map | v0.6 hardens trust and indexes; v0.7 targets execution speed; v0.8 moves planning; v0.9 centers write-back; v0.10 raises the public proof ladder. | Roadmap page |
Storage integrity, ffsd ownership, Studio/daemon query contracts, qlog posture, snapshots, export/import, verified tests — and the v1 read flip: every read served from the on-disk engine, equal to in-memory across the full Cypher surface and a reopen.
The v1 write path: writes still maintain the in-memory store and dual-write the disk shadows; restructuring them to flow through the disk engine alone is what remains before the in-memory store can be retired. Alongside it, richer secondary-index plans and broader planner completion.
The cut to disk-served by default; 100GB, 10TB, and 100TB evals; backups and branch/restore surfaces; flow, feature, and agent workloads.