I optimized SQLite 3. More precisely: an AI agent did, and I can back up every number.

The optimized build achieves a verified geometric-mean speedup of 1.59x over the pristine latest trunk across four benchmarks:

- 2.06x on the official speedtest1 (~30k statements)
- 1.90x on TATP (OLTP mix: 400k transactions, 100k subscribers)
- 1.30x on the Star Schema Benchmark (13 queries x 2, 1.5M-row lineorder)
- 1.25x on kvtest (blob I/O: 40k x 10 KB, seq + random + update)

All 1,032,940 cases in the full SQLite test suite pass, and every benchmark run produces checksum-verified identical results. For context: the SQLite team has spent nearly 20 years tuning this code; their own measurements show ~3.5x total CPU improvement since 2008, earned a few percent at a time. Tested so far on macOS and Linux (GCP).

An agent called KISS Sorcar did it in under 8 hours for under $400 in API cost. I wrote no code: 3 short prompts plus a couple of steering prompts.

Why I trust the results:

1. No cheating in the speedup. The biggest win is defaulting to WAL journaling, the configuration SQLite's own docs recommend. Re-measured durability-neutral (synchronous=FULL: committed transactions survive power loss exactly as strongly as the baseline), it is still 1.54x faster. Every run is gated: speedtest1 --verify, kvtest integrity checks, and hard-coded expected counts and result checksums that abort the benchmark on any mismatch. PGO was trained on different workload sizes and seeds than the measured runs, no timing code was left in the final diff, and every change is an opt-in compile option. I asked for 5x; the agent refused, showed the remaining time is fsync-bound durability, and documented what a dishonest 5x would look like (sync off, benchmark-keyed caches, skipped work) - all rejected.

2. Adversarial testing. A separate attacking agent tried to break the changes: a 37-script differential SQL corpus (recursive CTEs, window functions, triggers, UPSERT, JSON, FTS5, rtree, corrupt inputs) compared byte-for-byte against a pristine build under ASan/UBSan, plus WAL-file corruption, multi-process mptest, fd-exhaustion, symlink, and read-only-media attacks. It found two real bugs in early versions - both fixed and re-verified.

3. Security hardening and independent review. Two hardening rounds with kimi-k3 as reviewer: in-tree fuzzers (fuzzcheck over all 8 corpora, sessionfuzz) came back clean; 14 hostile-WAL corruption scenarios - no crashes; OOM injection and page-size sweeps; one real bug found and fixed. Then a read-only review by gpt-5.6-sol-high, instructed not to invent problems: it confirmed the engine changes clean and instead caught flaws in my benchmark harness - silent pipeline failures, unenforced checksums, a nondeterministic fixture. All were fixed, negative-tested with a deliberately broken binary, and every number re-measured.

1.59x is what an agent can honestly find in one of the most heavily optimized codebases in the world - in an afternoon.
