SQLite (with WAL) doesn't do `fsync` on each commit under default settings

Re:SQLite (with WAL) doesn't do `fsync` on each commit under... by hoppp on Sunday August 24, 2025 @12:43PM (#45005664)

Calling fsync on each commit makes it slower, doesn't it?

Its an extra syscall. It depends on the use-case if its needed or not

[ Parent | on HN ]

Re:SQLite (with WAL) doesn't do `fsync` on each commit under... by senderista on Sunday August 24, 2025 @03:44PM (#45007098)

You can enqueue fsync as an op in io_uring, using link flag to sequence it after previous ops and drain flag to ensure no new ops are started until it completes.

[ Parent | on HN ]

Re:SQLite (with WAL) doesn't do `fsync` on each commit under... by dgshsg on Monday August 25, 2025 @03:35AM (#45011281)

You still need to wait for it to complete to report the commit success to the user, the cost of syscall itself is rather minor here.

[ Parent | on HN ]

Re:SQLite (with WAL) doesn't do `fsync` on each commit under... by senderista on Monday August 25, 2025 @02:47PM (#45017454)

Avoiding the syscall cost is about maximizing throughput, not minimizing latency. The media's time-to-durability is what it is.

[ Parent | on HN ]

Re:SQLite (with WAL) doesn't do `fsync` on each commit under... by praptak on Sunday August 24, 2025 @02:02PM (#45006294)

That's why big DBs do group commits, trading latency for throughput.

[ Parent | on HN ]

Re:SQLite (with WAL) doesn't do `fsync` on each commit under... by mxey on Monday August 25, 2025 @03:38AM (#45011301)

It’s slow because it forces a write to disk. I don’t think the syscall itself matters much.

[ Parent | on HN ]