[samatman]

Postgres obviously.

Sorry, just thought I'd buck the trend and assume a very write-heavy workload with like 64 cores.

If you don't have significant write contention, SQLite every time.

[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.

[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.

[dinosaurdynasty]

If you can have one "database" thread and 63 "worker" threads, send messages back and forth, and don't hold open transactions, this would probably work with sqlite. Aka treat sqlite like redis.

[skyde]

so in your example the database thread is the Redis thread and the worker thread are your http server thread I assume.

This is a good analogy, but there are still lot of wire heavy scenario a real database like postgresql or mysql will have better throughput than redis.

[innocenat]

Where is write contention coming from if it's operated locally?

[Thaxll]

SQLite is "single" threaded for writes.

[d3nj4l]

... you can get tons of requests on a server?

[dinosaurdynasty]

Redis has the same limitation (only one transaction at a time) and is used a lot for webapps. It solves this by requiring full transactions up front. The ideal case for sqlite for performance is to have only a single process/thread directly interacting with the database and having other process/threads send messages to and from the database process.

[innocenat]

But that isn't "locally"?