These libs have been used in read-only mode for several releases now. There have been no native database write operations for a while, as Thorium transitioned to JSON serialisation instead (a mirror image the structured internal application state).

The native libs and their Javascript counterpart code have been kept in Thorium to allow a time period during which application releases would remain capable of pulling data out of the legacy DB binary formats, and migrate the data into the new persistence model.

Note that SQLite3 is shipped in "developer" builds (automated via Continuous Integration / GitHub Actions workflow), whereas LevelDown is used in "production" builds (i.e. official releases, or locally-run executables). This segregation made it possible to install / launch both dev and prod builds on a given computer, and avoid data leaking across variants.

The official production builds / releases include an extra build step that patches package.json and src/package.json to remove SQLite3 references, in order to avoid "signing" issues (on Windows especially, as the makefile filename is not stable across rebuilds).

Note that the long processing time at postinstall stage (Electron rebuild in package.json), as well as when creating the official releases (src/package.json) is due to Node GYP orchestrating the compiler to build the C/C++ code of the native modules, when pre-compiled libs downloads are not available for the specific version of Electron used by Thorium. The postinstall stage is inevitable, as by default the package manager (NPM) infers the target Node platform from the computer on which it is running, so we have to instruct the framework to target the correct version of Node that ships with the currently-used version of Electron (which evolves over time).

So, long story short: the project will benefit from removing the SQLite3 and LevelDown dependencies. Let's make this happen in Thorium v2.0.0