WebSQL and IndexedDB are both DB API for accessing (CRUD) the underlying embedded database in the web browser. Which, if I am correct, is like SQL for accessing (CRUD) any c
To address your first question, WebSQL was never implemented in either Internet Explorer or Firefox (http://diveintohtml5.info/storage.html, http://caniuse.com/#feat=sql-storage). In terms of the "big browsers" that leaves Chrome and Safari, both born out of WebKit (although since v28 Chrome has been running on a fork from WebKit, called 'Blink'). In the past both these browsers used SQLite as the underlying database for both WebSQL and IndexedDb, but Chrome switched IndexedDb from SQLite to LevelDB.
To answer your second question, Chrome uses 2 different underlying database technologies:
WebSQL -> SQLite
IndexedDb -> LevelDB
I suspect they keep WebSQL as SQLite as they know it works. WebSQL is now deprecated and at some point it will be removed so why would they spend time porting it over to LevelDB.
In terms of performance between WebSQL / IndexedDb versus the performance of the underlying database, from experience on iOS Safari, both IndexedDb and WebSQL uses a SQLite database but they differ vastly in how the underlying database is constructed and how they perform. In my testing I found that WebSQL was twice as fast as doing 1000 simple database inserts compared with IndexedDb on Safari in iOS8.
In terms of your last question, I found this out:
For IE:
WebSQL -> Not supported
IndexedDB -> Extensible Storage Engine
For Firefox:
WebSQL -> Not supported
IndexedDB -> SQLite
For Safari:
WebSQL -> SQLite
IndexedDB -> SQLite
For Chrome:
WebSQL -> SQLite
IndexedDB -> LevelDB
(Sources: The WebKit project, https://bugzilla.mozilla.org/show_bug.cgi?id=837141, http://www.aaron-powell.com/posts/2012-10-05-indexeddb-storage.html)