AI 智能体 KISS Sorcar 在不到 8 小时、API 成本低于 $150 的情况下，将 SQLite 优化提速 59%（几何平均 1.59x），且全部 1,032,940 项测试通过。
Making SQLite 5% faster would already be powerful.
Here, an AI agent, KISS Sorcar, got 59% improvement in under 8 hours, for less than $150.
GitHub repo below:
SQLite is one of the most battle-tested codebases on earth. Its team has spent nearly 20 years shaving off tiny performance gains.
And it wasn't optimizing some toy benchmark. The gains showed up across transaction-heavy workloads, analytical queries, and blob I/O.
The agent found several places where the default setup was paying unnecessary costs, especially around how transactions hit disk, then changed the code and configuration, benchmarked everything, and attacked its own changes for bugs.
Over 1 million SQLite tests still pass.
This may be one of the more useful demonstrations of where coding agents are heading.
- 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)
I optimized SQLite 3. 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 standard Linux provided by GCP. An agent called KISS Sorcar did it in under 8 hours for under $150 in API cost. I wrote no code: 1 main short prompt 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. 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. 3. Security hardening and independent review. Two hardening rounds with kimi-k3 as the model: 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. 1.59x is what an agent can honestly find in one of the most heavily optimized codebases in the world overnight. Optimized SQLite Repository: https://github.com/ksenxx/sqlite-optimized/ Blog: https://kisssorcar.github.io/blog/sqlite-optimization-blog.html在 X 查看被引用的帖子
来源：Rohan Paul · x.com