"I genuinely think you could write a competitively-performant multi-threaded DB in Bun + TS if you had shared-heap threads and fast atomics/locking primitives."

Not likely. Databases that attain any significant use in the field end up getting optimized to the n'th degree because they're the bottleneck of the entire system of every system they get put into. Javascript runs on the "5-10x slower than C" language tier. Personally I think even picking Go, in the "2x slower than C" tier, is a huge mistake, though a few people seem to be doing OK with it. I don't think you can call it "competitive" when your C++ or Rust competition is consuming a factor of magnitude less resources.

WASM DBs, maybe, especially as it continues to mature. Not Javascript.

Something compiled to WASM still gives a fair amount of control over memory layout, something that AFAIK is not possible in JS without building effectively a new embedded language on top of an array (Emscripten being an existence proof that you can do more or less anything that way).

One place where an interpreter + JIT language could be interesting is if it were sufficiently safe to allow user code into the query execution engine, such that the JIT could optimize it all together.