I'm using it for the data catalog for one of my projects (a Linux backup tool) which I've grown to something like 20GB, and storing the metadata catalog for 40 systems and about 30 backup sets for each one.
So far the main issues I've been having is I have a lot of complex joins, and it doesn't seem to want to use appropriate indexes all the time. If I'm joining 2 tables on an indexed field, it is ok, but as soon as I add a 3rd or 4th table the performance falls apart. So my current workaround is to join 2 tables into a temporary table, add an index, then join that temp table to a 3rd one.
I'm using WebSQL / Sqlite to store TV show data on the user's system. works like a charm, databases regularly grow to 10+mb, never had a problem with crashes, speed or anything like it. Plus, everything runs locally <3
Now I really hope that Spartan can implement WebSQL as well...
I look forward to using SQLite again. In 2010ish I used it for an airport and aircraft database to be installed with our iOS app for 'find near you' feature. lookup performance was perfect. but did have some performance snags on application start, a server call retrieved any DB records needing to be updated. I found SQLite update statements were slow (10mb DB of 10,000 records, less than 100 updates took 30s on first gen iphones), so instead of retrieving the records that were changed, we modified it to retrieve the latest 3mb (compressed) of the 10mb DB from the server, decompress and replace the single file which turned out to be simpler, more atomic and required much less code.
Actually, all you needed to do was wrap that batch update in a transaction; by default, SQLite autocommits and writes to disk after each update/insert, which is a bit slow.
Which is kind of sad... I get the objections to "WebSQL" as it kind of lacked a standard to the support/syntax. But given that it was SQLite (v3 iirc) everywhere, it should have just specified SQLite v3's interface, and MS could have fallen into line with Firefox, Chrome and Safari.
IndexedDB is a better fit for no-sql style use in the browser, but sometimes you really need something closer to SQL.
I used SQLite to store the entire last.fm user graph there, it was more than a gigabyte or so. MongoDB was abysmal, so I switched to SQLite, which was very, very fast, and I had zero problems with it. I have immense respect for it ever since.
So far the main issues I've been having is I have a lot of complex joins, and it doesn't seem to want to use appropriate indexes all the time. If I'm joining 2 tables on an indexed field, it is ok, but as soon as I add a 3rd or 4th table the performance falls apart. So my current workaround is to join 2 tables into a temporary table, add an index, then join that temp table to a 3rd one.