NamiDB’s design lives in 18 (and counting) Request-For-Comments
documents. Each captures the why of a major engine decision — the
context, the alternatives considered, and the rationale.
For a high-level orientation, start with
RFC-001 — Storage engine
and RFC-002 — SST format.
Storage engine
| RFC | Topic |
|---|
| 001 | Storage engine |
| 002 | SST format |
| 003 | Read-path ranged reads |
| 018 | CSR adjacency cache |
| 019 | NodeView cache |
| 020 | Edge SST caches |
Query language
| RFC | Topic |
|---|
| 004 | Cypher subset |
| 008 | Logical plan IR |
| 009 | Write clauses |
Optimizer
| RFC | Topic |
|---|
| 010 | Cost-based optimizer |
| 011 | Predicate pushdown |
| 012 | Hash join |
| 013 | Parquet predicate pushdown |
| 014 | Hash semi-join |
| 015 | Projection pushdown |
| 016 | Join reorder |
Executor
Read fan-out (in flight)
| RFC | Topic |
|---|
| 021 | Read-path mutex removal (in flight on main) |
How RFCs work
For any change bigger than a few-line refactor, the contributor writes
an RFC, opens a Draft PR with only the RFC, and gets feedback before
writing any code. See RFC process for the
full workflow.
The canonical source is
docs/rfc/ in
the engine repo. The pages in this section are mirrors with a
docs-friendly nav.
