The storage engine under every app on an Apple device is reached through one C interface, and that interface is the cleanest place in consumer computing to swap in a better store. 8DB is binary-compatible with it. Underneath, instead of rows in pages, it keeps typed atoms with provenance, a confidence vector, governance state and cross-modal indexes, so the same write that lands a row also makes it searchable by text, traversable as a graph, matchable as an embedding and answerable with a policy check, without a background daemon re-indexing it later. Since April 2026 we have been measuring what that costs and what it buys on an M1 laptop. This is the ledger.
The drop-in path is faster than SQLite
On 20 May 2026, in one Criterion run on an M1 MacBook Pro with SQLite measured in the same process on the same host, the SQLite-compatible shim in deferred-write mode inserted a row in 522 ns against SQLite's own insert, about 2.9 times faster, and 435 ns per row when batched by a thousand, about twice as fast. A read issued after a burst of writes sees them, and the test suite checks that. The native ring path, for applications that call the engine directly, inserted in 99 ns, about fifteen times faster than SQLite. The third path, which computes confidence, provenance, governance, a perceptual hash and cross-modal indexes synchronously on every write, costs 35.7 µs per row batched, and delivers on one call what would otherwise be a pipeline of separate passes. The companion article in this series takes the three paths apart.
One substrate, many query shapes
The point of a single store is that every shape of question runs against the same atoms. Measured on the M1, release build with link-time optimisation, external-evaluation feature set.
| Query shape | Measured | Date |
|---|---|---|
| Ranked text search, 100 documents | 69.1 µs, 95% interval [67.8, 71.7] | 19 May 2026 |
| Ranked text search, 1,000 and 10,000 documents | 726 µs and 8.03 ms, linear then slightly super-linear | 19 May 2026 |
| One-hop graph neighbour lookup, 1,000 to 100,000 nodes | 165 to 197 ns | 7 April 2026 |
| Three-hop traversal, one million entities | 50 µs | 7 April 2026 |
| Face embedding match, 1,000 and 10,000 entries | 102 µs and 1.06 ms | 7 April 2026 |
| Perceptual hash and near-duplicate check | 39.5 ns and 313 ps | 7 April 2026 |
| Three-dimensional geohash encode | 27.5 ns, [26.4, 29.0] | 19 May 2026 |
| Confidence decay evaluation | 4.23 ns, [4.10, 4.46] | 19 May 2026 |
| Eight concurrent readers | 61.6 ns per read | 19 May 2026 |
| Point read through the shim, against SQLite in the same run | 413 ns against 286 ns | 19 May 2026 |
The last row is a place SQLite wins today, by a factor of about 1.44 on that run, and it is in the table because a comparison that only shows the wins is not a comparison. The April rows are scheduled for a rerun on the current build.
The same speed on two very different chips
The three-hop traversal measured 50 µs on the M1 and 53 µs on an AMD desktop processor with six times the last-level cache. A seven-modality composite query measured 623 µs on the M1 and 633 µs on the AMD host. Two results within two percent across architectures that differ that much in cache mean the traversal cost is a property of the layout, not a cache artefact, which is what you want from a store that has to run on a watch, a phone, a laptop and a server.
What it does to the battery
In April 2026, on an M1 MacBook Air with a 49.9 watt-hour battery, using the system management controller's power sensors, a photo-ingest workload through 8DB consumed about 34 joules per gigabyte written against about 130 through SQLite, a factor of 3.8. The mechanisms are structural: fewer bytes written through a write-optimised tree, no background re-indexing because the indexes are built at write time, and relevance-gated sync that moves only what another device needs. The daily figures that follow from that, on the order of three percent of an iPhone's battery and six percent of an Apple Watch's, are estimates built on published radio and processor energy constants and a stated usage model, and the battery article in this series gives the assumption set and the range for each.
How to read the numbers
Every figure in this series is one of three kinds, and the kind is always stated. A measurement carries its host, toolchain, build flags, date and, where the harness produces one, a confidence interval. An estimate carries the assumption set it rests on and a range. An architectural property is implemented and tested code that no packaged demonstration yet exercises at scale, such as governed traversal with a clearance check per hop or the privacy registry that decides at write time what may sync. Where we describe what the governed write path replaces in an application stack, the cost on the other side is anchored to public framework documentation and community measurements rather than measured, so we publish the anchors for an engineer to contest and we do not publish a ratio.
What to bring us
- An app with a real database file. The shim is binary-compatible with the SQLite C interface. Give us the schema and the hot queries and we will run the three paths against your workload and return the intervals.
- A device you can instrument. The battery estimates become measurements with device-level power telemetry. If you have it, the workload is ready.
- A query that spans modalities. The photo that matches a face, near a place, shared with a person, last spring. That is the shape the single substrate is for, and we would like to run yours.
Write to hello@8braid.com with the subject "8DB on Apple Silicon: run our workload". You will hear back from an engineer.
Sources and further reading
- SQLite C interface specification
- Criterion.rs statistics-driven benchmarking
- Apple Foundation Models framework
- 8DB: Faster Than SQLite on Two Write Paths, and More Than SQLite on the Third
- 8DB: A Quarter of the Energy per Gigabyte: What a Storage Engine Can Give Back to a Phone
- 8DB: AI Is Outgrowing the Way We Store Information
All measurements were taken by 8Braid on its own hardware (M1 MacBook Pro, macOS 26.2, Rust 1.94.1, Criterion, on the dates given, several under recorded system load; the energy figure on an M1 MacBook Air in April 2026) and describe 8DB and SQLite as run by us; none is a measurement of Apple's production software. Daily battery figures are estimates. Apple, Apple Silicon, M1, iPhone, iPad, Mac, MacBook, Apple Watch and macOS 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. or the SQLite developers.
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