> If your application software runs on the same physical machine as the database, which is what most small to medium sized web applications does, then you probably only need SQLite.
That's the adoption problem. It has a hard ceiling. Besides embedded, most engineers use a different DB professionally - dare I say pg or mysql? And because of that they'll reach for the tool they already know.
Sure, I get the argument that SQLLite fits "more exactly" for many many applications because the sheer number that never move off of one machine, but it has this hard ceiling of "what if I need more" and well "I could just use this other tool that goes the full distance, in case one day... oh and I already use it at work."
That's why SQLLite excels for embedded applications. It fits perfectly. There is no "what if" and the performance is astounding esp in low power.
The question is what kind of "more" is needed. Out of disk space or hitting CPU/mem limits? Splitting off a 2nd service which handles isolated functionality could help, migrating to larger storage could help, migrating some data to cold/external storage could help, eliminating low value high storage cost features could help.
The only "more" which pushes a move to client-server DB is a CPU- or memory-limited, not easily sharded, persistent service. But to have such a problem is highly uncommon. Usually optimization will solve such problems easily. I've seen Python services which use 1GB RAM/process, each process can handle 1 concurrent request, and there's only 20GB of RAM per instance. The solution there is to use one of many sane async frameworks to handle more than 1 concurrent request/process. Some problems, such as latency of DB queries/N+1s and the query complexity which ensues, will not even arise in the first place if you were using SQLite.
That's the adoption problem. It has a hard ceiling. Besides embedded, most engineers use a different DB professionally - dare I say pg or mysql? And because of that they'll reach for the tool they already know.
Sure, I get the argument that SQLLite fits "more exactly" for many many applications because the sheer number that never move off of one machine, but it has this hard ceiling of "what if I need more" and well "I could just use this other tool that goes the full distance, in case one day... oh and I already use it at work."
That's why SQLLite excels for embedded applications. It fits perfectly. There is no "what if" and the performance is astounding esp in low power.