this is not vibe coded project, this is developed by understanding sqlite code. Have you ever looked into examples ? Have you checked the code ?
Now my post got flagged. and If I use AI to understand code than what is wrong with that ? what is the use of AI ? to make person more productive, right ?
I've considered building this exact thing before (I think I've talked about it on HN even), but the reason I didn't build it was because I was sure (on an intuitive level) the actual overhead of the SQL layer was negligible for simple k/v queries.
Where does the +104% on random deletes (for example) actually come from?
Fair skepticism — I had the same intuition going in.
The SQL layer overhead alone is probably small, you're right. The bigger
gain comes from a cached read cursor. SQLite opens and closes a cursor on
every operation. SNKV keeps one persistent cursor per column family sitting
open on the B-tree. On random deletes that means seek + delete on an already
warm cursor vs. initialize cursor + seek + delete + close on every call.
For deletes there's also prepared statement overhead in SQLite — even with
prepare/bind/step/reset, that's extra work SNKV just doesn't do.
I'd genuinely like someone else to run the numbers. Benchmark source is in
the repo if you want to poke at it — tests/test_benchmark.c on the SNKV
side and https://github.com/hash-anu/sqllite-benchmark-kv for SQLite. If your
results differ I want to know.
Did you measure the performance impact of having multiple trees in a single file vs. having one tree per file? I'd assume one per file is faster, is that correct?
the benchmark probably controls for this implicitly but wondering if they used prepared statements in the sqlite baseline. the query planner overhead is negligible for a simple put/get after the first parse, but the vtable dispatch and statement compilation on every call can add up. if the baseline is using raw sqlite3_exec strings rather than prepared + bound params, that would explain a chunk of the gap.
I have used this https://github.com/hash-anu/sqllite-benchmark-kv/blob/main/t..., in which I called sqlite3_exec for only setting PRAGMA settings, for main operations I never used it. I have used prepared/bound/step/reset functions only. so the gap isn't
statement compilation overhead and the comparison is fair
this is not vibe coded project, this is developed by understanding sqlite code. Have you ever looked into examples ? Have you checked the code ? Now my post got flagged. and If I use AI to understand code than what is wrong with that ? what is the use of AI ? to make person more productive, right ?
If you can't tell then I'm not sure what more needs to be said. I took a look through the commit history and it was glaringly obvious to me.
To trust something like data-storage to vibe-coded nonsense is incredibly irresponsible. To promote it is even moreso. I'm just surprised you can't tell, too.
I don't know about trash, but this post, this repo and even their comments on this thread are blatantly written by an AI. If you still need to ask for evidence, consider that you might be AI-blind.
Edit: for me this post appears on the front page of HN. OP this is mission success - add this project to your résumé and stop spamming.
I've considered building this exact thing before (I think I've talked about it on HN even), but the reason I didn't build it was because I was sure (on an intuitive level) the actual overhead of the SQL layer was negligible for simple k/v queries.
Where does the +104% on random deletes (for example) actually come from?
The SQL layer overhead alone is probably small, you're right. The bigger gain comes from a cached read cursor. SQLite opens and closes a cursor on every operation. SNKV keeps one persistent cursor per column family sitting open on the B-tree. On random deletes that means seek + delete on an already warm cursor vs. initialize cursor + seek + delete + close on every call.
For deletes there's also prepared statement overhead in SQLite — even with prepare/bind/step/reset, that's extra work SNKV just doesn't do.
I'd genuinely like someone else to run the numbers. Benchmark source is in the repo if you want to poke at it — tests/test_benchmark.c on the SNKV side and https://github.com/hash-anu/sqllite-benchmark-kv for SQLite. If your results differ I want to know.
[1]: https://github.com/fastserial/lite3
All random accesses are slower.
that credulous hn readers will upvote this is alarming.
To trust something like data-storage to vibe-coded nonsense is incredibly irresponsible. To promote it is even moreso. I'm just surprised you can't tell, too.