Tucked away in spreadsheets there are but we don't currently have any benchmarks in a publishable form. In broad strokes, i can assure you (as the one who performed the benchmarks) that the new sqlite wasm is competitive with WebSQL in terms of performance, with either one winning out in certain benchmarks. Given that WebSQL is implemented in native code and sqlite in wasmified C, we're quite happy with those results.
Note, however, that benchmarks are very browser-dependent. Firefox's wasm engine, for example, is significantly slower than Chrome's, but it's also more consistent. If you run a given test 10 times in FF, the difference in runtimes across them will be small (maybe 10%), whereas there will be a +/-50% difference in runtimes for the same tests in Chrome. In Chrome, if the dev tools are open when wasm is running, wasm's performance can (for unknown reasons) drop by as much as half or more even if the wasm code produces no output.
> I hope the author(s) of IndexedDB would finally understand how stupid the idea of IDB was
While not one of said authors... You mind giving me an actual rundown on issues you've got with it instead of just slinging mud?
I've used IDB in a few projects, and apart from:
- The god awful callback crap born of being pre-promises.
- The lack of partial indexes (e.g. indexing a subset of documents based on some parameters)
- The iOS Webkit teams continued habit adding weird, app-breaking bugs every other release to an api/system that should be stable?
It's been fairly useful. Hell, it supports storing JS types like CryptoKey or Blob/File with no real issues[1]
[1] Sans iOS WebKit, which a version or 2 back would just eat Blobs at random.
You already gave a great overview of issues. But inventing something totally different from what people know without any reason doesn't make any sense. Look, YugaByteDB, CockroachDB, and some others use Postgres-compatible protocol/dialect. You can use most of standard tooling/query-builders/ORMs to speak with this databases. Why not use Redis or Cassandra protocol? Damn, leaving WebSQL as is would be much better choice. And please, don't say that "Web is different".
> But inventing something totally different from what people know without any reason doesn't make any sense.
See this argument falls apart because:
It's a key-value store... I'm fairly certain people are aware of that concept, or can grok it fairly quickly once introduced to it.
Also as to "without any reason"? It handles js data natively. You're not having to immediately throw an ORM or a bunch of custom code to marshal data into and out of the db. People build more than just todo lists. There was also some intent of it being "low level" that others could build niceties like rich query syntax etc atop.
Now, that didn't really happen much, so the debate about it being "terrible" should maybe focus there on what got missed for that goal.
No, it isn't. While kv is easy on its own, the IDB API was never the right answer to the demand. This is exactly the reason why we (devs) are so hot about the persistent client-side storage. We want just use something like SQLite (or WebSQL, or Postgres) and forget about the IndexedDB nightmare. I'm pretty sure, we will see a huge boost around libraries and tooling when the things get more stable eventually.
Much of that log is just issues with one implementation, which would indicate that the Safari team is either underfunded (time/talent/money wise) or incompetent to break a working/"feature complete" system, multiple times. Not really an issue with the spec as written.
As for transactions.... Yeah I'll admit they suck hard, and can be a pain to remember the quirks of them, as well as dealing with the callbacks.
Quotas and Private mode... Those same issues would apply to webSQL, and webSQL didn't have a way to delete the database to clear it up.
Are there any numbers on performance?