DuckDB and ClickHouse
They are the execution and scan credibility bars. FFS needs to earn physical-plan seriousness while staying centered on graph/vector/write-back loops, not generic OLAP dominance.
database comparisons
FFS should not be read as a clone of DuckDB, ClickHouse, Postgres, Neo4j, or a vector database. It is an engine shape for graph, vector, typed-record, and durable write-back loops.
not clones; bars to clear
| Product | What people know it for | How FFS should be read against it | Status |
|---|---|---|---|
| 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 proof harness. |
| ClickHouse | Very fast columnar analytics at server scale. | FFS is not trying to be distributed OLAP first. It should earn 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. | FFS treats Postgres as the trust bar, not a clone target. The Postgres bridge is optional CDC/interoperability, not a runtime dependency. | pgvector HNSW query measured at 3.01x faster for FFS in the local run. |
| Kuzu / Neo4j | Graph storage, traversal, and Cypher-shaped querying. | FFS stores relationships as a native physical shape and keeps graph work near typed facts and vector indexes. | Kuzu/Neo4j numbers exist with caveats: FFS native CSR vs Cypher stack overhead. |
| LanceDB / Qdrant / pgvector | Embedding search and vector indexes. | FFS keeps HNSW beside the data, WAL, catalog, and transaction boundary instead of treating vectors as a sidecar lifecycle. | LanceDB and pgvector measured; Qdrant planned. |
| RocksDB / sled | Embedded key-value storage and page/tree internals. | FFS uses page and B+-tree machinery as part of a typed graph/vector engine, not as the whole product. | sled measured; RocksDB planned. |
| TigerBeetle | Correctness posture, deterministic testing, recovery discipline. | FFS borrows the idea that verification is a product feature: qlog posture, invariant checks, simulation, and crash/reopen tests matter. | Verification bar; not a direct workload comparator. |
honest comparisons
They are the execution and scan credibility bars. FFS needs to earn physical-plan seriousness while staying centered on graph/vector/write-back loops, not generic OLAP dominance.
Postgres is the trust and operations bar. FFS needs proofs around durability, reopenability, transactions, and compatibility pathways before it deserves broader production use.
The interesting comparison is not whether FFS has every mature feature. It is whether one engine can keep relationships, vectors, typed facts, provenance, and write-back under one transaction boundary.
claims need proof