Browser & WebAssembly
Running the NetlyDB engine inside the browser, so a web application keeps its data on the visitor's device and keeps working with no connection at all.
Online once, offline from then on
A Blazor WebAssembly application is served by your web server like any other site. With browser support, NetlyDB is part of what the browser downloads: the engine, compiled to WebAssembly, starts on the visitor's device. From that point on, every read, query and write runs locally, and the data is stored in the browser's own persistent storage. The connection can drop, or never come back, and the application keeps working with the data it has.
- The server delivers the application, not the data path. No request goes to your server to read or write a document.
- Data survives reloads and restarts. It is stored in the Origin Private File System (OPFS), private to your site's origin.
- Loading the application itself without a connection - for example as a progressive web app that caches its own files - is part of your application, as it is for any offline web app. NetlyDB does not need the network at all.
The same engine, not a browser database
Browser support does not introduce a second database. The engine that runs in the browser is the one that runs on a server: the same write-ahead log, snapshot generations, recovery, queries and indexes. What changes is the profile around it - how it is scheduled, where it stores data and how it claims ownership of a store.
- Your Blazor WebAssembly UI
- Dedicated worker: the NetlyDB engine
- Storage worker: OPFS file handles
- Origin Private File System, on the device
- Off the UI thread. Database work never runs on the thread that draws the page. Your application will call it through an asynchronous API.
- One thread, same order. On a server, each collection commits and applies writes on its own threads. The browser runtime is single-threaded, so in the browser each write performs those steps itself, in exactly the same order: logged and flushed before it is applied, applied before it is confirmed. Both strategies run the engine's test suites on every change.
- One tab owns a store. A store has one writer, as everywhere else. A second tab or worker that opens the same store is refused until the first releases it, including after the first tab crashes.
- Fail closed. If the browser cannot provide what the engine needs, the database refuses to open for writing rather than running on weaker guarantees.
What has been shown so far
The real engine now runs end to end in a browser worker on OPFS. These scenarios pass in continuous integration on headless Chromium on Linux, each checked against a record of every write the browser confirmed:
| Scenario | Result |
|---|---|
| Open an empty store, insert, read back by id, run a filtered query | Passes |
| Inserts, updates and deletes; clean shutdown; reopen in a new worker with every document intact | Passes |
| Worker terminated without shutdown; recovery from the write-ahead log alone | Passes |
| Snapshot published, more writes, worker terminated; recovery from the snapshot plus the log | Passes |
| Workers terminated in the middle of a stream of writes: every confirmed write recovered, nothing reordered | Passes |
| Storage worker lost mid-write: the write in flight is never confirmed, and recovery finds it wholly present or absent | Passes |
| Two workers open one store at once: exactly one wins; the other takes over after a clean close or a crash | Passes |
| Snapshots and log compaction scheduled inside the worker, alongside the application's own writes | Passes |
| The whole browser process killed and relaunched on the same profile, repeatedly: every confirmed write recovered | Passes |
| Two tabs on one store with the real engine: one owns it; the other takes over after the first is closed or crashes | Passes |
| A newest snapshot that cannot be used and a log that cannot carry an older one forward: the store is refused, never opened with missing writes | Passes |
On that evidence the browser design passed its viability gate in October 2026: the shared engine works in the browser architecture above without a second engine or a browser-specific storage format. That is a technical decision, not a support claim. Still to come before browser support can be released: durability testing beyond a browser crash, behaviour when the browser evicts or partly clears site storage, other browsers and operating systems, and the public packages, API and documentation for Blazor applications.
Hosting requirements
The engine reaches OPFS synchronously through a SharedArrayBuffer shared with the storage worker. Browsers
allow that only on a cross-origin isolated page, so the current design needs your server to send
Cross-Origin-Opener-Policy: same-origin and Cross-Origin-Embedder-Policy
(require-corp or credentialless). Isolation can affect sign-in pop-ups and third-party
embeds, so whether it can be avoided safely is being investigated; it will not be avoided by weakening a guarantee.
Planned scope of the first browser release
Being confirmed feature by feature in the browser test host:
- typed document collections, CRUD, and revision-based conditional updates and deletes;
- LINQ and string queries, scalar and compound indexes, and full-text search;
- persistent OPFS storage and offline operation;
- write-ahead log and snapshot recovery, snapshot retention and log compaction;
- document expiry and memory governance, run by a scheduler inside the worker.
Out of the first browser release, and refused clearly rather than left to fail:
- file and media collections, encryption at rest, and clustering or replication;
- the Management UI, REST API and MCP server, which are server-side modules;
- vector indexes, which are planned for a later browser release;
- several tabs sharing one store, and synchronisation with a back end. The design leaves room for application-level synchronisation later; none ships in the first release.
What is not claimed
- Surviving a browser crash is not surviving a power loss. Data has survived the browser being killed. Whether the browser's flush reaches the physical device is a separate question, still to be tested, and the guarantee will be stated no stronger than what is shown.
- Browsers can evict site storage. Unless the site is granted persistent storage, the browser may clear it under storage pressure. Keep an authoritative copy of data that must not be lost.
- Chromium on Linux is the only environment tested so far. No other browser or operating system is claimed.