WebSQL wasn't killed by opposition to having a relational API, it was killed because the spec was tied to, and only implemented by embedding, a specific, identified version of SQLite.

I think that a developer distaste for relational databases was a major driver. Digging back into correspondence on this a few months ago (when this came up on HN) I found clear statements that Mozilla opposed anything relational. The SQLite version is a convenient excuse for some developers who, at the time, we're enamoured with "NoSQL".

Discussion here: https://news.ycombinator.com/item?id=28156831

Mozilla for a long time backed their IndexedDB with SQLite, they wouldn't have done that if they were that antagonistic to relational databases.

I trust Mozilla's surface reasons here: they inherited the mess that was NPAPI from Netscape, then decades of experience with XUL binary components, were among the many dealing with Flash bugs and zero-day fallout well after Flash's "heyday", and have combined multiple decades of experience in what happens if the web depends on specific binaries to do its job. From that standpoint of they were already knee deep in trying to sandbox/reign in NPAPI, remove XUL, and remove Flash I absolutely understand why "you want the web to depend on the bugs and zero days of SQLite directly with no abstraction layer between?" was a complete non-starter.

The need to productionize another embedded database in order to support embedded SQL in the browser seems like a tough hill to climb given how widespread SQLLite is. This stance is always going to keep web apps behind mobile apps in terms of features and performance.

Maybe on the other hand, wasm can fill this gap.

IMHO, these days browser should just ship popular libraries, e.g. sqlite, with browser, or download them once and cache them permanently, until never version is released. Think like «Linux distribution», but for web/wasm.