How it got
faster

A hill climb is a loop: measure, change one thing, measure again, and keep the change only when the numbers say it helped. The work in September followed that loop, and from 3 October we ran six formal hill climbs, each with a fixed eval, against SQLite on one Windows machine. Every speed figure on this page is a ratio of SQLite’s time to Inillucent’s in the same round, so 2.00x is 100% faster and 0.50x is 100% slower.

Each round changes one thing and is judged by a rule written down before the first measurement. The rule, the workloads and the split into training and held out workloads do not change once the climb starts.

• A workload is held out when the FNV-1a hash of its name is 0 mod 3. Held out workloads are never used to design a change, only to accept one.
• Every change is a general mechanism, such as a set lookup, a cached setup or a lock that is not needed. None is keyed on a workload’s SQL text or its data.
• Builds are run in turn, pass by pass, in one quiet window, so a change in the machine’s speed moves both builds.
• A change is kept when the workloads it targets are faster with their whole 95% interval above 1.00, the training and held out means do not fall by more than 2.5%, processor time and memory do not rise by more than 10% and 3%, the tests pass, and every answer still agrees with SQLite.

Every benchmark runs both engines in the same rounds. A workload’s score in one round is SQLite’s time over Inillucent’s in that round, so a machine that slows down slows both. A workload’s result is the median of its rounds, and a set’s result is the geometric mean of its workloads, so one very fast workload cannot carry it. The engine headline weights ten families, with the weights fixed in a file before any measurement was taken.

A speed number is only useful when a reader can believe it. Each of these rules came from a number that looked like an answer and was not.

• A time counts only after the answer is checked. Every answer is hashed and compared with SQLite’s on every round. The first climb found two wrong answers this way: a reverse ordered LIMIT 20 after 20,000 inserts returned rows from the middle, and a prepared OFFSET returned the first page every time.
• Both engines run on the same cores. The machine has 8 fast performance cores and 16 slow efficiency cores. The same build read 4.40x unpinned and 4.97x pinned, and nothing in the output said so.
• The machine must be quiet. A busy machine slows SQLite about twice as much as Inillucent, so it makes Inillucent look faster. The gate times SQLite against its own idle speed and grades a run only when SQLite is within 3%.
• Measure the noise first. In the climb of 7 October, two rounds that changed no code the gate runs read 1.003 and 0.999.
• Use medians. One SQLite round sometimes took 20 to 35 times its usual time when its own checkpoint landed in it.
• Design from the training set and accept on the held out set. A change that helps only the workload it was written for shows up as a held out set that did not move.

The engine headline calls the engine directly. The path every driver uses was much slower: SELECT 1 once cost 132,884 ns outside a transaction against 1,126 ns inside one, because every statement took and released the file lock. From 3 October the climbs measured through Connection::prepare and Statement::step, on 48 workloads that applications meet.

Processor time for one round of the 48 workloads went from 3,906 ms against SQLite’s 1,820 ms on release 2.1.1, 115% more than SQLite, to 641 ms against 1,945 ms on release 2.4.2, 67% less. Peak memory went from 100.96 MiB to 59.78 MiB.

On 5 October we asked whether the engine’s speed reached a person using it. It did not. Release 2.1.5 was 216% slower than SQLite over 25 workloads, and the npm package was 29,270% slower, because every call started a new process. Two climbs fixed it in two days.

The command line stays close to SQLite because starting a program costs both engines the same and is most of a short command. From a terminal an empty program starts in 5.7 ms, and a one row query takes 7.55 ms in Inillucent and 7.95 ms in SQLite.

Release 2.1.5 on 5 October against release 2.4.2 on 8 October, each against the same use of SQLite. Every one of the 25 workloads is now faster than SQLite, and 7 of them are three times as fast or more.

The goal was 50% faster than release 2.3.4 on common operations: select, join, group by, insert and search. The eval was 82 workloads through the Connection API plus 6 search cases, 56 training and 32 held out. A case’s score is its speedup against 2.3.4. The goal was met at round 10.

Round 6 was the largest single step. Half of an autocommit point read was one system call, asking the open log segment its length to learn whether another process had committed. On Windows the process now holds an opportunistic lock on the segment. While it holds the lock no other handle to the file exists on the machine, so the length is known from this process’s own writes. Another process’s open breaks the lock and waits until this process has stopped trusting its count. An autocommit point read went from 1.74 to 1.91 us to 0.46 to 0.55 us.

