maitrungduc

That constraint is the part I find most interesting here. The wal-index lives in the -shm file, which SQLite never really uses as a file: clients mmap it and treat it as shared memory, and access to it is coordinated through xShmLock rather than ordinary file locks. The race needs two connections because it needs that shared coordination layer to exist at all.

It also hints at why it could hide for sixteen years. Almost everything below the pager can be swapped out through the VFS interface, and there are plenty of unusual VFSes exercising those paths. The shared memory methods are the exception. WAL normally requires xShmMap, xShmLock, xShmBarrier and xShmUnmap, and unix and windows are effectively the only two implementations of them that see real traffic.

Everyone else opts out rather than implementing them, because SQLite documents an escape hatch: set locking_mode=exclusive before the first access and the wal-index is kept in heap memory with no shm file at all. That is the road the browser builds take. The WASM build has no shared memory APIs, so WAL on an OPFS database is only possible in exclusive mode, and the docs are blunt that this removes all concurrency in exchange.

So the alternative VFS world contributes close to nothing to the coverage of the exact code path this bug lived in. Everyone who might have been a third implementation stepped around it instead, which leaves finding it to someone on unix doing something unusual with checkpoints.

Thank you, really appreciate it.

Good news on that front: Vite and Svelte already work today. The Studio ships templates for Svelte 5 (Vite) and SvelteKit, alongside React, Vue, Astro, Nuxt, Solid, Qwik, Preact and more, and Vite is the default dev server for most of the frontend templates. If you open the Studio you can boot a Svelte + Vite project right now.

The Sandpack comparison is fair, though the approach differs a bit. Sandpack's classic setup bundles in the browser, whereas Vivari runs a real Node (plus Bun and Python) runtime with a virtual filesystem and a process model, so the actual npm dev server runs in-VM instead of a bundler standing in for it. Closer in spirit to WebContainer or CodeSandbox's Nodebox.

On the roadmap: near term I'm focused on hardening what's already there (Next.js and Postgres via PGlite are still experimental), expanding Bun coverage beyond the current shim, and improving the debugger and git support. I'll put up a proper public roadmap soon. If there's a specific framework or workflow you'd want, I'd genuinely like to hear it.