A week of speedups we didn’t write
Last week the database got materially faster. One common operation went from about 4.4 seconds to about 10 milliseconds. Another went from about seven hours to about fifteen minutes. No human wrote those changes. Our autonomous build loop did — it found the slow paths, wrote the fixes, wrote the benchmarks that prove they worked, and merged its own pull requests. Here’s what landed, and how the loop knew it helped.
We’ve written before about how LastDB is built: humans set destinations, a loop of scheduled agents drives everything to merged on the development track, and only a handful of genuinely human decisions come back to us. Performance is one of those destinations. This is a week of it, in detail.
Two wins you’d notice
Asking the database for every record of one kind — every card, every note — used to mean walking the entire store, decoding each record, and keeping the ones that matched. The cost grew with how much data you held, not with how big the answer was: a few milliseconds at ten thousand records, ten times that at a hundred thousand, headed for over a second as a store approached a million. The loop added a secondary index so the same question reads only the records that match. The answer is now a roughly fixed cost — about ten milliseconds — whether the store holds ten thousand records or a million.
The second win is setting up a new device. Restoring from the cloud replays an encrypted change log, and it used to do that strictly one entry at a time: download, decrypt, apply, repeat. At roughly a tenth of a second per entry, a sizeable log — a couple hundred thousand entries — took about seven hours. The apply step genuinely has to run in order, so the loop left that alone. But the download-and-decrypt does not: it now runs thirty-two at a time, feeding an in-order apply. The restore is bound by your bandwidth instead of by round-trip latency. The same log now restores in about fifteen minutes.
Three smaller cuts landed alongside them: a redundant full copy of every record on the write path, removed; usage telemetry moved off the request’s hot path so it runs beside the real work instead of in front of it; and sandboxed transforms moved off the thread that serves requests, so a slow one can’t stall everything else. None is dramatic on its own. Together they trim the steady-state latency of ordinary work.
How the loop knew it helped
The fixes aren’t the interesting part. The interesting part is that the loop does not trust “looks faster.” Every one of these changes shipped with a benchmark — five new ones last week — that measures the path and then guards it: if a later change pushes it past a set threshold, the build fails.
A speedup that isn’t measured is a hope, not a result. So the order is always the same: write the measurement, write the fix, then leave behind a fence that keeps the win from quietly eroding six months from now. The numbers in this post aren’t our impressions. They’re what those benchmarks reported.
The win it didn’t take
One of those new benchmarks found a path running about fifteen times slower than it could: a bulk scan over an area that’s encrypted at rest pays a per-record decryption cost that adds up. The loop measured it, wrote it down — and deliberately left it alone.
Nothing in production reads that path yet. Optimizing it now would be solving a problem no one has, and trading simple code for speed that no user would feel. So the loop filed the finding, set a guard so the cost can’t silently get worse, and moved on. Knowing what not to fix is the same discipline as knowing what to.
What the humans did
We set the direction — the database should be fast, and stay fast — and answered nothing else. The loop found the slow paths, wrote the fixes and the benchmarks, opened the pull requests, and drove them to merged without anyone in the chair. The one thing that came back to a human was publishing this post about it. The same local-first principle behind LastDB is the principle behind how we build it: the work runs on its own, in the open, without waiting on permission it doesn’t need.
More on the loop itself: Building LastDB with an autonomous agent loop.