“The restaurant my wife mentioned last Tuesday.” You remember who, when and why. Your assistant needs data that connects those clues.
A message says, “Let's try this place.” The restaurant name is inside a link. The sender identifies who recommended it. The date narrows the search. None of those clues, on its own, is the whole question.
For developers building personal AI, that is a valuable opportunity. Give the model a way to retrieve connected information, and it can work with the context people actually remember.
8DB is an omnimodal database designed to bring multiple representations, provenance, confidence and governance into the same data system. For on-device AI, our aim is a memory that can connect content to people and time, retain its source, and make an explicit access decision before a result reaches the model. The building blocks are concrete; the restaurant example illustrates the application we want to enable.
Turn remembered clues into a useful retrieval task
The first job is to make the relationships available. A message can be linked to its sender, timestamp and referenced place. A retrieval tool can then combine those clues instead of asking the language model to infer missing connections from isolated snippets.
The next job is to preserve what makes an answer checkable. Keep the source message with the result. Carry uncertainty where the connection is inferred. Apply the relevant permission to each candidate. The assistant should be able to point back to the information behind its answer.
This is where 8DB's architecture becomes interesting: search results have explicit places for provenance, confidence and evidence state, and the native search path includes candidate-level admission. These give application developers components for building that workflow within one connected data layer.
Illustrative application design
One question. Several connected clues.
“The restaurant my wife mentioned last Tuesday.”
The sender
The person linked to the message helps identify whose recommendation you mean.
The place
The message and its link identify the restaurant, even if its name was absent from your question.
The time
The message timestamp narrows the candidate set to the period you remember.
The relevant recommendation, with a source you can inspect. If no permitted evidence supports it, leave the question unresolved.
Keep the source and the permission with the result
Suppose the same search returns a public recommendation and a sealed personal note. Their relevance may be similar; their permission is different.
8DB's retained native-search regression fixture checks that a sealed candidate cannot borrow an open neighbor's read permission, even when both arrive in the same page. Separate persisted-snapshot fixtures check label and payload consistency. That is a useful boundary for local AI: select information for relevance, then admit it under the candidate's own policy.
An application still needs to bind the request to an authenticated identity, current policy and its cache behavior. The fixtures address specific boundaries, rather than certifying a complete deployed assistant. They give the integration a concrete starting point and clear acceptance checks.
The destination also matters. 8DB includes a category-and-target privacy gate for local writes, sync and backup. For example, its inspected default face-biometric category permits local use but is ineligible for sync and backup. Applications must configure their categories and route outbound operations through the enforcement path. This lets the deployment specify which information may travel, with an explicit check at the relevant boundary.
A fast lookup is a useful building block
Connected retrieval still benefits from efficient access to the underlying records. Our historical keyword experiment provides one encouraging, narrowly scoped result.
Keyword lookup: a May 19 report records 290 µs for 8DB and 606 µs for SQLite FTS5, approximately a 2.09× advantage for the tested 8DB route. The workload used 10,000 generated records and batches of 50 terms on an Apple M1. These are medians of batch-average per-query timings. 8DB used simulated storage; SQLite ran in memory. The machine also had concurrent build activity, so this is a historical stressed-host observation, not an isolated production benchmark or a claim about every full-text workload.
That comparison measures one retrieval operation. A useful assistant also needs to return the right information and enforce access on the complete question. The next application evaluation should measure those together, with the same corpus, metadata and answer requirements for each implementation.
That evaluation should also ask whether useful retrieval lets the complete assistant fit the device and budget you already have. Count context preparation, model execution, peak memory and energy alongside answer quality and access checks. A faster lookup is one contribution to that outcome.
Where 8DB fits among local data tools
Apple's Foundation Models tool-calling interface gives developers a place to connect a model to an application's database. Choosing the data layer determines how much context and control that tool can supply.
| Option | Documented capabilities relevant to local AI | What to examine for your application |
|---|---|---|
| SQLite with FTS5 | Text search with relational metadata available through SQL | How queries combine text, relationships and application access rules |
| ObjectBox | On-device vector search alongside an object data model | How similarity, relationships and application policy fit the model |
| Couchbase Lite | Local document queries with vector, full-text and other filters | How query filters, indexes and replication fit the workflow |
| 8DB | Native representations, evidence-bearing search results and candidate admission | How connected evidence and policy can work together in the retrieval path |
The opportunity for 8DB is the combination: several ways to find information, with explicit evidence and access decisions in the data layer. These alternatives also have useful ways to combine data. A matched application evaluation should establish which approach best serves your questions; this capability comparison is not a performance ranking.
Search is one part of 8DB's native breadth. Our time-series ingestion comparison examines another workload, while our process-level access article explains a separate protection boundary. Those results inform the design without becoming a speed or security guarantee for a combined assistant.
Bring the question people struggle to search for
Start with one question your users can describe but your application struggles to answer. Identify the clues, the source that would make an answer convincing, and who is allowed to see it.
That gives us a practical evaluation: can the system retrieve the right evidence, within an acceptable time, under the right permission? It is also the customer benefit we are pursuing with 8DB: making personal data easier for an assistant to use meaningfully.
Talk to us about an on-device retrieval evaluation. Bring one difficult question and a small approved corpus. We can define the evidence, latency and access checks together.
Evidence scope Recorded M1 keyword report · Native-search source review · Illustrative application design. Explore the evidence. Methods and retained scope notes.
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