🌋🤨

First of all, thank you very much for publishing this repo and the accompanying article, it has been incredibly insightful to me. One qualm I wanted to raise was noticing that minisqlite behaves mostly like a sqlite database, but by design it is quite different. I'll let Fable detail the specifics:

Where it diverges: Volcano-style pull execution instead of a bytecode VM, skipped the VFS trait and sans-IO design entirely (plain std I/O, no simulator harness), and ships no C API, no CLI, and no prepared statements — the whole public API is Connection::{open, open_in_memory, execute, query}. It also has no cost-based planning — ANALYZE writes real sqlite_stat1 rows, but the planner doesn't read them yet. So: a real format-3 implementation with disciplined architecture, positioned as an embedded library for one process at a time, not a full sqlite3 replacement.

Although I don't think this diminishes the published work, I am curious how the swarm came to the volcano design decision when much of the above is well documented in the pages of SQLite docs (e.g. https://sqlite.org/arch.html). It seems to me this was less of a "building SQLite from scratch, in Rust, from nothing but its documentation" and more of a "build a database that behaves like SQLite but is designed to benefit from swarm decomposition" or as Fable put it "Conway's law, agent edition".

Just thought I would raise this in case the authors wanted to share any further details not covered by the article.

No file, test, or entry point is named, and the issue asks for architectural context rather than a specific change. Start by reading the accompanying article, the repository documentation, and SQLite's architecture documentation; done would require a decided explanation of the Volcano design and its relationship to swarm decomposition.