| 5 Dec 2025 |
 just1602 | But did some of the fork of sqlite like libsql or turso could fix the issue we face with sqlite? | 16:40:42 |
|  adam changed their profile picture. | 16:43:41 |
|  👉@crystallinefire:chat.solarpunk.moe changed their display name from EVA-01 to 👉@crystallinefire:chat.solarpunk.moe. | 17:17:17 |
 aloisw | I would rather trust SQLite than a VC-backed fork plastering "AI" over their website to stay around. | 17:52:46 |
| aloisw | And I think it's helpful to figure out what our actual issues with SQLite are. "The WAL grows too large" is a <10 line fix, but of course I don't know yet if this is the only problem. | 17:54:24 |
| aloisw | Update: RESTART checkpoints with 40000 pages tank the speed even more, since checkpoints happen very often due to nix-eval-jobs growing the WAL so fast. | 18:36:17 |
 raitobezarius | hah | 18:47:21 |
| aloisw | Yeah the WAL just grows so much faster than the database, even with large WAL sizes checkpointing takes quite long. | 19:01:35 |
| aloisw | Page size of 512, WAL size of 1 GiB (lower should also work, only increasing the fsync cost) and RESTART checkpointing looks quite nice with the synthetic test case. There are still stalls, but they are like 7 seconds after 2 minutes. | 19:30:36 |
| 6 Dec 2025 |
 Jassuko | Hmmm. The database itself should not be very big, right? What is the consistency requirement for it? I.e. do we really need to care if the system crashes mid-build somewhere as long as the final state or such gets committed properly? | 10:50:42 |
