One bar from each system.
FFS borrows one bar from each of these systems instead of competing with any of them head-on. The tables say which bar each one sets and what has actually been measured against it so far.
At a glance
| Need | Usual answer | FFS answer |
|---|---|---|
| Data moving between systems | ETL and orchestration | high-throughput work inside one engine |
| Continuous derive-and-write loops | application choreography | read, derive, index, write in one transaction |
| Analytical scans | separate column store | dense typed columns in the storage engine |
| Embedding search | similarity sidecar | native HNSW beside the data it indexes |
| Hot reads | server round-trips, parser overhead | native engine calls or thin ffsd protocol |
| Heavy writes | duplicate index maintenance | one WAL and one storage pipeline |
| Graph traversal | Neo4j / Kùzu | typed graph storage + Cypher subset |
| Typed facts | Postgres | schema enforced at the storage boundary |
| Mixed graph + vector + facts | distributed glue | one transaction |
| Deployment | services to operate | embedded library or ffsd, same file format |
The comparators
| Product | What people know it for | How to read FFS against it | Measured so far |
|---|---|---|---|
| SQLite | Open a file, get a database. | FFS wants that simplicity, but for heavier graph, vector, typed-record, and write-back loops. | Design bar; comparator planned. |
| DuckDB | Embedded analytical scans and vectorized execution. | FFS learns from the physical-execution discipline, but the target hot path also includes graph edges, HNSW vectors, and durable derived writes. | Planned in the proof harness. |
| ClickHouse | Very fast columnar analytics at server scale. | FFS is not chasing distributed OLAP. It needs column-scan credibility inside a single-node engine that can also traverse, search, and write back. | Planned after scan benchmarks mature. |
| Postgres | Trust, SQL tooling, durability, operational maturity. | Postgres sets the durability and operations bar FFS has to clear before production trust. The Postgres bridge exists for CDC and interoperability; FFS runs without it. | pgvector HNSW query 3.01x faster, same algorithm and parameters. |
| Kùzu / Neo4j | Graph storage, traversal, Cypher. | FFS stores relationships as a native physical shape and keeps graph work beside typed facts and vector indexes. | Measured with caveats: native CSR vs Cypher stack, see the evals. |
| LanceDB / Qdrant / pgvector | Embedding search and vector indexes. | FFS keeps HNSW beside the data, WAL, catalog, and transaction boundary instead of running vectors on a separate lifecycle. | LanceDB and pgvector measured; Qdrant planned. |
| RocksDB / sled | Embedded key-value storage and page/tree internals. | FFS uses the same kind of page and B+-tree machinery, but as one layer inside a typed graph/vector engine rather than as the whole product. | sled measured on all three ops; RocksDB planned. |
| TigerBeetle | Correctness posture, deterministic testing, recovery discipline. | FFS borrows its verification posture: qlog integrity checks, invariant scans, deterministic simulation, and crash/reopen tests ship with the engine. | Verification bar only; the workloads barely overlap. |
How to read this
DuckDB / ClickHouse. They set the bar for physical execution and scan discipline. FFS is not chasing general OLAP; it needs their level of plan seriousness on the scans that feed graph, vector, and write-back loops.
Postgres. The trust and operations bar. FFS needs proofs around durability, reopenability, transactions, and compatibility pathways before it deserves broader production use.
Graph and vector DBs. FFS will lag Neo4j and Qdrant on feature count for years. The question this project actually answers: can one engine keep relationships, vectors, typed facts, and provenance consistent under a single transaction boundary, which none of them attempt.
The measured numbers behind this table →