SQLite: Past, Present, and Future

Re:SQLite: Past, Present, and Future by ledgerdev on Thursday September 01, 2022 @11:01AM (#32677283)

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?

[ Parent | on HN ]

Re:SQLite: Past, Present, and Future by lvass on Thursday September 01, 2022 @11:10AM (#32677483)

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

[ Parent | on HN ]

Re:SQLite: Past, Present, and Future by endisneigh on Thursday September 01, 2022 @11:23AM (#32677707)

No durability guarantee is a showstopper for any serious use case

[ Parent | on HN ]

Re:SQLite: Past, Present, and Future by axelthegerman on Thursday September 01, 2022 @01:39PM (#32680067)

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

[ Parent | on HN ]

Re:SQLite: Past, Present, and Future by endisneigh on Thursday September 01, 2022 @01:53PM (#32680314)

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

[ Parent | on HN ]

Re:SQLite: Past, Present, and Future by dinosaurdynasty on Thursday September 01, 2022 @04:29PM (#32682666)

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.

[ Parent | on HN ]

Re:SQLite: Past, Present, and Future by endisneigh on Thursday September 01, 2022 @04:54PM (#32683052)

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

[ Parent | on HN ]

Re:SQLite: Past, Present, and Future by dinosaurdynasty on Thursday September 01, 2022 @05:49PM (#32683757)

Yeah that's not great

[ Parent | on HN ]

Re:SQLite: Past, Present, and Future by ledgerdev on Thursday September 01, 2022 @03:03PM (#32681391)

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

[ Parent | on HN ]

Re:SQLite: Past, Present, and Future by endisneigh on Thursday September 01, 2022 @04:14PM (#32682442)

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

[ Parent | on HN ]

Re:SQLite: Past, Present, and Future by sph on Thursday September 01, 2022 @05:08PM (#32683217)

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.

[ Parent | on HN ]

Re:SQLite: Past, Present, and Future by samatman on Thursday September 01, 2022 @12:25PM (#32678775)

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

[ Parent | on HN ]