Hacker News Reader

Comment by adenta | Hacker News Reader

Do you really need concurrency? My understanding is read are like… picoseconds, because everything happens in memory. You don’t have a separate server to call.

This guy is great: https://fractaledmind.github.io/2024/04/15/sqlite-on-rails-t...

View on HN

https://fractaledmind.github.io/images/railsworld-2024/111.p...

https://fractaledmind.github.io/2024/10/16/sqlite-supercharg...

You're off by two orders of magnitude.

More like six?

It would be more constructive if you guys posted the correct numbers and a source.

A quick search suggests SSD reads are in the milliseconds. I’ve found that, or microseconds to be roughly accurate. SQLite queries, however, can take seconds (or more in pathological cases) depending on how optimized the indices are to the query being run, load, etc. This is one of the reasons I don’t love using SQLite in Bun servers. It makes me nervous that a bad query will bring down the single thread of the app.

it is easy to assume most programmers today know roughly how long things take since this has existed in various forms since Jeff/Peter first published it:

https://colin-scott.github.io/personal_website/research/inte...

(This version is more useful since it shows change over time)

That’ll teach me to post first thing in the morning.

Something something, Cunningham's Law.

It would be mice for it to work in concurrent contexts as even using mutexes adds responsibility (for not messing up).

Reply on news.ycombinator.com