That’s silly, SQLite is the single most widely deployed database engine in the world, possibly the most deployed software, period. It’s unit test suite is second to none. It’s reliable enough that SMF, Solaris’ boot and service management (sort of like systemd) depends on it.

That does not mean it is applicable to all databases use-cases, but production-grade it undoubtedly is.

How many installations SQLite has is not that relevant in a discussion of SQLite vs full RDMS.

By your example, a bank should use SQLite because it is deployed widely.

You have to look where they are deployed and the use cases. They also come with dramatically different tooling which make sa huge difference. More tooling does not mean that a full RDMS is a better choice:

It is just about what you need, what use case you need to cover and what industry you are in.

> NEVER use sqlite for any production

> RDBMSs are there to enforce constraints on data.

If you did not ask SQLite to enforce type constraints on relations (with STRICT), it will work in the relaxed, backwards-compatible expected behavior of previous versions of SQLite.

That being said, if you want actual validation, you probably need more complex CHECK expressions anyways with your business rules, and those work by default on any database.

https://www.sqlite.org/stricttables.html

  * unless you're a madman that runs things with "PRAGMA ignore_check_constraints = false;" enabled or equivalent; in that case, no DB can help you.

RDBMS constraints are oversold usually. For instance it is usually the case that things like foreign-key constraints are avoided in production because they cause performance and maintenance nightmares.

Widely-used constraints like UNIQUE are production-quality in SQLite.