I'm still resistant to using SQLite for projects it would be perfect for, like small nodejs services with relatively small batches of non-permanent data... and I'm not sure why. Deprecation from web browsers put me off, and I think it's unfortunate, but it isn't such a big deal for my server-side purposes... but still... I just don't want to harness a 10-year deployment to something a little iffy when I'm completely sure that including a full MySQL db will be a safe bet. For the same reasons but more so, I'm not really going to mess around with DuckDB. It would really be nice if there were an interoperable web / server light relational db standard, and it's a shame that SQLite somehow got so close to that... but we seem to reach these peaks and then go backwards for a decade. (See: Every animated interactive 2D canvas screen graph for the last decade trying to reproduce some portion of Flash).
SQLite is not 'a little iffy'. It's a) one of the most resilient pieces of software ever made and b) one of the most widely adopted pieces of software ever made.
One data point that really highlights this is that it is used in the flight software in Airbus planes. This alone is a very strong indicator that it is extremely robust, and also that it will be around for a very long time. There's a whole list of additional industry use-cases [1] that support this claim even more.
A good resource to better understand how SQLite is tested is https://www.sqlite.org/testing.html. I found it to be a fascinating read, and quite impressive. I came away with a lot of confidence in SQLite's robustness.
> Deprecation from web browsers put me off, and I think it's unfortunate
See, as I recall WebSQL was deprecated because to be a proper standard it needed more than one implementation, but nobody thought they could improve on Sqlite.
So the draft standard ended up saying user agents must implement the SQL dialect supported by Sqlite 3.6.19 which is.... not normal, for a standard.
But fundamentally, an argument in favour of Sqlite
