Skip to content
8BraidCreators of
8DB

Idea · Multi-anchor retrieval measured on M1, May 2026 · Governed traversal integration-tested · Registry and workloads exercised on synthetic data

Private On-Device AI Needs a Store That Never Phones Home: Provenance on Every Fact, Clearance Enforced at Every Hop

The promise of intelligence that never leaves the phone is only as good as the data layer under it. A model retrieving from a store that cannot say where a fact came from, who may see it, or how sure to be will give private answers that cannot be trusted. 8DB is the retrieval layer built for that setting: multi-anchor search that returned 3.6 times the precision of full-text search on the questions people actually ask, traversal that enforces clearance on every hop, and a privacy registry that decides at write time what may ever leave the device.

Published
Reading time5 minutes
On-device AI retrievalApple Intelligence data layerPrivate on-device databaseMulti-anchor search vs FTS5Governed retrieval clearancePrivacy by design storageFoundation Models contextPost-quantum database

Apple has made the strongest public commitment in the industry to intelligence that runs on the device and, when it cannot, in a cloud that is verifiably unable to retain what it sees. That commitment moves the hard problem down a layer. A model that never leaves the phone still retrieves from something, and what it retrieves from decides whether the answer can be trusted: where each fact came from, whether this request may see it, and how much confidence to place in it. Today that something is a collection of per-app databases, a metadata index and a set of caches that do not share an identity for the same event. 8DB is a store built for the setting instead.

Answering the questions people actually ask

"The restaurant my wife mentioned last Tuesday." "The photo of my dog in Calgary." Those are multi-anchor queries: two or three weak constraints across modalities, none of which is a keyword the user typed into a document. Full-text search is built for the opposite case, one strong lexical anchor, and it degrades on these.

On an M1 MacBook Pro in May 2026, over thirty multi-anchor queries, two thermal phases and 22,573 iterations, 8DB's inverted-index entity lookup returned in 290 µs at the median against 606 µs for SQLite's full-text extension on the same corpus, about 2.1 times faster at the median and between 1.8 and 2.1 times across percentiles. More important than the latency: on the class of query where one anchor is a topic and the other a person hidden in metadata rather than text, the adaptive retrieval path returned about 3.6 times the precision of the full-text baseline. Latency parity with a mature full-text engine is table stakes. Answering the question is the product.

Clearance enforced on every hop

An on-device model reasoning across a user's graph must not traverse into data its current context is not cleared for, and that has to be a property of the traversal, not of the prompt. In 8DB every edge carries governance and every hop checks it. In the on-device cognitive integration test, a 200-hop governed traversal completed at about 23 ns per hop with zero clearance violations, six of six scenarios passing. The clearance check is cheaper than the hop.

Deciding at write time what may leave

A privacy registry in the engine carries, per data category, whether a write may land locally, sync to other devices, or be included in a backup. Biometric and credential categories default to local only; messaging, media and documents carry their own defaults; an application can tighten a rule and cannot silently loosen it. Because the check runs at write time, a category that must never leave the device cannot be exported later by a code path that forgot to ask. The registry is exercised by a workload of 10,000 policy checks across eight categories and three write targets.

Built for the shapes intelligence produces

The store is exercised against eight workloads modelled on what on-device intelligence actually generates: speaker embeddings with match and diarisation, biometric time series with segment recognition and a circadian fit, spatial anchors with radius and nearest-neighbour queries, activity embeddings with prediction and weekly summary, the privacy gate above, a notification graph with temporal windows and per-app profiles, cross-device activity handoff with chain tracing, and a model registry that selects the best model for a target accelerator. Each reports ingest rate, per-query latency and rows returned, and each runs against the same atoms as every other, because that is the point.

Why one store

Every app on the device today keeps its own database, contributes its own metadata to a shared index, and maintains embedding caches no other app can reuse. The same event, a photo, exists as a row, an index entry, a face embedding, a location and a sharing permission with no shared identity, and a model retrieving across them has to trust application code to reconnect them. In 8DB those are projections of one protected atom with one provenance chain, one confidence vector and one governance state. The retrieval precision and the per-hop clearance above are what that identity buys on the read side. The registry is what it buys on the write side.

What to bring us

  • Your hardest retrieval query. A real multi-anchor question your users ask and your search does not answer. We will run it against the corpus and return precision and latency.
  • A model that needs governed context. If you are building on an on-device foundation model and assembling context by hand, the traversal and the registry are the two pieces to test first.
  • A privacy rule you cannot enforce today. Tell us the category and the boundary. We will show whether the registry expresses it and what the write path does when it is violated.

Write to hello@8braid.com with the subject "On-device intelligence: governed retrieval test". You will hear back from an engineer.

Evidence notes

The retrieval measurements are Criterion and harness results from one M1 MacBook Pro in May 2026 against SQLite's FTS5 extension as run by us. The governed-traversal figures come from an integration test and a microbenchmark scheduled for a rerun on the current build. The privacy registry and the eight workloads run on generated data with default parameters, so their numbers are regression guards rather than product measurements and are not quoted here. No production application has yet shipped on the registry.

Sources and further reading

Measurements were taken by 8Braid on one M1 MacBook Pro in May 2026 and describe 8DB and SQLite's FTS5 extension as run by us; they are not measurements of Apple's software or of any Apple service, and nothing here describes an announced Apple product or Apple's internal implementation. Apple, Apple Intelligence, iPhone, Mac, M1, Siri and Private Cloud Compute 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

Continue reading

The next layer of the argument.

Engineering note

8DB on Apple Silicon

Cut Storage Energy to a Quarter of SQLite's per Gigabyte Written, and Give the Battery Back to Your Users

Measured on an M1 with the machine's own power sensors, a photo-ingest workload through 8DB used about 34 joules per gigabyte written against about 130 through SQLite. The reasons are structural, not tuning: a write-optimised tree writes fewer bytes, indexes built at write time remove the background re-indexing daemons, and relevance-gated sync moves only what another device needs. Here is the measurement, the mechanisms, and what they project to for an iPhone's and a Watch's day, with every assumption in the open.

6 min readEnergy per gigabyte measured, April 2026, rerun scheduled · Daily figures are estimates with published assumption setsRead article
Research

8DB on Apple Silicon

One Store Under Every App: 8DB on Apple Silicon, by the Numbers

Every app on an Apple device keeps its data in the same embedded engine, behind a C interface that has not changed in decades. Put 8DB underneath it and the device gets a store that is faster than SQLite on its drop-in write path, carries provenance, confidence and governance as storage columns, answers graph, search, spatial and face-match queries from one substrate, and runs at the same speed on an M1 as on a desktop chip with six times the cache. Here are the measurements, with the host and date on every one.

6 min readCriterion runs on one M1 host with 95% intervals · Estimates labelled with their assumption setsRead article
Benchmark

8DB on Apple Silicon

Faster Than SQLite on the Writes That Matter, With Provenance and Category 5 Sealing SQLite Cannot Give You

8DB gives an application three ways to write. The drop-in path speaks SQLite's C interface, preserves read-your-own-writes, and inserted about 2.9 times faster than SQLite on the same M1 in the same run. The native path inserted in 99 nanoseconds, about fifteen times faster. The third path costs more per call because it computes confidence, provenance, governance, a perceptual hash and cross-modal indexes on every write, replacing a pipeline of separate passes with one. Here is the benchmark and the trade each path makes.

5 min readsqlite_comparison_bench, Criterion, one M1 host, 20 May 2026 · 95% intervals · SQLite measured in the same runRead article