And
"SQLite has exhibited very high reliability in the field and a very low defect rate, especially considering how rapidly it is evolving. The quality of SQLite is achieved in part by careful code design and implementation. But extensive testing also plays a vital role in maintaining and improving the quality of SQLite."[2]
There may be the occasional entity with mission critical data which does not, sooner or later, entrust some of it to SQLite. It would be difficult to populate such a list, however.
> Can I throw 1TB
Subject to this[0] list of constraints, yes. The theoretical upper bound is 281TiB, but this is untested due to a lack of the combination of hardware and filesystem which can create an SQLite file of that magnitude. What happens when the limit is reached is extensively tested, just not at the theoretical maximum, yet.
As for its general reliability, this too is documented[1]. SQLite sets the bar for high-assurance practices in open source software, at a level which more programs should aspire to.
[0]: https://www.sqlite.org/limits.html [1]: https://www.sqlite.org/testing.html
Seems like the kind of thing where, given a compelling need to do it, one could work something out fairly readily and rely on the result. But it's probably not the ideal solution to the problem.
Edit: by pure chance I hit that just a moment ago: https://fractaledmind.github.io/2024/10/16/sqlite-supercharg...
There are lots of small things missing from it (like boolwan support), but it's used as an archival format and backwards compatibility for the archive format is prioritized over new features.