It is a replacement, but I'm not really sure whether it's a good one. SQL was a nice choice because it made writing hybrid applications (with online and offline DB storage) very easy, and it was using an API that was already well known and understood. At this point it's unclear if IndexedDB is actually going anywhere, it's a prime example of a lifeless spec being prescribed from "high above". It might get adopted, maybe browser makers will force web devs to do it in the end, but SQL already has been proven more than workable in the field whereas IndexedDB has not.
SQL is certainly a well-known _language_, but I don't think it's very well understood by most.
Also if IndexedDB has a "lifeless" spec, it might be because there's not much to discuss. Something simple and straightforward tends to requires much less discussion and debate, than something complex.
I'll be obtuse, and claim it means "JavaScript-like". You know, multiple "truthy" values, the inability to detect the difference between arrays and objects, a weird mashup of OO and functional abilities, `=== undefined` but `isNaN()`, and no real difference between integers and floats, and all the math weirdness that goes with them. Browsers implementing the same thing different ways, interacting with a system (the DOM) that's the same but different everywhere, and patched together by multiple, usually-mutually-exclusive libraries that everyone uses instead of the actual language.
(disclaimer: I've come to quite like JS, it's made some of my experiments phenomenally simple. but it's weird.)
An API that maps to the underlying data-structure (btree, ranges, cursors), is bar-none simpler than an API that abtracts the underlying data structure away (like any SQL does).
The web was built by taking existing systems, and cutting away at them until they were so simple they barely worked. But because they were simple they could spread.
IndexedDB isn't the simplest spec it could be (I think they could do-away with transactions if they were willing to require MVCC semantics) but it is admirably simple for a database.
> An API that maps to the underlying data-structure (btree, ranges, cursors), is bar-none simpler than an API that abtracts the underlying data structure away (like any SQL does).
That may be true in this specific case (I'm not saying either way), but it does not hold generally. For example, APIs involving directories and files are simpler than APIs involving inodes and blocks.
I like it because the API is much more web-like than SQL. Others have other reasons to prefer it.