The most valuable thing a storage engine can give a phone is hours. A phone spends a surprising share of its energy on data plumbing that the user never sees: writing more bytes than the data needs, re-reading everything it just wrote so that a search index can catch up, and pushing every change to every other device whether or not anyone there will ever ask for it. 8DB removes each of those by construction rather than by tuning, and on the one workload we have instrumented so far the difference is a factor of about four.
The measurement
In April 2026, on an M1 MacBook Air with a 49.9 watt-hour battery, we ran the same photo-ingest workload through 8DB and through SQLite and read energy from the system management controller's power sensors. 8DB consumed about 34 joules per gigabyte written. SQLite consumed about 130. On that workload the same charge ingests about 3.8 times as many photos. The figure is dated and a rerun on the current build is scheduled, because the engine has changed since April.
Why it is structural
Fewer bytes reach the flash. 8DB's tree is write-optimised: updates are buffered and flushed in large sorted runs, so the bytes actually written approach the bytes of data rather than a multiple of them. Flash writes are among the most expensive operations a phone performs per byte, and write amplification is paid in energy and in the lifetime of the flash itself.
Indexes are built at write time. In a conventional stack the row lands first and a background daemon later re-reads it to extract metadata, compute embeddings, cluster faces and update a search index. That is the same data read again, sometimes several times, at an energy cost that appears on nobody's benchmark because it happens when the phone is idle and plugged in. In 8DB the text index, the perceptual hash, the embedding match and the governance state are produced by the write itself, at a measured 35.7 µs per row batched on the M1, and there is nothing left for a daemon to do.
Sync moves only what matters. Every atom carries a confidence vector and a relevance signal, so device-to-device sync can send the small fraction of changes another device will actually query rather than replicating everything. Radio time is the other large energy line on a phone, and the fraction sent is the lever.
What that projects to
The daily figures below are estimates, and each rests on three inputs: published radio and processor energy constants from the engineering literature, a stated usage model, and a community-sourced figure for what a background indexing daemon draws. We publish conservative, central and aggressive values, and the central ones are these.
| Device | Estimated daily saving | Share of battery | Largest contributor |
|---|---|---|---|
| Current-generation large iPhone | About 131 mAh | About 2.8 percent, roughly 18 minutes of screen time | Elimination of background search indexing, about 35 mAh |
| Apple Watch Series 10 | About 21 mAh | About 6.5 percent, roughly 1.7 hours | Health time-series ingest and sync |
| AirPods Pro | Negligible | Under 0.1 mAh | Audio streaming dominates; storage is not the lever |
The Watch figure is the interesting one. A small battery makes the storage layer a much larger share of the day, and health data is a continuous time series, which is exactly the write pattern the tree is best at. The iPhone figure is dominated by one line, background indexing, and that line rests on a daemon power draw we did not measure ourselves; if the draw is lower than the community figure, the saving shrinks with it, and we say so in the assumption set.
The baseline in every percentage is Apple's published battery capacity or battery life. Reviewer-measured figures, which run longer, are cited for context and never used as a denominator.
The rule we hold energy claims to
Before an energy figure appears anywhere external it is either a measurement with a host, sensor, workload and date, or an estimate with its assumption set and a range. It is a per-day realistic-usage figure or it is labelled illustrative. And it has survived one adversarial read by someone who wants it to be wrong. That discipline is why this article has one measured number and a table of labelled estimates rather than a headline, and it is why the number will still be true when you check it.
What to bring us
- Device power telemetry. The estimates become measurements the day the workload runs on an instrumented iPhone or Watch. The workload and the assumption set are ready.
- Your write pattern. Continuous time series, bursty media, chatty sync. Tell us the shape and we will say which of the three mechanisms applies and by how much on the M1 harness.
- A measured daemon draw. If you have instrumented background indexing on a device, the largest line in the model is waiting for your number.
Write to hello@8braid.com with the subject "Storage energy: measure our workload". You will hear back from an engineer.
Evidence notes
The energy measurement is a single April 2026 run on one M1 MacBook Air using system sensors; a rerun on the current build is scheduled. Every daily figure above is an estimate, not a measurement, and its inputs are listed. Per-sync-cycle figures that appeared in an early internal report are illustrative only and are not used here. A separate thermal-performance property of the retrieval engine, in which accuracy on hard multi-anchor queries rises with an algorithmic bath temperature, was tested on the M1 in May 2026, initially reported as absent, and then confirmed in the calibrated range after the first benchmark was found to have run outside it; that parameter is algorithmic and is not the physical temperature of the processor.
Sources and further reading
- Apple: iPhone battery and performance and Apple Watch battery information
- 8DB: One Store Under Every App: 8DB on Apple Silicon, by the Numbers
- 8DB: Faster Than SQLite on Two Write Paths, and More Than SQLite on the Third
- 8DB: Every Number on This Site Has a Harness
The measured energy figure was taken by 8Braid on one M1 MacBook Air in April 2026 using system sensors and describes 8DB and SQLite as run by us; it is not a measurement of Apple's software. Daily milliamp-hour figures are estimates resting on published constants and a stated usage model. Battery capacities and battery-life baselines are Apple-published values. Apple, iPhone, Apple Watch, AirPods, M1, MacBook Air and Spotlight are trademarks of Apple Inc. SQLite is a trademark of Hipp, Wyrick and Company, Inc. 8Braid is not affiliated with or endorsed by Apple Inc.
Continue the technical conversation
Where could this help your work?
Bring a research question, a database workload or an application you want to build. Let’s connect the ideas in this article to an evaluation that matters to your team.
Discuss this work