1. FAQ

1. Why would browsers want this feature?
2. As it is a small and light browser, I would like to have a complete sqlite in the browser, this will allow me to create my own single apps within the browser itself.
3. What databases do browsers use?
4. IndexedDB, pouchdb(client couchdb), HTML5 local storage, cookies, Web SQL Database, sql.js
5. Why is this relevant?
6. sql.js is a javascript library to run SQLite on the web. but... this is not the official version of sqlite on the web, there is no version of sqlite on the web, what exists is an unofficial library that allows there to be sqlite on the web and here is the problem - it is something developed outsourced and not official Regarding that, my concern is with the support, maintenance of this library - of course I can fork it... but... I would like something official...
7. There are a lot of requests on WICG for SQLite to be on the web, have you ever thought about officially supporting SQLite on the web?
8. Some people say that having SQLite support on the web is not relevant, interesting - I would like to know the opinion of everyone present if this is relevant or not
9. There are technologies as mentioned that have already been implemented in most browsers, with sqlite it is different not every browser supports it
10. I would like to know if this feature has already been thought of or not

2. questions

3. refs

• https://discourse.wicg.io/t/proposal-ship-browsers-with-builtin-wasm-sqlite3/3954
• https://discourse.wicg.io/t/writable-file-api/1433
• https://stackoverflow.com/questions/19677553/can-i-use-a-database-in-the-browser
• https://www.codemag.com/article/1411041/Introduction-to-IndexedDB-The-In-Browser-Database
• http://diveintohtml5.info/storage.html
• https://caniuse.com/sql-storage
• https://superuser.com/questions/1355714/database-server-for-web-browser
• https://www.sitepoint.com/html5-browser-storage-past-present-future/
• https://pouchdb.com/guides/
• https://github.com/sql-js/sql.js

Hi! so... I spoke ironically, emphasizing that the support that exists is not something official

sql.js is a javascript library to run SQLite on the web. but...

There are several "buts" with that, actually ;). sql.js is a nice, simple solution for some high-level uses of sqlite, but it lacks the low-level interfaces which are needed for a wider range of "shapes" of applications. Even so, it has been a fantastic point of reference for how to integrate sqlite into the JS/WASM world.

but... I would like something official...

The good folks in the sqlite3 project have tasked me with working on that very thing. It is underway but there is neither a concrete timeline nor an estimate of when we'll have something which is ready for widespread beta testing. As soon as we have it, it will be posted about in this forum.

Is it possible to have SQLite support in browsers permanently?(yes no)

Currently yes and no. The storage models of JavaScript currently make it impossible to have full-fledged sqlite support. There are proofs of concept (including one from within this project) which use IndexedDB as backing store for sqlite. It works (surprisingly) but it's very easy to get the db in an inconsistent state due to weaknesses in the IndexedDB API which make it unsuitable for using with, e.g., the same app running in two tabs of the same browser. Thus it's not really useful for anything more than a proof of concept.

Sidebar: the Emscripten project already provides POSIX-like storage APIs for use with WASM which work very well with sqlite, but "it would be cool" if we can avoid hard dependencies on any specific WASM toolchain. It's an evolutionary process, though.

As web apps evolve, browsers will provide more infrastructure, including (we hope) storage backends more suitable for sqlite. When and if they do, we'll be eager to take that on, and we have been building up infrastructure to assist in working towards such features for several months, such as (shameless plug) this independent side-project of mine.

So: yes, it will eventually happen, but no, the web client infrastructure is not quite there yet. Long gone are the days of browsers which attempt to lock users in to specific features for all of eternity (MSIE 6), and modern browsers develop at a tremendous technological pace. It's only a question of time before they provide the features needed for tomorrow's class of web applications, and the sqlite project's developers aim to be ready to serve that niche as it arrives.

There are a lot of requests on WICG for SQLite to be on the web

It used to be. But:

The specification reached an impasse: all interested implementors have used the same SQL backend (Sqlite), but we need multiple independent implementations to proceed along a standardisation path

They decided having one engine was a bad idea.

They decided having one engine was a bad idea.

It's a general requirement, for standards tracks, that at least two independent implementations be available, presumably, in part, in order to prevent arbitrary commercial vendors from "standardizing" their stuff as a matter of course. That principle sometimes collapses under the onslaught of lobbyists and, one assumes, stacks of currency (bitter about OOXML? Who, me?). Alas, this project lacks such resources to "coerce" its way past such objections ;).

That said: at this point, given that sqlite has become a de facto standard with (AFAIK) no full-fledged alternative, the committee which chose to cancel the standardization of WebSQL on those grounds back in 2010(?) would, if the effort were rebooted today, presumably consider sqlite to be a special case worthy of exemption and they'd instead require multiple implementations of the browser-binding layer which would sit atop sqlite in that API. Speculation, of course, but seems reasonable.