Replicache, which author loves, is also built on top of IndexedDB.

But notably, not directly atop. We build our own KV store that uses IDB just as block storage. So I sort of agree w/ you.

But if we were to build atop OPFS we'd also just be using it for block storage. So I'm not sure it's a win? It will be interesting to explore.

I think you’ll find it’s a performance win.

	▲	aboodman 4 days ago \| parent [-]
		It's not so cut and dry. The majority of the cost in a database is often serializing/deserializing data. By using IDB from JS, we delegate that to the browser's highly optimized native code. The data goes from JS vals to binary serialization in one hop. If we were to use OPFS, we would instead have to do that marshaling ourselves in JS. JS is much slower that native code, so the resulting impl would probably be a lot slower. We could attempt to move that code into Rust/C++ via WASM, but then we have a different problem: we have to marshal between JS types and native types first, before writing to OPFS. So there are now two hops: JS -> C++ -> OPFS. We have actually explored this in a previous version of Replicache and it was much slower. The marshalling btwn JS and WASM killed it. That's why Replicache has the design it does. I don't personally think we can do this well until WASM and JS can share objects directly, without copies.