"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.

You have web workers, and for shared memory and synchronisation respectively SharedArrayBuffer and the Atomics namespace.

This sounds pretty insane if you wrote any database code that needs to care about memory management at all

Are you hoping to, like, run postgres in nodejs or something?

You can get parallelism with web workers and shove sqlite over there if you like, e.g. for running more intensive queries. Beyond that I kinda don't see much of a reason to use JS for databases, except maybe for isolation (e.g. via wasm).

I honestly should print that comment and hang it on a wall.

> …competitively-performant… Care to explain competitively to what?

…but why? JS/TS does not seem like the right tool for the job?