The project converts the SQLite C code and has been kept very up to date, so it is far more than a one-off port. The reason is to avoid dealing with CGO in your project, which is necessary with other drivers such as mattn/go-sqlite3.

Implementation decisions of Go have various advantages in terms of control and memory use but they make linking to binary artefacts problematic. Not complicated, but it impacts the toll chain’s flexibility drastically. The FFI is also extremely slow.

That is why the go ecosystem tends to reimplement everything in go.

C has no telemetry

Each call out to a C library from Go locks an OS thread rather than participating in the go routine scheduling. If stuff happens that makes those threads slow or have some issue, they just sit here. I had a server with C Kafka libraries and each time the network glitched the CPU would spike up wards and not decline. With pure go the scheduler is able to just swap out and ignore code that is stuck some where (unless it were in a busy loop).

With this SQLite implementation I can stick it in my server (as a background, near real time mirror of memory state to disk) without worrying that the main loop will get clogged or my real time path will be hurt.

I use glabarez’ wrapper which makes it have an API like other Go databases: https://github.com/glebarez/sqlite/ and hey have been very responsive to issues I raised.

I have been running load tests against it for a few weeks, and it is quite solid.

Worth noting that busy loops are handled as well since 1.18.

Doesn't Go runtime offer anything like spawn_blocking in Rust async runtimes? Spawn_blocking allows to run any blocking operation without blocking the main executor threads, by spawning blocking operation into a separate thread-pool. This way there is no reason to worry "that the main loop will get clogged or my real time path will be hurt."