If you'd used leveldb from the beginning you wouldn't have this problem as it will happily work on the server and in the browser https://www.npmjs.com/package/level-js
Yes I see that. But if IndexedDB were supported on Node I also would not have this problem. So the question is, why can't node just support IndexedDB (which is formally specified in a standards document) instead of inventing an extremely similar but incompatible api?
Because IndexedDB is a W3C spec[0] intended for web browsers and LevelDB is a third-party npm module[1].
Node is just a JS environment. Implementing IndexedDB is as much out of scope as implementing XHR[2] or the File API[3]. In fact it provides the building blocks developers to implement any of these on top of Node should they need to (like node-fetch[4] implementing the Fetch API[5] for isomorphic apps).
This just begs the question. The question is, what about IndexedDB, XHR, the File API, etc. make them unsuitable for pure-JS environments?
Because there is nothing about the problem domains (indexed key/value store, asynchronous web requests, filesystem I/O) that are specific to web browsers.
If a problem domain is common across browsers and pure-JS environments, then it should follow that there can be common APIs. If some part of the API is necessarily specific to one or the other, then ideally these differences should be localized to small parts of the API.
That's an intuitive assumption but it's naive (i.e. it lacks understanding of the actual domain concerns).
JS in the browser needs to be sandboxed by default and has to handle concerns like cross-origin policies and interactively seeking user permissions. It also has some fairly browser-specific singletons (e.g. a shared global cookie storage).
The equivalent built-in node APIs are much more low-level, allowing developers to use abstractions that are useful in their problem domain.
Having an IndexedDB implementation in node core would be an incredibly pointless effort (most apps out there won't use it) and bring with it several complications (e.g. pluggable storage backends and concurrency conflicts if you want multiple node processes to share the same database). Plus it would mean the Node Foundation would have to get involved in the standardization process to make its concerns heard and likely introduces concerns that are irrelevant to everyone else (i.e. browser vendors).
Don't forget that Node is not a web framework. It's a JS runtime environment. It is primarily used for things that talk over the web or that generate content for the web, but it's not at all unreasonable to implement other things in it (e.g. mail servers). The web specs carry a lot of overhead that is simply unnecessary for most node applications even if it is perfectly necessary in browsers.
The only spec I can think of that I'd like to see in node is the Fetch API and for that we have node-fetch, which just wraps node's low-level http module.
What I'm trying to say is that node doesn't need these high-level APIs because it can give you the low-level APIs to implement them with. Browsers can't do this, so they need to work at an entirely different layer of abstraction. Plus node allows you to easily include native extensions whereas in the browser you can't have that (except for NaCl).
