WebSQL has increasing browser support. What's its future? [closed]

Question

I've done some looking around, and found that WebSQL seems to have a somewhat rocky future right now.

On the one hand, it's apparently widely looked down on as a solution because of the fact that literally every actual implementation simply uses SQLite3, because the spec itself borrowed heavily from SQLite3's design semantics, and it would be very very tricky to not specifically use SQLite3.

On the other hand, as of February 2017, all the major browsers do seem to support it (http://caniuse.com/#search=websql) - Chrome has had it for ages, and it was introduced in IE11, Edge 14, Firefox 50, and Safari 10. Mobile support also seems to be trending positively (right now there's just a note saying it doesn't work for some reason on some Samsungs).

The theory behind IndexedDB does makes sense: it's a brand-new standard, not tied to any existing library, and vendors can design their own implementations, create competition, and avoid vendor/library lock-in. However, I've crashed into one of IndexedDB's most negative aspects: its abstracted design seems to have absolutely disastrous performance due to implementational overhead.

http://scaljeri.github.io/indexeddb-vs-websql/v2.0.0/index.html is a one-click IndexedDB-vs-WebSQL shootout. I set it to 10000 items (a fairly modest number) and gave it a try on my ThinkPad T43 - a single-core 2GHz Pentium M with 2GB RAM.

First of all, with nothing except Chromium running, most tabs suspended, and the remaining tabs not using any CPU:

For the entire "Insert" time on IndexedDB, the tab was using 100% CPU, and the system was generally unusable. (I could have browsed around - screen repaints was just really slow - but I didn't in order to get an accurate benchmark).

I also happened to play with the tab when I had a lot of other things going on and the system happened to be swapping to death (something that happens a lot on this particular machine):

And yet, this entire time, WebSQL performance is incredible. Three seconds to insert a bunch of rows, even while the system is swapping a lot (to a slow HDD) and system I/O is greatly impacted. (Note: I understand that SQLite3 force-flushes all data to disk to ensure integrity by default, but I'm unsure if Chrome's implementation disables this option for WebSQL.)

The benchmarking done at https://nolanlawson.com/2015/09/29/indexeddb-websql-localstorage-what-blocks-the-dom/ (from September 2015) seems to generally agree with what I've presented here; it shows IndexedDB performance to be significantly worse than WebSQL on a 2013 Macbook Air.

With these considerations in mind, I have two questions.

1. What's WebSQL's practical future as a Web standard? SQLite3 works everwhere (it's ANSI C) and WebSQL seems to be widely supported (?).

   My question was originally going to ask specifically about Chrome extension support (see next point), but now I think about it, if I wanted an alternative to localStorage (and its 5MB limit), I'd want to use WebSQL as my primary solution, with IndexedDB or localStorage as a fallback that were rarely (if ever) used. What are my chances of success with this approach going forward?

2. Are any browser vendors likely to drop WebSQL support (for websites and/or extensions) anytime soon?

   I'm at the beginning design stages of a Chrome extension which will need to store a potentially significant amount of information - it'll be managing history/bookmarks/etc, data that will only ever grow and never shrink. I'm going to want to use this extension on all of my computers, including the T43 in the benchmarks I showed above.

   At this point, for me, it's WebSQL or nothing; I cannot agree with IndexedDB. If WebSQL looks like it'll be going away, I'll make a small application server in Go or similar and simply talk to that.

   On a similar note, if WebSQL randomly "goes away" from Chrome one day, will extension support for it continue even if Web support disappears?

Polik

Submit these tests as a bug report on IndexedDB performance. It was always bad but maybe it's just the implementation is bad, not the design per se. So there's a chance this insert bug can be fixed soon. – Corporal

indexedDB is a bad joke compared with web sql performance-wise. there is a library that pretends to simulate SQL with indexedDB and fails miserably on large data and will never catch-up with the super tuned sql. also absurd how much more work one needs to do with indexedDB for no reason because that type of nosql design is good for huge bigdata sets and not for a local db running clientside. – Darcee

@wOxxOm: AFAIK, these issues have actually persisted for years. – Polik

@ZigMandel: I see, thanks for the information. I'm guessing Chrome will support WebSQL for a while yet, but the way things are standards-wise is really sad. TIL about that library, and I'm not surprised it bogs down easily - IndexedDB feels really bloated. – Polik

To the people voting this be closed - I understand the opinionated nature of this question, and I'm not sure what to do with the one-sided sentiment it seems to be attracting. I was primarily seeking to find out what developers in similar situations to mine have done - I just want to build high-performance applications. Reopening the question would be awesome, but I just request it not eventually get deleted - I want this to stay on public record. I'm terrible at "rewording" in these situations, everyone is welcome to edit this. – Polik

Id also love for webSQL to not go away until there is a true replacement, but its also ok for this question to be on-hold. This is not the right place to debate it. Ive tried to debate this on the official forums/issue trackers (I tried couple years ago) the response was hey! look at this cool js library github.com/google/lovefield I will try again but last time it was way too slow and could only handle 50k tables before dying. – Darcee

@ZigMandel: I totally agree/understand SO isn't the right place to debate. It is widely used so is a good spot for public records though, so I just didn't want this Q to disappear. :) Also, I had a look at LoveField - google.github.io/lovefield/demos/movie_db/demo.html gives me (on the same T43) 20007ms load for IndexedDB, 20248ms for LF. F5 produced 16598 for IDB, 15091 for LF. So it's pretty close, no real difference. – Polik

This debate is still relevant in 2019. It's safe to say that IndexedDB will never be as fast and performant as Web SQL. Which means the people who rejected WebSQL specifications were not really bright and completely missed what was to come. – Intercommunion

@Tony: It is indeed very sad that an SQLite centric design was interpreted politically instead of technically (especially considering SQLite is literally everywhere). It seems it may have been lack of decisiveness and technically-focused vision that was the design fail here. – Polik