An embedded database is judged first on how fast it takes a write, and the fair way to judge is to measure the competitor on the same host, in the same run, through the same interface. On 20 May 2026 we did that on an M1 MacBook Pro, macOS 26.2, Rust 1.94.1, release build with link-time optimisation, with SQLite measured through its own C interface in the same Criterion process. 8DB exposes three ways to write, each trading a documented thing for a measured benefit, and all three are below.
The three paths
| Path | Insert cost | 95% interval | Against SQLite, same run | What you trade |
|---|---|---|---|---|
| Native ring, direct API | 99 ns | [98.4, 99.7] | About 15 times faster | The SQL surface. The application calls the engine directly and owns governance. |
| SQLite-compatible shim, deferred-write mode | 522 ns single; 435 ns per row batched 1,000 | [518, 526]; [432, 437] | About 2.9 times faster single, about 2 times batched | The first read after a burst of writes drains the queue once, amortised over the burst. Read-your-own-writes is preserved and tested. |
| SQLite-compatible shim, full governance per call | 39.9 µs single; 35.7 µs per row batched 100 | [34.8, 36.9] batched | About 21 times slower per call | Nothing is lost; the write also produces confidence, provenance, a governance check, a perceptual hash and cross-modal queryability, synchronously. |
The drop-in path is the one most readers want. It is binary-compatible with the C interface every app already uses, it is faster than SQLite on the same host in the same run, and a read issued after pending writes sees them, which the test suite checks under the deferred-write flag. The cost is a one-time drain of the write queue on the first read after a burst, plus a check of about 28 ns at read entry to see whether the queue is empty.
The native path is for pipelines that already gave up SQL for speed. Telemetry ingest, write-heavy logs, embedding backfills and internal indexers commonly drop to raw storage and lose their query language doing it. The ring path gives them the speed and keeps the store queryable.
The governed path is a different product. Its per-call cost is high because it does on one call what an application stack does in several passes: the row, the search-index update, the perceptual hash, the embedding match, the policy check and the provenance record. Whether 35.7 µs per row is expensive depends entirely on whether you would otherwise have built and scheduled that pipeline. On a device, the pipeline is the background daemons, and their energy is the subject of the battery article in this series.
Where SQLite wins today
Point reads. The shim's point read measured 413 ns against SQLite's 286 ns in the same run, a factor of about 1.44. Both numbers were slower than the same benchmark's earlier reference values by amounts consistent with the load on the machine at the time, which is recorded with the run. A comparison that shows only the wins is not a comparison, so this row stays.
How to reproduce
The harness is a Criterion benchmark in the engine's repository, run with the external-evaluation feature set and, for the drop-in row, the deferred-write environment flag. It measures SQLite through the same C interface on the same host in the same process lifetime. Given the source, the command and the host description, an evaluator reproduces the table above with their own intervals. That is the standard every number on this site is held to.
What to bring us
- Your insert workload. Bulk ingest, telemetry, write-heavy logs or a backfill. We will run the three paths on it and return the intervals.
- Your read-after-write pattern. If your application depends on seeing its own writes immediately, the deferred-write path is the one to try to break.
- A quiet machine. These runs were taken under recorded system load. One clean run on hardware we do not otherwise use replaces the caveat with a number.
Write to hello@8braid.com with the subject "8DB shim versus SQLite: run our workload". You will hear back from an engineer.
Evidence notes
Earlier internal documents compared only the full-governance path against a raw SQLite insert and reported the shim as slower; that comparison measured a governed pipeline against a row write and has been retired in favour of the three-path table above, which was measured in one run with SQLite on the same host. Ratios in this article are between numbers measured in that run. No end-to-end comparison against Apple's application frameworks is claimed, because we have not measured them running this workload.
Sources and further reading
- SQLite C interface and SQLite performance guidance
- Criterion.rs
- 8DB: One Store Under Every App: 8DB on Apple Silicon, by the Numbers
- 8DB: Every Number on This Site Has a Harness
Measurements were taken by 8Braid on one M1 MacBook Pro on 20 May 2026 under recorded load and describe 8DB and SQLite as run by us on that host; they are not measurements of Apple's production software. Apple, M1, Mac 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