I run this library in a bunch of different applications, and as I decide how urgent (or even necessary) it is to upgrade it when a new version comes out, I try to look at the [CHANGELOG](https://gitlab.com/cznic/sqlite/-/blob/master/CHANGELOG.md). However, in the last 6-ish months, it's become really, really hard to understand what's new. The (AI generated?) changelog is now a wall of text full of implementation details, which are hard to parse as an end user. Past example: > 2026-04-03 v1.48.1: > > * Fix memory leaks and double-free vulnerabilities in the multi-statement query execution path. > * Ensure bind-parameter allocations are reliably freed via strict ownership transfer if an error occurs mid-loop or if multiple statements bind parameters. > * Fix a resource leak where a subsequent statement's error could orphan a previously generated `rows` object without closing it, leaking the prepared statement handle. > * See [GitLab merge request #96](https://gitlab.com/cznic/sqlite/-/merge_requests/96), thanks Josh Bleecher Snyder! Short and to the point. > - 2026-09-15 v1.59.0: > - Bump the pinned `modernc.org/libc` to [v1.75.7](https://gitlab.com/cznic/libc/-/tags/v1.75.7) and re-vendor `lib/` and `vec/` from `modernc.org/libsqlite3` v1.14.5 and `modernc.org/libsqlite_vec` v0.5.0, which were transpiled against it. As always, downstream `go.mod` files must pin the same `modernc.org/libc` version as this repository's `go.mod`; see the package documentation and [GitLab issue #177](https://gitlab.com/cznic/sqlite/-/issues/177). The transpiled SQLite is unchanged: still 3.53.4, byte-identical to v1.58.0 on all 20 targets. The change is beneath it. On the Linux targets libc v1.75.7 replaces the transpiled musl `memcpy`, `memmove`, `memset`, `memcmp`, `strcspn` and `fabs`, loops moving at most four bytes per step, with native Go routines backed by the runtime's vectorized `memmove` and `memclr` and by the `bytes` package; on every target `strlen` is now a word-at-a-time scan, or `bytes.IndexByte` on the 64-bit architectures. On the three CPU-bound workloads in the new Performance section of the package documentation, measured on linux/amd64 against the same SQLite 3.53.4 compiled from C with the same options, this driver went from 3.0x, 2.2x and 1.6x the CPU time of the C build to 2.0x, 1.9x and 1.3x. The other operating systems already used a native Go `memcpy` and `memmove` and see no such change. `vec/` stays at sqlite-vec v0.1.9; its re-vendor, from a transpile made with newer modernc.org/cc and modernc.org/ccgo, differs only in unreferenced macro constants and in one bounds check spelled with `INT8_MAX` instead of its value, so nothing changes in behavior there either. > - Hand user-defined function and aggregate callbacks a pooled `*FunctionContext` instead of allocating a fresh one per call. After the `[]driver.Value` pooling of #226 this was the last driver-side heap allocation per invocation: one 16-byte object for every `Scalar`, `Step`, `WindowInverse`, `WindowValue` and `Final` call. The context now also carries the invocation's `sqlite3_context`, so accessor methods can be added to it later without touching the trampolines. Like the argument slice, it is valid only for the duration of the callback and must not be retained past its return; the documentation on `FunctionContext` and on the callbacks now says so. On the 1000-row, 3-argument noop scalar UDF benchmark this removes a further 1000 allocs/op (5756 to 4756, and 3756 to 2756 with `VolatileArgs`) and 16 KB/op; on the reporter's reproducer from #226 it removes about 12% of the remaining allocations (25.3M to 22.4M allocs/op, 553 MB to 505 MB per iteration). > - Updates [GitLab issue #226](https://gitlab.com/cznic/sqlite/-/issues/226). See [GitLab merge request #137](https://gitlab.com/cznic/sqlite/-/merge_requests/137). > - Add regression tests for the pooled context: two functions evaluated in one statement must receive two different `sqlite3_context` values and every callback's context must belong to the invoking connection, checked on two connections held at once and without dereferencing the context, so that a stale one is reported rather than faulted on; eight connections held at once calling a function from their own goroutines, and a function that runs a statement invoking another function, both meant for the race detector. See [GitLab merge request #138](https://gitlab.com/cznic/sqlite/-/merge_requests/138), thanks Ian Chechin! > - Add a Performance section to the package documentation. It records the measured CPU-time ratios of this driver against the same SQLite compiled from C, that they hold under concurrency, where the gap comes from, and the two consequences for applications: index the columns that `ORDER BY`, `GROUP BY` and `WHERE` use, because a query that is merely sluggish in C can cross a deadline here, and bound the `database/sql` pool with `SetMaxOpenConns`, because a periodic query that outlasts its period piles up connections without bound. Prompted by [a report](https://github.com/coderage-labs/spillway/issues/162) that attributed a 103 s query to the driver spilling a temporary b-tree in Go; the workload showed no spill and about 2x the CPU cost of C, the wall time being unbounded overlap of periodic polls. There's only 5 bullet points but you'd be forgiven if you missed that in this wall of text. Some of the above are unnecessarily verbose. For example, the first one could just have been `Bump the pinned `modernc.org/libc` to [v1.75.7](https://gitlab.com/cznic/libc/-/tags/v1.75.7)` Others just are completely lacking any context, such as `Updates [GitLab issue #226](https://gitlab.com/cznic/sqlite/-/issues/226). See [GitLab merge request #137](https://gitlab.com/cznic/sqlite/-/merge_requests/137).` **Ask:** Please consider simplifying the changelog so it goes back to what it used to be, more digestible for human readers. The ask is **not** to stop using AI to generate the changelog, but rather just to tune the prompt so release notes are short bullet points that end users can read and understand.