For one project we used sqlite in a GUI application to store some tabular data (usually way below 1GB), and to do some light processing over it. Mind that the performance requirements were minimal, as this was a just an auxiliary function; the program did do a lot of heavy lifting in other parts, but the DB wasn't involved in these (it got fed some messages/stats at best, and most of the data came from other aux functions).
The sqlite lib was easy to integrate both on the technical as well as on the legal level. We could have done all that with native code, too (I think we even removed some code?), but it would have consumed much more time (dev work, unit tests, maintenance) without any benefits. And it worked like a charm, except for one issue: The GUI person did create a connection for every operation but thought they were reusing it, which then caused some weirdness. And this was easily fixed.<p>An important realization is that not everything needs to scale, and that it depends on how you access the DB and what your product looks like. For a load with many concurrent writes I'd be careful with sqlite, or when I know that I'll want my DB to mostly live in memory (e.g. operations will often process the whole, huge dataset and no index can help with that). But even if I thought "Uh, I'll probably need a full DB", I'd still benchmark my application with both sqlite and e.g. postgres. And if the API to access the DB uses some nice abstractions, swapping the flavor of SQL isn't a huge issue anyway.<p>//edit: Plus, I've done stupid stuff like "my SPA hammers the PHP API with 20 to 40 requests, each resulting in a simple SQLite query, just to render a checklist" and got away with it:
a) because we had at most 20 concurrent users [realistically: 1 to 5]
b) doing the checklist took half a workday (ticking off an item was done via a JS callback in the background, so the actual rendering happened only once)
and c) SQLite performs great for read heavy loads.
The site performed so well (page loads felt about as fast as HN, even when connected via VPN) that I even scraped the plan to locally cache checklist in the HTML5 localStore (bonus: no cache = no cache incoherence to care about).