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
A subsequent campaign completed 864,000 locally acknowledged records over 24 hours, 9 minutes and 52 seconds. That was elapsed execution, not an accelerated clock simulation. A WSL kernel panic interrupted the later reconnect stage, so full payload recovery and delivery verification remain unfinished for that larger campaign. Recorded outcome
The selected security profile intentionally refused protected access after the boot identity changed. Work is underway on fresh, signed recovery authorization controlled by the deployment owner, including an offline approval exchange. Its first scope is verification and export; it must not revive expired service permissions. This is an accepted design under implementation, while the completed smaller rehearsal remains a separate recovery result. Recovery decision
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
Single-operation latency still matters. In the June M1 campaign, SQLite FULL with macOS fullfsync enabled recorded 5.08 ms per commit, compared with 10.50 ms for 8DB SyncNow. SQLite was faster in that historical configuration. Later 8DB SyncNow observations were 5.54–5.64 ms, but the contemporary RocksDB reference used different keys, values and timer boundaries, so it cannot establish a precise ranking.
Those observations belong beside the recovery, mixed-load and workflow results. A single durable PUT does not price the entire application. The next matched comparison will include equivalent protection and completed work, 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 notes
This article combines separately identified 8Braid engineering campaigns, not a single universally qualified build. The telemetry source is a96ab656; the warm-reopen source is 366e87e4; the batching candidate is 450940d4 against b271c198. Mixed-load results are retained Airtable campaign evidence; original raw timing files remain a recovery gap. Full source mapping is retained in 8Braid's benchmark archive; the underlying telemetry reports are not public downloads. No physical power-cut, energy, full ACID certification or government approval is asserted.
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