Source-linked AI summary
Zeta-Lite: A Concurrent, Branchable In-Browser SQL Database for Agentic Memory
Gene Zhang
TL;DR
In-browser applications need private, durable, structured storage, but conventional PostgreSQL-derived browser databases cannot express concurrent transactions and may lack richer capabilities. Zeta-lite compiles Zeta’s log-centric MVCC engine to a 2.87 MB WebAssembly artifact, delivering overlapping snapshot-isolated transactions and copy-on-write branching alongside a feature-complete PostgreSQL surface. It sustains 268k-315k point reads/s across browser and native runtimes while supporting agentic-memory exploration through branchable state.
Problem
In-browser applications need private, offline, structured storage, while PostgreSQL’s single-connection process model cannot express concurrent transactions and may omit richer capabilities such as graph queries and database branching.
Method
Zeta-lite compiles the Zeta server’s log-centric asynchronous MVCC engine to WebAssembly and exposes overlapping transactions, copy-on-write branching, and a feature-complete PostgreSQL surface.
Results
Zeta-lite delivers overlapping snapshot-isolated transactions and whole-database copy-on-write branching in a 2.87 MB gzipped artifact, sustaining 268k-315k point reads/s across browser and native runtimes.
Takeaways & Limitations
Branchable persistent state makes zeta-lite a strong fit for agentic memory, where agents can explore speculative changes and keep or discard the result.
Takeaways & Limitations
Concurrency is limited to interleaving transactions between statements; in-query parallelism requires a future thread-enabled build and is out of scope here.
Abstract
from arXiv · showhide
The browser has become a first-class database host: applications increasingly want to store, query, and reason over structured data entirely on the client - for privacy, offline operation, local-first collaboration, and, most recently, as durable memory for in-browser AI agents. One way to get SQL in the browser, compiling PostgreSQL to WebAssembly (PGlite), inherits PostgreSQL's process model: a single backend connection that executes one statement at a time and blocks. That model cannot express concurrent transactions, and it leaves richer capabilities - graph queries, database branching - to whatever the compiled server happens to include. We present zeta-lite, the browser form factor of the Zeta database engine: a WebAssembly build that compiles the same Zeta server down to a 2.87 MB gzipped artifact. Zeta-lite keeps the engine's log-centric asynchronous MVCC core, which yields two capabilities no other in-browser SQL engine provides. First, overlapping snapshot-isolated transactions on a single thread: multiple transactions hold distinct read/commit timestamps and interleave, with snapshot-isolation conflict detection between them. Second, copy-on-write database branching - whole-database fork, merge, and rebase - is unique in a browser SQL database and rare even in servers. On top of these, zeta-lite exposes a feature-complete PostgreSQL surface (joins, CTEs, window functions, JSONB with GIN indexes, full-text search, HNSW vector search, SQL/PGQ graph queries, multi-database) and snapshot-to-OPFS durability. Across Chrome, Firefox, and a native reference runtime, zeta-lite sustains 268k-315k point reads/s and holds a mixed read/write workload flat over millions of operations. This small, fully-featured, concurrent SQL database is an especially good fit for agentic memory - where cheap branchable state lets an agent explore, inspect, and commit or discard speculative work.
1 Introduction
Zeta-lite targets browser applications that need private, offline, structured data and addresses the serial, feature-limited model inherited by PostgreSQL-to-WebAssembly systems. Its log-centric MVCC core combines overlapping snapshot-isolated transactions and copy-on-write branching with a 2.87 MB gzipped, feature-complete SQL artifact.
- Browser applications increasingly need structured, private, durable client-side data for offline use, collaboration, and in-browser agent memory.
- PostgreSQL-to-WebAssembly systems inherit a single blocking backend connection, limiting concurrency and leaving capabilities such as graph queries or branching to the compiled server.
- 2.87 MB gzipped is the artifact size for the browser build, which retains the Zeta engine’s log-centric asynchronous MVCC core.
- The browser build adds a feature-complete PostgreSQL surface and snapshot-to-OPFS durability without workers, SharedArrayBuffer, or cross-origin-isolation headers.
- Overlapping snapshot-isolated transactions interleave on one thread with distinct snapshots and conflict detection, but not sub-statement parallelism.
- Copy-on-write branching supports whole-database fork, merge, and rebase, using MVCC row versioning already present for isolation.
2 Background and Related Work
Related systems occupy different browser database trade-offs: PGlite provides broad PostgreSQL compatibility but serializes transactions, while other engines emphasize narrow, analytical, or server-tier branching capabilities. Zeta-lite’s stated delta is overlapping snapshot isolation and whole-database branching at a similar gzip size to PGlite.
- PGlite offers a large PostgreSQL surface and OPFS persistence, but its single-connection architecture serializes transactions rather than executing them concurrently.
- SQLite-wasm is small and narrow, PGlite is similarly sized with serial PostgreSQL transactions, and DuckDB-wasm targets analytical columnar workloads.
- Database branching is generally implemented at server or storage tiers, as in Dolt, Neon, and PlanetScale, rather than as an in-browser SQL capability.
- Zeta-lite claims overlapping snapshot-isolated transactions and whole-database branching at a gzip size in the same class as PGlite.
3 System Architecture
Zeta-lite compiles a shared Zeta codebase into a small browser form factor, retaining server-grade SQL and log-centric MVCC semantics while using WebAssembly memory and snapshot-based persistence. The same timestamped log supports overlapping transactions and whole-database branching.
- The engine runs inside WebAssembly, with JavaScript driving queries and wasm-bindgen bindings connecting capabilities to browser Web APIs.
- 3.1 The Zeta family and the compile-down bet: The browser build keeps the shared Zeta codebase’s SQL front end and execution engine while specializing the storage and runtime for a browser tab under 3 MB.
- 3.2 The log-centric asynchronous MVCC core: Timestamped log versions give transactions consistent read snapshots and enable statement-boundary interleaving with snapshot-isolation conflict detection on one thread.
- The SQL surface includes PostgreSQL-style joins, CTEs, subqueries, windows, aggregates, mutations, and secondary indexes, with materialized or streaming results.
- Streaming cursors keep peak query memory at O(batch) rather than O(result-size), which bounds large scans in the browser.
- Snapshot-to-OPFS persistence serializes the in-memory database out of band, trading durable-by-default commits for a small dependency-free artifact.
- 3.6 Database branching as a consequence of the log: A branch is a fork timestamp over the shared log, enabling whole-database merge, rebase, and discard without separate storage machinery.
- In v0.1, exportSnapshot() does not serialize branches, so branches must be merged or dropped before persistence.
4 Executing in the Browser: wasm, not WASI
Zeta-lite uses JavaScript and Web APIs rather than WASI because browser WebAssembly receives capabilities through host-provided imports, while WASI targets POSIX-like capabilities in server or CLI runtimes. Its bindings route persistence and randomness to browser APIs through wasm-bindgen.
- WebAssembly supplies sandboxed computation but no ambient files, clocks, networking, randomness, or standard I/O; hosts must explicitly provide imports.
- WASI standardizes POSIX-like filesystem, clock, randomness, and file-descriptor imports for wasm modules outside the browser.
- The browser supplies equivalent capabilities through JavaScript and Web APIs, including OPFS for persistence, crypto.getRandomValues for entropy, and performance.now for time.
- Figure 1’s dashed edges represent capability bindings that cross the sandbox through wasm-bindgen and terminate on Web APIs rather than WASI syscalls.
- Zeta-lite targets wasm32-unknown-unknown and uses wasm-bindgen’s web target, with browser implementations of its platform traits supplying randomness and OPFS persistence.
- A server-side or CLI build would instead target wasm32-wasip1 and use WASI to reach a real filesystem.
5 Persistence: Snapshot-to-OPFS Durability
Zeta-lite separates in-memory execution from durability by exporting complete database snapshots to OPFS, avoiding per-write filesystem synchronization and special browser isolation requirements. The trade-off is coarse-grained durability: commits after the last persisted snapshot can be lost, and branches cannot yet be snapshotted.
- The Memory backend keeps the whole database in WebAssembly linear memory, making durability a separate mechanism from each write.
- exportSnapshot() serializes the catalog, row versions, and timestamp high-water mark into one Uint8Array, while openFromSnapshot(bytes) restores an equivalent database.
- Snapshot-on-demand uses asynchronous OPFS directly on the main thread, avoiding workers, SharedArrayBuffer, and special cross-origin-isolation headers.
- 44 ms: export-to-rehydrate cycles averaged this time for blobs up to ∼2 MB.
- Snapshot durability means commits after the last persisted snapshot can be lost after a crash, reload, or tab close, so applications must checkpoint important writes.
- In v0.1, snapshots do not capture branches, so branches must be merged or dropped before persistence.
6 The SQL Surface as Agentic Storage
Zeta-lite combines a broad SQL surface with agent-oriented storage and branchable state. Its heterogeneous retrieval capabilities support structured, textual, semantic, and graph-based memory, while branching enables isolated speculative work that can be merged, rebased, or discarded.
- 6.1 The surface an agent wants: An agent’s heterogeneous memory maps to JSONB and full-text, vector, graph, and multi-database capabilities within one 2.87 MB SQL engine.
- 6.2 Database branching as agent exploration state: Without branching, agents must restore whole snapshots, reconcile scratch tables manually, or maintain application-level undo logs.
- 6.2 Database branching as agent exploration state: Database branching lets an agent fork persistent state, perform speculative work in isolation, inspect the result, and merge or discard it without cleanup.
- 6.2 Database branching as agent exploration state: Branching is demonstrated through SQL that creates a branch, isolates inserted data, resets to main, and merges the branch back.
- 6.3 Companion system: Zengram-lite is presented as a forthcoming companion system built on vector-indexed memory, graph queries, and branchable state in the same 2.87 MB engine.
7 Evaluation: Throughput under Concurrency, Coverage, and Size
The evaluation tests concurrency, throughput, sustained-load stability, feature coverage, and artifact size using the published WebAssembly artifact across browsers and a native reference. Zeta-lite supports overlapping snapshot-isolated transactions, maintains high and stable single-thread performance, and combines broad SQL coverage with a 2.87 MB gzipped artifact.
- Concurrency: Across 5,000 contention trials, overlapping transactions updating the same row produced exactly one commit and one write-write conflict abort in all three runtimes.The test verifies snapshot-isolation conflict detection under overlapping snapshots.
- Concurrency: 40,000 disjoint-key commits across eight concurrent transactions completed with zero conflicts, confirming that only genuine write-write conflicts abort.The experiment distinguishes permitted overlap from conflicting writes.
- Sustained-load stability: 1.00 throughput stability held in Chrome and Firefox from 1,502 to 1,501 ops/s over 900,000 sustained operations, with no drift.The browser soak used a mixed workload rather than peak-throughput measurement.
- Sustained-load stability: The read-only settle phase grew wasm memory by +0 MB in both browsers, within a 32 MB budget, while insert-heavy growth reached 131 →195 MB.The reported insert-heavy growth is attributed to data accumulation; the settle phase is the leak test.
- Durability: A full OPFS export, write, read, rehydrate, and verification round-trip remained below 200 ms for a database growing to approximately 4.8 MB.Firefox measured 38 + 48 + 5 + 85 ms, while Chrome measured 34 + 19 + 2 + 78 ms.
- Artifact size and coverage: The 2.87 MB gzipped artifact matches PGlite’s size class while adding overlapping transactions, HNSW vector search, SQL/PGQ graph queries, and whole-database branching.SQLite-wasm is smaller at roughly 400 KB gzipped but has a narrower surface.
- Coverage: The validation harness checked 88 assertions covering relational, JSONB, full-text, vector, graph, multi-database, branching, and snapshot-restore functionality.Tests exercised the published wasm artifact through shipped examples and the concurrency demo.
8 Limitations and Future Work
Zeta-lite’s v0.1 preview has explicit boundaries around concurrency, threading, durability, branching snapshots, analytical workloads, measurement, and minor surface gaps. Future work targets threaded execution, branch-aware snapshots, in-browser soaking, and agentic memory.
- Concurrency: Concurrency overlaps transaction lifetimes between statements, but individual statements execute synchronously without interior yields.In-query parallelism requires a future SharedArrayBuffer- and wasm-threads-enabled build, outside the headers-free form factor.
- Concurrency: The browser build is single-threaded, so its throughput ceilings are single-core and limit embarrassingly parallel workloads.The paper considers this adequate for browser workloads by a wide margin.
- Durability: Durability is snapshot-based: commits become durable only at the last persisted snapshot, with no per-commit fsync.
- Durability: Snapshots currently cannot capture branches, requiring branches to be merged or dropped before persistence.The paper identifies this as a v0.1 implementation gap rather than a design boundary.
- Workload scope: The browser artifact is row-oriented OLTP rather than an OLAP or columnar engine, which belongs to a separate larger Zeta form factor.
- Evaluation scope: Per-operation latency is measured natively because the browser’s approximately 1 ms timer clamp makes sub-millisecond in-browser timings unusable.The in-browser soak instead validates throughput stability, memory behavior, and OPFS cost.
- Surface gaps: Minor surface gaps include unfiltered schema-sidebar listings and no bundled model for embed(), without affecting SQL semantics.Applications must register a synchronous JavaScript embedder or bind precomputed vectors.
- Future work: Future work includes in-query parallelism, branch-aware snapshots, an in-browser soak, and the zengram-lite agentic-memory system.
9 Conclusion
Zeta-lite challenges the assumed trade-off between a small browser artifact and rich SQL capabilities by combining concurrent snapshot-isolated transactions, database branching, and a feature-complete PostgreSQL surface. Its shared log-centric MVCC design makes the system a natural substrate for agentic memory, where agents can explore alternatives and commit or discard speculative work.
- 9 Conclusion: Zeta-lite combines snapshot-isolated transactions, whole-database copy-on-write branching, and a feature-complete PostgreSQL surface in a 2.87 MB gzipped artifact.
- 9 Conclusion: Both headline capabilities derive from representing transaction and branch views as timestamps over an append-only log.The paper presents this shared mechanism as the architectural point enabling a small artifact to behave like a larger system.
- 9 Conclusion: Branchable, semantic, and graph-queryable state lets agents explore hypotheses and commit or discard speculative work at timestamp cost.The companion zengram-lite system builds on these primitives, while zeta-lite remains the underlying engine.