SQL is a terrible example of a standard. Half the major databases that support the "standard" can't even agree with each other on what the syntax is to window the number of returned results.
SQLite is partly so battle tested simply because once you start down the path of relying on it, it becomes tough to shift to another SQL "standard" database, because of tiny differences in dialect, and sometimes huge differences in performance characteristics.
MySQL/MariaDB and PostgreSQL are also, open source, battle tested pieces of software. Why would a browser stop at SQLite and not allow developers the power of an equally tuned, "full" SQL database, with additional power/capabilities/storage management capabilities? Would a browser have to reimplement SQLite's dialect on top of it to support that as an option? Would a browser need to implement SQLite bugs on top of PostgreSQL? Would you want to write a website that does feature checking to see if WebSQL is backed by SQLite or MariaDB on the user's machine and adjust its SQL queries for the different query engines?
Meanwhile, you can look at Redis, Cassandra, Riak, BigTable, etc: we have the technology to build really scalable key/value stores that can scale and perform incredibly well. We also have the knowledge of building higher level APIs on top of that and getting those to scale and perform well. IndexedDB's slow period was a brief adjustment period, and benchmarks indicate that calling it "slow" or "feeble" today isn't accurate. We're certainly on the path where IndexedDB's performance is only steadily improving, and again, we have the technology to insure that it can scale and perform extremely well given the investment.
IndexedDB is a more than adequate compromise to the tar pit that is decades of weirdly incompatible SQL dialects and database engines, and to the security nightmare implications that if there was a 0-day bug found in SQLite code you could take down every browser on the web with it had SQLite been blessed to be such a "standard" that every browser just integrated it directly.
SQLite is partly so battle tested simply because once you start down the path of relying on it, it becomes tough to shift to another SQL "standard" database, because of tiny differences in dialect, and sometimes huge differences in performance characteristics.
MySQL/MariaDB and PostgreSQL are also, open source, battle tested pieces of software. Why would a browser stop at SQLite and not allow developers the power of an equally tuned, "full" SQL database, with additional power/capabilities/storage management capabilities? Would a browser have to reimplement SQLite's dialect on top of it to support that as an option? Would a browser need to implement SQLite bugs on top of PostgreSQL? Would you want to write a website that does feature checking to see if WebSQL is backed by SQLite or MariaDB on the user's machine and adjust its SQL queries for the different query engines?
Meanwhile, you can look at Redis, Cassandra, Riak, BigTable, etc: we have the technology to build really scalable key/value stores that can scale and perform incredibly well. We also have the knowledge of building higher level APIs on top of that and getting those to scale and perform well. IndexedDB's slow period was a brief adjustment period, and benchmarks indicate that calling it "slow" or "feeble" today isn't accurate. We're certainly on the path where IndexedDB's performance is only steadily improving, and again, we have the technology to insure that it can scale and perform extremely well given the investment.
IndexedDB is a more than adequate compromise to the tar pit that is decades of weirdly incompatible SQL dialects and database engines, and to the security nightmare implications that if there was a 0-day bug found in SQLite code you could take down every browser on the web with it had SQLite been blessed to be such a "standard" that every browser just integrated it directly.