Each bar is one change, measured as the time before over the time after on the workload it was written for. Each of the largest removed work the engine did not need to do: a full scan where two index lookups would do, a list searched from the start for every row, an array of 3.2 MB grown and freed on every execution, a new process for every call.

Fable is an AI model that is slower and more expensive to run than the one that did the building. We asked it for design advice where measurement could not answer the question, such as whether a change to the log is safe beside an older release. Every answer was a written document. Fable measured nothing and changed no code. The builders measured each claim and kept what held.

Every climb ends with a table of changes that were measured and reverted, so the next climb does not try them again. A few of them:

Release 2.4.2 on the engine plan, the median of three runs of 30 rounds. These runs were not graded: SQLite ran 4.0% to 4.4% slower than its idle reference, which makes the figures read somewhat high. The pale bars are the last graded run, release 1.0.32 on 26 September.

Processor time is 73% less than SQLite’s and peak memory 14% more. Memory is the one measure where SQLite is better, and most of the difference is what a Rust process holds before the engine starts. One workload of the engine plan is slower than SQLite: compiling SELECT 1 on every call, 75% slower. Through the Connection API, which keeps the compiled plan, it is 76% faster.

One regression is open. A DELETE of 40,000 rows by a range of rowids was 4% faster than SQLite after the third climb and is 233% slower in 2.4.2. It slowed down in a release between 2.1.5 and 2.3.4, and the climb of 7 October, which measured against 2.3.4, could not see it. It is filed as a known bug.

An eighth climb set a harder goal than a weighted mean: every one of the 116 workloads the benchmark times, in all three measurements, at least as fast as SQLite. It started from 74 of 116, because release 2.5.2 had added three questions to the file system per statement that cost about 20 us each on Windows. Release 2.5.4 ended it at 110 of 116, and 499% faster on the engine plan in a graded run of 11 October 2026, with SQLite within 2% of its idle reference.

The changes: the file system questions are skipped while the log’s oplock shows no other process has opened it; a range delete unlinks the leaves it empties; a join with a large outer side walks the inner index once; an update keeps one copy of each leaf as its undo record; an INSERT ... SELECT into an empty table collects its rows in a few large buffers; and a WHERE of integer comparisons is tested a batch of rows at a time. One change was to the benchmark: its Connection arm compiled a statement inside the clock where SQLite’s arm compiles before it, and now compiles first.

Six workloads are not faster. A range DELETE pays for folding the log into the database file, which lands on it in the benchmark’s fixed order; on its own it is level with SQLite. SELECT 1 compiled from text on every call through the engine’s own API costs more than SQLite’s compile; through the Connection API it is 66% faster. A join over an index range and an autocommit update are within 6% of SQLite, where the same index probes and one disk sync per commit decide the time.

• Fix the eval before the first measurement. A weighting or a threshold chosen after the results are in chooses the answer.
• Check the answer before trusting the time.
• Measure the noise before judging a change, and use medians when one sample can be 20 times the others.
• Run both engines on the same cores on a quiet machine, and say in the output when it was not quiet.
• When a timing will not hold still, count something that does: compactions, log writes, page fetches, compiles.
• Profile before changing, and profile each statement on its own.
• Measure the way people use the product as well as the engine. The engine was 419% faster while a person calling it from Node waited 29,270% longer than with SQLite.
• Report a floor no program can go under as a floor. Starting an empty program takes longer than three times SQLite’s speed would allow on 14 command line workloads.
• Ask a stronger model for design advice, and measure what it says. Its estimates were wrong twice, and its designs held every time they were built.
• Write down every rejected change with its numbers, so nobody tries it again.

• Every figure is from one Windows 11 machine with an Intel Core Ultra 9 285. A Linux run on 23 September measured 53% faster where Windows measured 279% on the same build, and has not been repeated since.
• The newest engine runs were not graded, because the machine was not quiet enough.
• The 5 September figure is computed from that day’s ten family ratios and weights. No run printed it.
• The hill climb workloads were written by the people improving the engine. The held out set guards against tuning to them, and the engine plan’s weights were fixed before any measurement.