Repository navigation
[Proposal] Embed SQLite in NODEJS CORE #29378
Description
Activity
And, no. node-gyp is not an option.
It would help strengthen your case if you explain why. Precompiled and WASM-ified versions of sqlite exist - you would need to argue why those aren't sufficient.
Also, why sqlite and not $some_other_technology?
Reacted by snek and Jonah SniderI disagree personally to integrate it for various reasons, but for a security standpoint, maintenance work increasing and so on and so forth, while there is existing separated solutions.
Hi @bnoordhuis
And, no. node-gyp is not an option.
It would help strengthen your case if you explain why.
Precompiled and WASM-ified versions of sqlite exist - you would need to argue why those aren't >sufficient.node-gyp based solution: Pure node applications (JS/WASM) would take advantage of not having to rely onto external building tools at the sole expense of <1M of a binary increase in the node executable.
Zero-admin is another issue.the wasm version of SQLite: it's nice, but it's slower than native and takes more memory.
Besides, SQLite is FAA Compliant and transactional fail-safe.Also, why sqlite and not $some_other_technology?
Adoption scale. Being it (one of) the most installed and used library in the world with billions of users constantly (and mostly unknowingly) relying on it all the time makes SQLite one of the more robust pieces of code available.
Seniority and competence of its developers: its code is clean and well documented. A pleasure to read and really simple to embed.
-R
Anecdotally there are probably more users of node who either don't use a database or use a database that isn't sqlite, than users who use sqlite. The engineering work to integrate it, figure out API guarantees, make good bindings, etc., is probably better spent optimizing the wasm builds of sqlite.
Reacted by Jake and Ben NoordhuisPure node applications (JS/WASM) would take advantage of not having to rely onto external building tools at the sole expense of <1M of a binary increase in the node executable. Zero-admin is another issue.
Precompiled binaries address those pain points. Embedding sqlite harkens back to the abandoned WC3 Web SQL standard.
Since no one seems to be in favor of this proposal, I'm going to go ahead and close it out.
Possible alternative: explore whether it makes sense to add a web storage technology like IndexedDB to Node.js. Proposals that promote browser interop are usually better received.
Keep in mind that you should also volunteer to do the work when proposing a feature if you actually want to see it happen.
Pure node applications (JS/WASM) would take advantage of not having to rely onto external building tools at the sole expense of <1M of a binary increase in the node executable. Zero-admin is another issue.
Precompiled binaries address those pain points.
Again, no.
There are enterprise situations I deal with where deploying non-auditable code is a no-go.Embedding sqlite harkens back to the abandoned WC3 Web SQL standard.
I remember that. To put it mildly, it was mostly a non-technical decision.
Since no one seems to be in favor of this proposal, I'm going to go ahead and close it out.
I waited some couple years to raise the issue since I knew the possible reactions. 😄
Possible alternative: explore whether it makes sense to add a web storage technology like IndexedDB to Node.js. Proposals that promote browser interop are usually better received.
I use IndexedDB on several projects and my experience is that implementations are still quite buggy.
Again, it's far from a DBMS and not fail-safe.
Overall, more of a ulterior surface of attack to be worried of than a possible database replacement.Keep in mind that you should also volunteer to do the work when proposing a feature if you actually want to see it happen.
Volunteering was implicit.
Ave atque Vale!
-R
I actually agree with this, and sqlite should be embedded in the core.
Also, why sqlite and not $some_other_technology?
PHP seemed to have a very good answer for that, since thats what they chose to embed in their coreAnd, no. node-gyp is not an option.
It would help strengthen your case if you explain why. Precompiled and WASM-ified versions of sqlite exist - you would need to >argue why those aren't sufficient.For me, node-gyp is not an option, because the best sqlite module requires me to have massive amounts of trash labelled VisualStudio on my machine, and that's almost as appalling as how far short node-sqlite3 falls compared to
node-sqlite3Keep in mind that you should also volunteer to do the work when proposing a feature if you actually want to see it happen.
Really, there shouldn't be much work to do in the first place, as the whole code-base and API is pretty optimized and well-laid out by Joshua Wise viabetter-sqlite3, all you'd really need to do is link to it and make it available via require('sqlite3'). Which, before you get your quote gun out, I'm more than happy to volunteer my time on.So I think this should be re-opened, as even though 'not many' will use it, enough will to justify the very small increase in final size , and once the feature 'is' available, I believe many programmers will drop the primitive ways of temp and cache files. Maybe even one day the inclusion of sqlite3 into the core could help manage the mess of the
node_modulesfolder
NodeJS is close being the perfect swiss army knife of zero-admin deployable microservices and applications.
The only thing missing is a built-in database.
Adopting SQLite.h/.c and exposing it to JS will result in NodeJS being the best "batteries included" environment ever.
Encrypted versions of SQLite could be considered. At a later time.
And, no. node-gyp is not an option.
R.