Your application still has a job when the network goes away. It needs to save the next observation, protect what it already holds, and get the right information to the right recipient when the connection returns.
In a completed local telemetry rehearsal, 8DB captured 16,384 records while disconnected, then delivered them alongside 128 new records. A separate verifier reconciled all 16,512 records, their exact content and signed receipts. A fresh process reopened the stores and confirmed the expected data with no pending deliveries. This was a vendor-run Linux rehearsal using local TCP endpoints and test keys. Rehearsal evidence
That is the storage story worth evaluating: capture, protection, delivery and recovery working together. 8DB is an embeddable, omnimodal database, so that foundation can serve an application that needs more than one kind of data operation.
Follow the work, not just the write
The useful question for a field application is whether saved work remains usable throughout its journey. For a sensor system, that could mean collecting observations offline and delivering a verifiable backlog. For an inspection application, it could mean keeping a service record connected to its location and history. The telemetry rehearsal tests the first workflow; the richer applications are deployment opportunities to qualify.
Fewer moving parts between capture and delivery
8DB brings native data operations, protected capture and verifiable delivery into the same product. For a field application, the practical advantage is less work connecting the database to the rest of the job.
| Customer need | What 8DB brings | How the alternatives compare | Why it matters |
|---|---|---|---|
| More than key-value storage | Native time-series, graph, spatial and analytical operations alongside storage | RocksDB, LMDB and redb provide key-value foundations; richer operations require application logic or additional engines | Potentially fewer stores and copies to connect, secure and recover |
| Proof that the right records arrived | The completed telemetry rehearsal checked exact content, signed delivery receipts and a fresh-process reopen | SQLite / SQLCipher provide local storage and encryption; the application must supply or integrate this delivery-and-verification workflow | Less delivery and audit plumbing for the application team to build |
| Useful work without a connection | 16,384 offline records delivered with 128 new records in the completed rehearsal | Couchbase Lite also supports offline work and direct peer sync. Here, compare 8DB's native data operations and required protection with the complete Couchbase deployment | Keep collecting locally, then reconcile the backlog; offline sync alone is shared capability |
| Data that stays useful on the device | An embeddable engine with several native query modalities | SQLite / SQLCipher offer embedded SQL; Couchbase Lite offers embedded document queries and sync; the key-value engines need application-level query logic | More ways to use local context before uploading it or assembling another service |
Capability and workflow comparison. Fewer integrations, copies and recovery procedures are architectural benefits to evaluate, not measured cost savings. The completed telemetry evidence covers the stated rehearsal; the larger interruption test below remains unfinished. Sources: SQLite, SQLCipher, RocksDB, LMDB, redb and Couchbase Lite peer synchronization.
For an inspection team, that could mean keeping an observation, its location and its equipment history together on the device, then delivering a verifiable record when connectivity returns. 8DB's advantage to evaluate is how much of that complete application one engine can cover. The native performance articles linked below provide evidence for individual modalities; this richer inspection workflow is a deployment opportunity, not a completed benchmark.
More than a day of actual disconnected capture
The next scale milestone is complete reconnect and recovery verification for a longer campaign that already recorded 864,000 local acknowledgments over more than 24 hours. The completed rehearsal above is the starting point for evaluating your field workflow.
The selected security profile intentionally refused protected access after the boot identity changed. The tested Linux recovery path now supports fresh, signed authorization controlled by the deployment owner, including an offline approval exchange. It permits bounded verification and export into private quarantine while keeping expired service permissions inactive. Release qualification and full recovery and delivery reconciliation for the interrupted campaign remain open; the completed smaller rehearsal is a separate result. Recovery evidence and scope
Faster reopening and less repeated writing
The lower layers contribute their own opportunities. In a historical Apple M1 test, the Zero-WAL path opened a store with 50,000 committed records in 0.098 ms, versus 110.6 ms for 8DB's own WAL path: about 1,100× faster for this warm, clean storage-manager reopen. It did not time a complete application restart or recovery after physical power loss.
A newer native section-batching candidate reduced application-issued payload writes by 31.8%, from 33.83 MB to 23.08 MB. All three matched pairs retained 109 commits and 109 WAL syncs, with fresh-reopen checks. The synthetic capture-shaped fixture used strict WAL with encryption off; production adoption gates remain open. This measures fewer bytes issued by the application, not physical SSD wear or energy savings.
For battery-powered devices and nonreplaceable storage, avoiding unnecessary work could matter as much as peak speed. The byte reduction is measured. Its effect on battery life, physical writes and device lifetime needs instrumented testing in the intended deployment.
Keep the application responsive while saving
A separate M1 mixed-load campaign recorded 2.44–3.40 ms read p99.9 across three valid runs while offering 1,000 writes per second, with durable commits every 100 writes. Across 1,603,273 verified reads, the retained campaign record reports zero value errors. These are internal mixed-load results, not a matched competitor ranking; they measure batched durability rather than one durable commit per write.
That is a useful direction for a field application: collect new work while the user can still consult the history. The store's batching and persistence choices belong in that decision alongside its fastest standalone benchmark.
Where the single-write results fit
The retained single-write observations complement the recovery and mixed-load results. A single durable PUT does not price the entire application. An evaluation should compare completed work with equivalent protection, plus first useful query, delivery, recovery, memory and background maintenance.
One storage foundation, many native capabilities
An inspection record, a time series, a location and a relationship may all belong to the same application. 8DB's native modalities create an opportunity to reduce the number of stores, copies and recovery procedures that application needs. The savings depend on the actual replacement architecture and remain to be measured.
Our separate articles cover time-series ingestion, key-value performance, graph lookups and analytics. Each has its own measured scope; their headline results are not added together into an untested combined claim.
Bring us the work your application must preserve, the query it must keep answering and the interruption it must survive. Plan an evaluation around that complete job.
Evidence scope 8Braid telemetry rehearsal · Separate recorded storage tests · Larger recovery campaign unfinished. 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