Apr 21, 2026 · Rejected (no bump needed — already on newest stable sqlite3mc)

Experiment 090: sqlite3mc bump audit — already current

Date: 2026-04-21

Status: Rejected (no bump needed — already on newest stable sqlite3mc)

Problem

SQLite 3.51.0 (2025-11-04) advertised "use fewer CPU cycles to commit a

read transaction." The daily-research note flagged a bump as a

candidate: if our vendored sqlite3mc is behind, we get across-the-board

read-path wins for free.

Hypothesis

Vendored copy lags upstream ⇒ a dependency bump pays for itself.

Investigation

Current vs. target

Our vendored copy is 37 days old. The premise of the task brief — "If our vendored copy is older, bumping should produce free, across-the-board read-path wins" — does not hold. We already pulled the "fewer CPU cycles to commit a read transaction" work. That change shipped in 3.51.0 and we are on 3.51.3.

What SQLite 3.53.0 would buy us

Based on the official 3.53.0 release log:

Net verdict: no meaningful read-path or write-path perf win we can reliably bank. The FP default change is a minor correctness hazard (snapshot diffs) and adds risk we'd normally want a point release to shake out.

Compile-flag drift audit

Diffed our hook/build.dart:84-137 defines against SQLite 3.53.0's documented compile options. No drift:

No removed or renamed flags affect us. No new required flags for 3.53.0. One new optional flag worth noting for a future bump: SQLITE_DBCONFIG_FP_DIGITS runtime option if we ever want to keep 3.52 / pre-3.53 FP rounding on a 3.53 binary.

Risk table

Benchmarks

Not run. The investigation stopped at target-version feasibility

because 3.53.0 fails our pre-existing .0-release policy. Running a

bench wouldn't change the recommendation: even if 3.53.0 won by 5% on

some workload, we wouldn't land it at .0. The cautionary exp-088

guidance about "don't hand-wave single runs" applies equally to "don't

hand-wave a bake-time policy."

Decision

Rejected — hold at sqlite3mc 2.3.2 / SQLite 3.51.3. Reasons:

1. We are already on the newest stable sqlite3mc tracking a stable SQLite release. The bump thesis ("our vendored copy is old") is false — it is 37 days old.
2. The only newer target (3.53.0) is a .0 release 12 days old, explicitly excluded by the policy in the task brief.
3. No compile-flag drift; no signal of a significant perf win specific to our hot paths in the 3.53.0 changelog.
4. 3.53.0 ships a default FP rounding behavior change that is a small but real snapshot / test hazard.

Revisit trigger

Re-run this investigation when any of these is true:

• SQLite 3.53.2 (or later .2+) ships upstream, and sqlite3mc cuts a release tracking it.
• A specific workload regression surfaces that has a known fix in >3.51.3.
• We decide to adopt a 3.53.0 API (none planned — sqlite3_carray_bind_v2 is the only mildly interesting one and we have no current consumer).

If a future bump is approved

Step-by-step plan (for the record, not for this PR):

1. Download sqlite3mc-<version>-amalgamation.zip from the GitHub release.
2. Overwrite third_party/sqlite3mc/{sqlite3.h,sqlite3ext.h,sqlite3mc_amalgamation.c,sqlite3mc_amalgamation.h}.
3. Update third_party/sqlite3mc/VENDORING.md with new version + SHA-256s + source id.
4. If bumping into 3.53.x: add sqlite3_db_config(db, SQLITE_DBCONFIG_FP_DIGITS, 15) in native/resqlite.c::resqlite_open to pin pre-3.53 FP rounding, or explicitly decide to accept the new default and update any test snapshots.
5. dart pub get && dart test — zero expected failures.
6. dart run benchmark/run_profile.dart on baseline branch and bump branch with --repeat=5, then benchmark/profile/diff.dart. Commit only <label>-aggregate.md per feedback_profile_json_aggregate_only.md.
7. Commit order: (a) vendored sources + VENDORING.md, (b) any FP-digits shim in resqlite.c, (c) benchmark aggregate, (d) CHANGELOG entry noting SQLite version.

Appendix: sqlite3mc release map