[ledgerdev]

Here's sqlite doing 100 million inserts in 33 seconds which should fit into nearly every workload, though it is batched. https://avi.im/blag/2021/fast-sqlite-inserts/

So write contention from multiple connections is what you're talking about, versus a single process using sqlite?

[lvass]

Keyword here is transactions, not processes. You can model any workload to be transaction-efficient, but it might not be easy.

[endisneigh]

No durability guarantee is a showstopper for any serious use case

[axelthegerman]

Not sure what you mean by durability. Sqlite has WAL that can be replicated (see litestream)

[endisneigh]

https://en.m.wikipedia.org/wiki/Durability_(database_systems...

[dinosaurdynasty]

https://www.sqlite.org/atomiccommit.html

sqlite is as good at durability as any non-replicated database, though you can configure it to be non-durable (most other databases too tbf).

https://www.sqlite.org/pragma.html#pragma_synchronous

By default WAL mode can rollback committed transactions in cases of power failure, but you can do `PRAGMA synchronous = FULL` to trade speed for durability.

[endisneigh]

I’m talking about the post I originally commented on. Things were disabled so durability is not guaranteed.

[dinosaurdynasty]

Yeah that's not great

[ledgerdev]

If it's good enough for avionics and nuclear subs, it's probably good enough for most web apps.

[endisneigh]

Web apps do more concurrent writes than subs, plus you can configure SQLite for more durability

[sph]

I don't have the data for subs, but there's web app and web app. No one is talking about using SQLite for 5k queries/s.

It might work, but I reckon 90% of web applications live beneath this relatively small threshold and 80% probably don't even reach 50 q/s.

[samatman]

That's correct, I meant the many cores to allude to many processes.