A product written by some notorious rock stars at Google, and with a reputation for corrupting data...
[1] - "...LevelDB has history of database corruption bugs.[15][16][17][18][19][20] A study from 2014 has found that, on older (non-checksummed) file systems, the database could become corrupted after a crash or power failure.[21]..."
You seem to believe a description like that is a recommendation, but it might be the opposite. Any corporation is a place where Not-Invented-Here virus spreads rapidly, because a) there are numerous problems and edge cases that develop at large scale; b) there is manpower to charge at them; c) there are incentives to do just so, and appear as definitely hard working to the management. That aura even spreads externally, in particular, to this conversation we have. If something is made by a hip company, it's a gods' gift to mortals, if it's from uncool place, it's definitely a rusty tech working on punch cards. (I am sure there exist at least one example in which the same person or team did both.)
Of course, they must have had valid reasons to use LevelDB for some components in Chrome. It seems that Minecraft-like world generating games are also a good use case for it. What I'm saying is that Google doing something does not automatically mean you need to do the same at all.
It's worth pointing out that once you reach Google size and domination you can pretty much do whatever you want*. Things that if done by "ordinary" companies would destroy them or wipe out their customers/users overnight.
if i was an sqlite user, i really wouldn't care at all about google switching from sqlite to that thing in chrome.
From the readme:
> LevelDB is a fast key-value storage library written at Google that provides an ordered mapping from string keys to string values.
it's a completely different thing from sqlite. sqlite is a relational database (which can also do key-value storing, I guess).
my educated guess is that google started with sqlite, then reached the peak usefulness *within chrome* and only then switched to developing its own custom solution.
if anything, this is a testament to sqlite and how far you can go with it before needing a custom solution.
Thats nice and all, but Im a Chromium user who wants to manually audit and edit my \User Data\Default\Local Storage. That wasnt a problem in sqlite days, tons of tools available. Switch to leveldb not only made that difficult (one paid GUI tool in existence afaik), but also introduced a change in localstorage behavior. Chrome localStorage used to return entries sorted by key, this is no longer the case.
I believe Chrome has deprecated LevelDB at this point. It turns out that LevelDB doesn't work well when you need many different databases in a single application. So all new Chrome storage is SQLite. At least until they find something better...
A key-value store can underpin a SQL layer. Look at CockroachDB's usage of RocksDB (which is a descendant of LevelDB). Seems like a fair comparison to compare BTrees and LSM approaches. The latter work better because they align more closely with how solid state storage works. BTrees require a fair bit of pointer chasing for reads and are expensive to modify.
