Performance

This benchmark measures end-to-end round-trip throughput from the browser to the server and back, through real WebSocket connections with pipelined queries. Every operation is a full SQL query (SELECT or UPDATE) executed on the server.

Why is the browser slower than the CLI?

The KineDB CLI client (written in Rust) uses native threads and blocking I/O — each thread sends a query and immediately blocks on recv() until the response arrives, with zero overhead per message. The browser runs all 6 WebSocket connections on a single JavaScript thread. Every response goes through the event loop: onmessage → promise resolve → microtask → next query. At high message rates, the event loop becomes the bottleneck, not the server or the network.

How does this compare?

Transport	Typical ops/sec	Notes
Browser → REST/HTTP	1K – 2K	6 conn limit (HTTP/1.1), full headers per request
Browser → WebSocket	5K – 35K	Persistent conn, pipelined, binary protocol
Node.js/Bun → WebSocket	19K – 27K	No browser event loop overhead
Native CLI → WebSocket	100K – 140K	Rust threads, blocking I/O, zero overhead
Embedded (in-process)	100K – 500K	No serialization, no network

Browser WebSocket limits (industry data)

• Performance degrades above 200 messages/sec per connection in academic benchmarks
• Chrome allows up to 255 concurrent WebSocket connections
• REST from a browser is limited to 6 concurrent HTTP/1.1 connections per domain
• SpacetimeDB’s “150K TPS” claim is measured server-side, not from a browser client
• No major database publishes browser-to-server throughput numbers

Why do numbers vary between runs?

V8’s JIT compiler optimises hot loops progressively (Ignition → Sparkplug → Maglev → TurboFan). A fresh page load starts cold; subsequent runs on the same page are faster. Switching to another tab activates Chrome’s background throttling, which can drop throughput dramatically. For consistent results, keep the tab focused and run the benchmark 2–3 times before recording.

Sources: Chrome connection limits (GeeksForGeeks), WebSocket performance study (Linköping University), Daniel Lemire’s Node.js/Bun WS benchmark, SpacetimeDB 2.0 benchmark analysis (HN).