[392]

Sqlite can be run in process. Latency and bandwidth can be made 10x worst by process context switching alone. Plus being able to get away with n+1s could save a lot of dev time depending on the crew, before Claude (tho the dev still needs to learn that the speed problem is due to this and refactor the query, or write it fast the first time)

[crazygringo]

> Latency and bandwidth can be made 10x worst by process context switching alone.

No they can't. That doesn't even make sense as a claim regarding bandwidth since SQLite doesn't use any, but please re-read what I said about being a 1% or 5% difference in speed. Not 10x.

[bob1029]

Yes they absolutely can.

Same-core context switching costs a few microseconds.

Going across core complexes can cost tens to hundreds of microseconds.

These figures are several orders of magnitude (5-6) slower than L1 access on the same thread.

[crazygringo]

Hundreds of microseconds? L1 access? I don't have the faintest idea of what you're talking about.

Communication between processes is negligible compared to all of the sequential disk/SSD accesses and processing required for executing queries.

The database isn't stored in L1 and communication isn't taking hundreds of microseconds. I don't know where you're getting your information.

The fact that SQLite is in-process is primarily about simplicity and convenience, not performance. Performance can even be worse, e.g. due to the lack of a query cache.